-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti1
ANLISE E PROJETO ORIENTADOS A OBJETOS:MTODO FUSION EXPANDIDO E
ADAPTADO UML
Por Maurcio F. [email protected]
Departamento de InformticaCentro de Cincias Exatas e
Tecnologia
Universidade de Caxias do Sul
Equipe do Projeto FILMCoordenador:
Prof. MSc. Maurcio F. GalimbertiColaboradores:
Prof. MSc. Jos Eduardo C. BussmannProf. MSc. Giovanni E.
RoccoProf. MSc. Daniel L. Notari
Bolsistas:Fabrcio Lazzari
ResumoO presente trabalho prope abordar a anlise e projeto
orientados a objetos a partir de um mtodo
sistemtico e didtico, utilizando para construo de seus modelos
um conjunto padronizado de notaes.Ser adotado o mtodo Fusion de
anlise e projeto de sistemas orientados a objetos, o qual se
expandecom uma fase inicial de coleta e especificao de requisitos,
conduzindo-a como um processo linear. Asdemais fases de anlise,
projeto e implementao sero tratadas em um processo cclico de evoluo
dodesenvolvimento de sistemas onde sero utilizadas as notaes padro
UML (Unified ModelingLanguage) para modelagem dos artefatos do
sofware.
Palavras-chave: anlise e projeto orientados a objetos; mtodo
orientado a objetos; mtodo Fusion;Unified Modeling Language
(UML).
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti2
1. Introduo Anlise e Projeto de Sistemas Orientados a Objetos
................................................ 41.1 - Anlise e
Projeto Orientados a
Objetos................................................................................
6
1.1.1 - Mtodos de Anlise e Projeto Orientados a Objetos
...................................................... 71.1.2 -
Mtodo Fusion de Anlise e Projeto Orientado a
Objetos.............................................111.1.3 -
Padres de Modelagem de Objetos usando UML - Unified Modeling
Language...........12
1.2 - Mtodo Fusion Expandido e Adaptado UML
...................................................................131.2.1
- Conduo das Fases do Mtodo de Especificao e Construo do
Software................15
PARTE I - PROCESSO
LINEAR...................................................................................................192.Fase
de Estruturao e Especificao de Requisitos
.....................................................................20
2.1 - Documento Contextual do Sistema
.....................................................................................212.2
- Modelo de Objetivos
..........................................................................................................22
2.2.1 Estrutura dos Objetivos
..................................................................................................232.3
- Viso de Use
Cases.............................................................................................................242.4
- Cenrios e Ciclo de Vida do Sistema
..................................................................................252.5
- Planejamento dos Ciclos de Construo do
Sistema............................................................262.6
- Manuteno de um Glossrio de Termos
............................................................................27
PARTE II - PROCESSO CCLICO
................................................................................................283.
Fase de
Anlise...........................................................................................................................29
3.1 - Conduo da Fase de Anlise
.............................................................................................293.2
- Refinamento dos Requisitos por Ciclo
................................................................................31
3.2.1 Cenrios do Sistema por Objetivo
..................................................................................313.2.2
Modelo de Requisitos por Objetivo
................................................................................32
3.3 - Modelo de Objetos (Modelo Conceitual)
............................................................................333.4
- Modelo de Interfaces
..........................................................................................................34
3.4.1 Cenrios e Modelo Ciclo de
Vida...................................................................................353.4.2
Modelo de
Operaes.....................................................................................................36
3.5 - Modelo de Objetos do Sistema (Modelo Conceitual)
..........................................................373.6 -
Verificao dos Modelos da Fase de Anlise
......................................................................38
4. Fase de Projeto
...........................................................................................................................404.1
- Conduo da Fase de Projeto
..............................................................................................404.2
- Grafos de Interao de Objetos
...........................................................................................41
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti3
4.3 - Refinamento do Modelo de Objetos do
Sistema..................................................................424.3.1
Agregaes
....................................................................................................................424.3.2
Herana - Estrutura Hierrquica de Classes
....................................................................43
4.4 - "Visibilidade"
.....................................................................................................................444.5
- Verificao dos Modelos da Fase de Projeto
.......................................................................44
5. Fase de
Implementao...............................................................................................................465.1
- Conduo da Fase de Implementao
.................................................................................465.2
- Gerao dos Prottipos e Estruturas de Classes de Objetos
.................................................475.3 - Verificao
das Estruturas de Classes de
Objetos................................................................47
6. Concluses
.................................................................................................................................48Bibliografia
....................................................................................................................................49Apndice
A - Estudo de Caso MiniBib (Biblioteca Departamental)
................................................50
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
4
1. Introduo Anlise e Projeto de Sistemas Orientados a ObjetosA
orientao a objetos surgiu como uma abordagem de programao que
procura explorar o nosso
lado intuitivo. Os "tomos" da computao orientada a objetos (os
prprios objetos), so anlogos aosobjetos existentes no mundo fsico,
o que produz um modelo de programao muito diferente datradicional
viso "funcional" e "procedimental" [Coleman, 1996].
Modelo computacional orientado a funes:Os "tomos" da computao so
as funes;Funes atuam sobre um nico estado compartilhado;Qualquer
funo pode atuar sobre qualquer parte do estado.
Figura 1.1 - Modelo Computacional Orientado a Funes [Coleman,
1996]Neste modelo a estrutura no se altera com o passar do tempo,
apesar de ocorrerem alteraes nos
valores armazenados na mesma: modelo computacional
esttico.Modelo computacional orientado a objetos:A nica maneira de
se obter ou alterar o estado de um objeto pelo envio de
mensagens;Cada objeto responsvel pela resposta a uma determinada
mensagem;Os objetos, quando compartilham uma nica interface, so
agrupados em classes;
Figura 1.2 - Modelo Computacional Orientado a Objetos, [Coleman,
1996]
Durante a execuo do sistema os objetos podem ser construdos,
executar aes, serem destrudos
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
5
ou se tornarem inacessveis: modelo computacional dinmico.Assim
sendo, os tomos do processo de computao so os objetos:Objetos
trocam mensagens entre si;As mensagens resultam na ativao de
mtodos;O emissor da mensagem no precisa saber como o objeto
receptor organiza o seu estado interno;Ao emissor da mensagem basta
saber que o objeto receptor/servidor responde a certas mensagens
demaneira bem definida.Entretanto, o paradigma orientado a objetos
deve, alm do processo de programao, abranger
tambm as demais fases do processo de desenvolvimento de sistemas
computacionais em especfico.Historicamente foram desenvolvidas
metodologias para tratar o ciclo de desenvolvimento de
software sob o ponto de vista de objetos. Contudo, como um
processo natural de evoluo de "novas"tecnologias, este tema ainda
proporciona novas propostas de abordagem para o assunto, gerando,
aomesmo tempo, divergncias e similaridades entre os diversos
mtodos.
Tendo como base este contexto, foram desenvolvidas as primeiras
metodologias e tambmabordagens parciais para tratar o assunto, como
linguagens de especificao e mtodos de projeto, porexemplo.
Considerando-se como abordagens (mtodos, tcnicas, linguagens de
especificao) conhecidasmundialmente, e altamente influentes para
este trabalho, cita-se: "Booch", de Grady Booch; "OMT
(ObjectModeling Technique)", de James Rumbaugh; "OOSE
(Object-Oriented Software Engineering)", de IvarJacobson; "CRC
(Class-Responsability-Collaboration)", tcnica exploratria que
orienta odesenvolvimento atravs do registro das classes em cartes
de referncia. Estas abordagens sero melhorcomentadas na seo 1.1.1,
sem contudo aprofundarmo-nos nas mesmas por no ser este nosso
objetivocom o presente trabalho.
Devido a esta miscelnea de mtodos, surgiram duas boas abordagens
com propostas de fuso deconceitos, sendo elas: Fusion [Coleman,
1996] e UML (Unified Modeling Language) [OMG, 2001]. Estasse
caracterizam como a base de nossas atividades e sero devidamente
apresentadas com o transcorrerdeste programa.
Atualmente sendo adotada como base para a prtica da orientao a
objetos nas disciplinas deAnlise e Projeto de Sistemas I e II,
seguindo os currculos dos cursos de Bacharelado em Cincia
daComputao e Tecnologia em Processamento de Dados da Universidade
de Caxias do Sul, o mtodoFusion se apresenta bastante sistemtico e
didtico para o processo de desenvolvimento de softwareorientado a
objetos, estabelecendo uma rota direta entre a definio dos
requisitos e a implementao dosistema. No entanto, os modelos por
ele criados tornam-se s vezes bastante confusos devido
asimilaridade de notao entre os mesmos. Alm disso, o mtodo no prope
abordagem para a definiode requisitos, que uma das fases iniciais
do processo de produo de software, que precede as atividadesde
desenvolvimento.
J em relao UML, padro estabelecido pela OMG (Object Management
Group) esta umalinguagem grfica para visualizar, especificar,
construir e documentar os artefatos de um sistema desoftware. A UML
oferece uma forma padro para se escrever/modelar projetos de
sistemas, incluindoconceitos, tais como processos de negcios e
funes de sistema, bem como coisas concretas comosentenas de
linguagem de programao, projetos de bancos de dados e componentes
reutilizveis de
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
6
software [OMG, 2001].Mais especificamente, a UML se concretiza
como um conjunto de notaes bem definidas e
especficas para a construo dos diversos modelos necessrios desde
a definio de um sistema orientadoa objetos at a sua
implementao.
A UML a unificao e evoluo das propostas de vrios mtodos de
orientao a objetos, dentreeles os principais mtodos so Booch, OMT e
OOSE, concebidos, respectivamente, por trs autores derenome
internacional, sendo Grady Booch, James Rumbaugh e Ivar Jacobson
(referenciadosmundialmente como "The Three Amigos"), que extraram
de suas metodologias anteriores aspectospositivos de cada uma
delas. Alm disso, suas experincias mostraram que ineficiente uma
metodologiaestanque e que no se adeque a outros processos de
desenvolvimento de software, o que os motivou criao da UML como uma
linguagem flexvel, que possa se adaptar a outras metodologias j
existentesou que por ventura venham a ser criadas.
A partir deste quadro mundial, foi criada uma comisso
internacional que iniciou um processo depadronizao da rea de
orientao a objetos, sendo atualmente a UML verso 1.3 (com proposta
daverso 1.4 em avaliao) reconhecida com exclusividade por esta
comisso, denominada ObjectManagement Group (OMG) [OMG, 2001], como
padro de notao de construo de modelos orientadosa objetos.
Este contexto, aliado ao fato de existir proposta semelhante,
quando da adequao da UML aoprocesso Objectory de Engenharia de
Software, atravs do trabalho "UML Extension for ObjectoryProcess
for Software Engineering" [//??], vem a motivar o presente projeto,
com o qual buscar-se-utilizar a UML para acrescentar clareza,
eficincia e padronizao construo dos modelos propostospelo mtodo
Fusion. Alm disso, permite a expanso do mtodo Fusion em relao fase
inicial dedefinio de requisitos, buscando-se enquadrar a notao da
UML para a gerao de modelos para estafase.
No entanto, a principal motivao para a criao deste trabalho vem
da atual estrutura curricular doscursos do Dpto. de Informtica
desta Universidade e, consequentemente, da insero de seus egressos
nomercado de desenvolvimento de software. Sendo estes cursos
formadores de profissionais com perfis deanalistas e projetistas de
software, considera-se que os mesmos devem cada vez mais se
enquadrar aocontexto mundial da tecnologia de orientao a objetos.
Deve-se, portanto, considerar o processogradativo de mudana do
paradigma estruturado pelo orientado a objetos, pelo qual passam as
empresasdo setor de informtica da regio, o que as levar,
certamente, adoo de padres estabelecidos para osegmento de produo
de software.
1.1 - Anlise e Projeto Orientados a ObjetosEsta seo apresenta a
importncia de se ter, alm do processo de programao, um mtodo
sistemtico que deve abranger tambm as demais fases do processo
de desenvolvimento de sistemascomputacionais em especfico.
Como principais caractersticas em se ter um mtodo,
cita-se:Oferecer sistemtica para as fases de definio de requisitos,
anlise, projeto e implementao;Evitar codificao precoce: programas
de difcil manuteno e que no satisfazem os requisitos
dousurio;Mtodos sistemticos consomem mais tempo nas fases iniciais
do desenvolvimento de software.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
7
As vantagens em se ter um mtodo sistemtico para anlise e projeto
de sistemas (sistemasorientados a objetos, no nosso caso) nem
sempre so apreciadas. Entre elas temos [Coleman, 1996]:
Verificao de requisitos;Conceitos mais claros;Maior adequao do
projeto ao problema;Melhor decomposio do projeto para trabalho em
equipe;Melhor comunicao da equipe de desenvolvimento;Menor esforo
de manuteno;No restante desta seo sero apresentadas as principais
abordagens existentes para anlise e projeto
de sistemas orientados a objetos. Na subseo 1.1.1 sero
brevemente abordadas, conforme [Coleman,1996], algumas das
propostas pioneiras da orientao a objetos, as quais ainda
contribuem em muito parao desenvolvimento de software orientado a
objetos, mas que no so o foco deste trabalho. Contudo,
seroenfatizados, nas sees subsequentes, o mtodo Fusion (seo 1.1.2)
e o padro UML (seo 1.1.3) por secaracterizarem como a base de nosso
projeto.
1.1.1 - Mtodos de Anlise e Projeto Orientados a ObjetosSem ter o
objetivo de aprofundar os conhecimentos em quaisquer trabalhos
abaixo, esta seo
descreve caractersticas bsicas, a grande maioria sob o ponto de
vista de [Coleman, 1996], sobrepropostas pioneiras na orientao a
objetos. Desejando-se conhecer melhor estes trabalhos, so
citadassuas principais referncias bibliogrficas.
OMT (OBJECT MODELING TECHNIQUE) [Rumbaugh, 1991]ANLISE:
modelagem do mundo real.
Modelo de Objetos:captura estrutura esttica de um sistema:
classes e relacionamentosatributos e operaes que caracterizam
cada classe
notao: diagrama E-R estendidoModelo Dinmico:
captura o comportamento dinmico de cada classe:mquina de
estados: como objetos da classe respondem aos eventosevento
representa um estmulo externoestado uma abstrao dos valores dos
atributos e relacionamentos
Modelo Funcional:mostra o que o sistema deve fazer: uso de
DFDs
PROJETO: decises a respeito dos subsistemas e aspectos gerais da
arquitetura.Projeto do Sistema:
divide em subsistemasaloca processos e defini a arquitetura
geral
Projeto de Objetos:algoritmos dos mtodosdetermina mtodos das
classesparticiona projeto em mdulos para a programao
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
8
IMPLEMENTAO: codificao do projeto dos objetos.
PRSAnlise possui um processo bem definidoModelos da anlise com
notaes concisas e inteligveisCONTRASRelacionamento entre modelos da
anlise no claroModelos da anlise dificultam percepo do cenrio
globalProjeto no possui abordagem passo a passoNo fica claro
onde/quando deve-se comear projeto
BOOCH [Booch, 1994]Processo com natureza descritiva (o que
podemos fazer) e no prescritiva (o que devemos fazer)Notaes (sem
ordenamento do processo):
Diagramas de Classes:classes e relacionamentos (esttico): variao
do E-Resboos so produzidos no incio do desenvolvimento e
completados durante aidentificao dos relacionamentos
Diagramas de Objetos:objetos e relacionamentos (dinmico): troca
de mensagensesboos so produzidos no incio do desenvolvimento e
completados durante aidentificao dos relacionamentos
Diagramas de Tempo:apresentam informaes de ordenao (sem
mensagens)eixo-x (tempo ) e eixo-y (fluxo de controle entre os
objetos)tambm identificam tempo de criao e destruio de objetos
Diagramas de Estados:transio de estados dos objetos
Diagramas de Mdulos e Diagramas de Processos:grafos identificam
viso fsica do sistemadiagrama de Mdulos:alocao de classes e objetos
em mdulos e dependncia dos mdulos
Diagrama de Processos:processadores, dispositivos e conexo de
comunicao entre eles
PRSConjunto de notaes abrangem todos os aspectos de um sistema
orientado a objetosCONTRASNotao complexaInformaes se duplicam entre
os vrios modelosAusncia de processo bem-definido para o
desenvolvimento de sistema
OBJECTORY [Jacobson, 1992]Baseia-se em use cases:
dilogo/transaes entre o sistema e um usurio
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
9
Adota o termo agentes: usurios do sistemaUse Cases capturam
funcionalidades do sistemaDemais modelos so construdos sobre use
casesUse cases -- elos de ligao entre as fasesREQUISITOS: declarao
em linguagem natural.Modelo Caso-de-Uso:
identifica agentes e seus casos-de-uso:Modelo de Objetos do
Domnio:
suporta os casos-de-uso: conceitos com o qual o sistema
operanotao similar a de um modelo E-R
Descries da Interface com o Usurio:esboos das janelas que os
usurios vero na telaenvolve o usurio no processo de
desenvolvimento
ANLISE: refina os modelos dos requisitos.Modelo uma forma de
modelo E-RObjetos e classes requeridos em cada use
caseSUBSISTEMAS:
grupos de objetos com comportamento similarcritrios para
agrupamento:
forte acoplamento entre objetosflexibilidade para suportar
mudanas nos requisitos
CONSTRUO: modelos da anlise so refinados.Modelo de Blocos:
Identifica blocos (abstrao de blocos de cdigo) do sistemaCada
bloco composto por um ou mais objetos da anlise
Diagrama de Interaes:Participao dos blocos (atravs de mensagens)
com use cases
Modelo de Interface de Blocos:Interface operacional: formada
pela extrao das operaes realizadas sobre um bloco
Especificao de Blocos:Modelo opcional sobre o comportamento
interno do bloco: mquinas de estados
PRSContribui com o conceito de use case: base do
processoCONTRASModelos e notaes: inadequados e insuficientesDifcil
compreenso de alguns modelosDificuldade para verificar inteireza
e/ou consistncia do sistema desenvolvido
CRC (CLASSE-RESPONSABILIDADE-COLABORADOR) [Beck,
1989]IDENTIFICAR CLASSES E RESPONSABILIDADES:
Objetos so agrupados, gerando classes em cartesAes dos objetos
transformadas em responsabilidades das classes: tarefas a
seremexecutadas pela classe
ATRIBUIR RESPONSABILIDADES:Responsabilidades so alocadas s
classesDistribuio das tarefas do sistema
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
10
IDENTIFICAR COLABORAES:Identificao das interaes entre as
classes: exame de cada par classe/responsabilidadebuscando suas
dependncias com outras classes
PRSComo tcnica exploratria (no um mtodo) bastante avanadatil no
projeto de estruturas de heranaMuito poderosa para o projeto das
interaes entre os objetosCONTRASCartes de referncia: nico registro
para as decises tomadasInadequadas para fins de manutenoNo trata da
criao/destruio de objetos
MTODOS FORMAISAbordagem de engenharia de software baseada na
aplicao de matemtica discreta programaode computadoresPropriedades
do sistema so capturadas em um alto nvel de abstraoTrabalhos
recentes tentam estender estes mtodos aos sistemas orientados a
objetosAlto custo de aceitao: exigido muito conhecimento
matemticoMtodo promissor: a longo prazo
FUSION [Coleman, 1996]O mtodo Fusion caracteriza o centro dos
estudos para nossa abordagem de orientao a objetos.
Portanto, neste contexto apenas apresentada a figura 1.3 que
representa o sentido de seu batismo, natraduo de uma fuso de
abordagens e mtodos. Deixaremos os detalhes do mtodo Fusion para
asubseo a seguir e, como bem ser fundamentado, este mtodo ser visto
ao longo de todo o nossotrabalho.
Figura 1.3 - Mtodo Fusion [Coleman, 1996]
UNIFIED MODELING LANGUAGE (UML) [OMG, 2001]A UML, juntamente com
o mtodo Fusion, forma a base de nossos estudos. Portanto haver
uma
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
11
seo especfica para trat-la (seo 1.1.3). Neste momento vale
lembrar apenas que a UML umalinguagem grfica para visualizar,
especificar, construir e documentar artefatos de sistemas de
software.Assim, a UML no se caracteriza como um mtodo ou processo
de construo de software, sendo estefato, e a sua padronizao, os
avais para sua utilizao em nosso trabalho, o que tambm poder ser
feitoem empresas de desenvolvimento que adotem mtodos e processos
proprietrios/particulares paraconstruo de software.
1.1.2 - Mtodo Fusion de Anlise e Projeto Orientado a ObjetosO
Fusion se caracteriza como um mtodo de anlise e projeto de sistemas
voltado para a produo
de software orientado a objetos. Este mtodo estabelece uma rota
direta entre a definio dos requisitos e aimplementao do sistema,
partindo, contudo, de uma definio de requisitos
pr-estabelecida.
Para a conduo das fases de anlise e projeto, o mtodo Fusion
estabelece um conjunto conciso ecompleto de notaes
bem-definidas.
A construo do software a partir do mtodo Fusion considera um
processo dividido em fases. OFusion estabelece o que deve ser feito
em cada fase, orientando a sequncia de aes de cada fase e
oscritrios que suportam o ponto de passagem para as fases
subsequentes.
O mtodo Fusion no cobre a captura de requisitos. Portanto, o
mesmo prev que os requisitossejam fornecidos por usurios e
documentados seguindo-se alguma tcnica de elicitao e deespecificao
de requisitos "qualquer".
Assim sendo, a diviso proposta pelo mtodo Fusion para o processo
de desenvolvimento Anlise,Projeto e Implementao, conforme segue um
breve resumo.
ANLISE: o que o sistema faz e no como feito.Descobre os objetos
e as classes existentes no sistema e seus relacionamentos;Define o
comportamento esperado do sistema;Modelos so produzidos para
identificar:
Classes de objetos que existem no sistema;Relacionamentos entre
essas classes;Operaes que podem ser executadas no sistema;Sequncias
permissveis para eventos de entrada e de sada;
No associa mtodos s classes.PROJETO: define como sero
implementadas as operaes do sistema atravs do comportamento
dos objetos em tempo de execuo.Operaes so divididas em interaes
de objetos;Operaes so associadas s classes;Como objetos faro
referncias mtuas entre si;Relacionamentos de herana entre as
classes;Modelos do projeto identificam:
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
12
Como operaes sero implementadas pelas interaes entre os
objetos;Como as classes faro referncias mtuas e como iro se
relacionar por herana;Os atributos das classes e suas operaes;
IMPLEMENTAO: transforma projeto em cdigo.Herana, referncias e
atributos so codificados nas classes especficas;Interaes entre
objetos so transformadas nos mtodos dos objetos;Mquinas de estado
so usadas para se reconhecer as sequncias permitidas para as
operaes;Tambm so consideradas tcnicas de inspeo e teste para
avaliao de sistemas orientados aobjetos.DICIONRIOS DE DADOS: so
adotados durante todo o processo de desenvolvimento e
identificam as entidades existentes no sistema.Segue abaixo uma
viso geral do mtodo Fusion. So identificadas as fases e os modelos
gerados
por cada uma delas e como esto interligados.
Figura 1.4 - Estrutura do Mtodo Fusion [Coleman, 1996]
1.1.3 - Padres de Modelagem de Objetos usando UML - Unified
Modeling LanguageA UML teve seu desenvolvimento iniciado em outubro
de 1994 quando Grady Booch e Jim
Rumbaugh, da Rational Software Corporation, comearam seus
trabalhos de unificar os mtodos Booch e
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
13
OMT. Em 1995 juntou-se com aqueles Ivar Jacobson e sua companhia
uniu-se Rational e seu mtodoOOSE passou a colaborar com a proposta
da UML.
//?? Continuar com uma viso estrutural da UML a partir da OMG:
no mais de uma ou duaspginas. Procurar uma figura
representativa.
1.2 - Mtodo Fusion Expandido e Adaptado UMLA proposta deste
trabalho resultado do projeto FILM, o qual est institucionalizado
na
Universidade de Caxias do Sul pelo Departamento de Informtica e
tem como objetivo adaptar e expandiro mtodo Fusion de anlise e
projeto de sistemas orientado a objetos. Este ajuste do mtodo
tambmexpande o espectro do mtodo Fusion, acrescentando ao mesmo a
abordagem da fase inicial deespecificao de requisitos, a qual no
considerada na verso original do mtodo Fusion
[Galimberti,2001].
Para a expanso do mtodo e adequao de seus modelos, utiliza-se da
proposta da UnifiedModeling Language (UML). A UML prope
flexibilidade aos diversos processos de desenvolvimento desoftware,
expandindo mtodos orientados a objetos e disponibilizando um
conjunto de notaes para aconstruo dos modelos da orientao a objetos
[Galimberti, 2001].
Para a fase de Definio de Requisitos o projeto est baseado na
proposta Um Modelo deEstruturao de Requisitos para o Mtodo Fusion
Adaptado UML [Rocco, 2001]. No entanto,dependendo dos objetivos e
carga horria de um curso de APOO, ser possvel partir de
especificaestextuais e, preferencialmente, adoo de use cases para a
definio de requisitos.
A estrutura geral proposta pelo projeto FILM est demonstrada na
figura 1.5 abaixo, a qual foiconstruda a partir das notaes de use
case da UML. Esta figura objetiva visualizar a estrutura
geralproposta atravs dos processos e de suas fases. A partir da seo
1.2.1 ser oferecida uma viso maisespecfica sobre as informaes a
serem documentadas em cada fase atravs de seus modelos.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
14
Figura 1.5 Estrutura do FILM com atores e processos (linear e
cclico)
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
15
1.2.1 - Conduo das Fases do Mtodo de Especificao e Construo do
SoftwareO projeto FILM prev as fases de Estruturao e Especificao de
Requisitos, Anlise, Projeto,
Implementao e Testes. A seguir sero apresentadas e comentadas as
estruturas de cada uma das fasespropostas no projeto FILM e a serem
abordadas nos captulos posteriores.
Fase de Estruturao e Especificao de RequisitosA metodologia a
ser trabalhada inicia com a Fase de Estruturao e Especificao de
Requisitos.
Considerando um processo linear para sua abordagem, deveremos
documentar as informaes que estosendo elicitadas conforme a figura
1.6 abaixo. Os principais documentos sero o Documento Contextualdo
Sistema, Modelo de Objetivos, Viso de Use Case e Cenrios e Ciclo de
Vida do Sistema. OPlanejamento do restante do processo cclico de
desenvolvimento do sistema marca o encerramento destafase de
Especificao de Requisitos.
Figura 1.6 - Fase de Estruturao e Especificao de Requisitos
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
16
Fase de AnliseA fase de Anlise de nosso trabalho marca o incio
da investigao interna sobre o sistema e prope
um conjunto de modelos a serem desenvolvidos conforme a figura
1.7. Considerando os ciclos planejadosna fase anterior, todos os
modelos devero ser construdos para cada ciclo. Portanto, as
principaisinformaes modeladas durante a fase de Anlise estaro nos
Modelos de Objetos e Modelo de Interfaces.No entanto, conforme a
proposta cclica, o primeiro passo desta fase sugere que os
requisitos do ciclo emquesto sejam refinados antes de se iniciar o
processo de modelagem dos objetos e operaes.
Figura 1.7 - Fase de Anlise
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
17
Fase de ProjetoA fase de Projeto caracteriza-se pela modelagem
dinmica do sistema principalmente em termos das
mensagens e dos objetos necessrios s operaes especificadas na
fase de Anlise. Portanto, conforme afigura 1.8, as principais
informaes sero modeladas atravs dos Grafos de Interao de Objetos.
Isto irviabilizar, para o final da fase de Projeto, que sejam
feitos melhoramentos em nossos Modelos de Objetos,buscando iniciar
a fase de Implementao com as estruturas/prottipos de classes.
Figura 1.8 - Fase de Projeto
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
18
Fase de ImplementaoNossa fase de implementao estar caracterizada
em se traduzir informaes, presentes
principalmente nos modelos da fase de Projeto, em
Estruturas/Prottipos de Classes de Objetos, conformeobserva-se na
figura 1.9.
Figura 1.9 - Fase de Implementao
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
19
PARTE I - PROCESSO LINEAR
Figura Parte I Processo Linear
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti20
2. Fase de Estruturao e Especificao de RequisitosA fase de
Estruturao e Especificao de Requisitos ser tratada atravs de um
processo linear,
onde sero definidos os requisitos para todo o sistema em funo de
seus objetivos principais. Portanto,esta fase se prope a investigar
e documentar o domnio do problema em estudo tendo como foco
osobjetivos que sero buscados quando da preparao da soluo do
problema. Futuramente, aps asdefinies dos ciclos que se iniciam na
fase de Anlise, todos os requisitos voltaro a ser
melhordocumentados a partir de outras ferramentas de modelagem.
Para facilitar o trabalho de documentao de requisitos, este
captulo orienta o estudante a buscarum conjunto inicial de
informaes constantes do Documento Contextual do Sistema. Em seguida
serabordada uma tcnica para se documentar requisitos a partir de
objetivos, onde sero utilizados osModelos de Objetivos e a Viso de
Use Cases para expressar os principais processos identificados
nodomnio do problema em estudo. Logo aps a construo dos use cases
ser descrita uma maneira de sedocumentar a interao dos
agentes/atores com o sistema e em que sequncia isto pode
ocorrer.
O tratamento dado aos requisitos antes da fase de Anlise estar
temporariamente encerrado com oplanejamento das fases seguintes em
termos de processos cclicos de construo do sistema.
Haver, contudo, uma seo a parte no captulo voltada a abordar a
manuteno de um Glossrios deTermos, necessrio durante todo o tempo
em que ser construdo o sistema e que, por se constituir emalgo
bastante simples, no mereceu um captulo especfico para seu
estudo.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti21
Figura 2.1 Fase de Estruturao e Especificao de Requisitos
2.1 - Documento Contextual do SistemaO Documento Contextual do
Sistema dividido em cinco clusulas que ajudam a criar uma viso
macro do sistema. A partir deste documento j se pode ter uma
idia do sistema e seu enquadramento noambiente ao qual vai servir,
podendo-se prever a viabilidade de construo do projeto.
A orientao para que este documento contenha as clusulas, ou
sees, conforme abaixo:
Descrio InicialEssa descrio expe uma viso geral do sistema,
citando quais mdulos o compem, quais as
necessidades que ele pretende atender e o resultado esperado aps
sua implementao.
Problema Original uma exposio da situao atual do ambiente onde o
sistema ir atuar, descrevendo todas as
dificuldades existentes e que devem ser solucionadas, ou pelo
menos simplificadas, pelo sistema que seest propondo.
Origem do sistema
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti22
Esta clusula dever identificar se o projeto a ser desenvolvido
ser de um sistema novo ou seruma manuteno para a atualizao de um
sistema j existente. No caso de ser uma atualizao sobreum sistema j
existente, deve-se analisar o quanto do mesmo poder ser aproveitado
e qual ser o volumede alteraes que necessitam ser realizadas sobre
ele para que o mesmo possa suprir as necessidades dosclientes.
Tambm no caso da atualizao, deve-se analisar a relao custo-benefcio
para que no sejamais oneroso efetuar as alteraes sobre o sistema
existente do que desenvolver um sistema novo, jvoltado para as
atuais necessidades.
Contexto de utilizaoEsta clusula consiste na descrio do ambiente
onde o sistema ir atuar, tanto em nvel local fsico
quanto em relao ao tipo de agente que ir interagir com ele.
Limites do sistemaEsta clusula definir as responsabilidades do
sistema dentro dos objetivos. Devem ser definidos
quais objetivos sero atendidos pelo sistema e quais deles ficaro
sob responsabilidade dos usurios ou deoutros sistemas, evitando a
criao de falsas expectativas por parte das pessoas envolvidas no
projeto.
2.2 - Modelo de ObjetivosO processo de elicitao deve ser
concomitante ao modelo de objetivos, o qual define a estruturao
das informaes. A estrutura das informaes prev a definio do
objetivo e a descrio dos objetos queo compem. So sugeridas questes
que tem o propsito de descobrir, ante ao objetivo, os
objetosresultado, sujeitos, objetos e ferramentas, conforme as
figuras 2.2 e 2.3.
Figura 2.2 A definio de um objetivo [Rocco, 2001]
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti23
Esquema de Descrio de ObjetivoObjetivo Elicitadas as informaes,
pode-se definir um objetivo para o sistema em
questo. Descrio do objetivo, que em geral responde a
umquestionamento por qu.
Resultado Qual o resultado esperado? Por que h a
necessidade?Objeto Para o que esse objetivo se faz necessrio ao
sistema?Sujeito Quem atua em prol desse objetivo?Ferramenta Quais
so os recursos necessrios para os sujeitos interagirem com o
objeto?Figura 2.3 - Estrutura para a descrio de objetivo [Rocco,
2001]
2.2.1 Estrutura dos ObjetivosEsta estrutura tem por finalidade
compor a estrutura hierrquica dos requisitos derivados de cada
objetivo. Neste momento apenas os requisitos de nvel mais alto
so abordados, pois para contemplar umrequisito outros requisitos
podem ser necessrios. Essa estrutura dada pela associao entre
objetivo erequisitos e refinamentos entre os requisitos. O objetivo
define uma atividade realizada no sistema,enquanto que os
requisitos definem as aes necessrias para a realizao completa da
atividade.
Essa abordagem hierrquica do modelo permite estruturar os
requisitos em nveis verticais deabstrao, nos quais os requisitos so
associados por qualificadores E, que indica
requisitoscomplementares, e por qualificadores OU, que indica
requisitos opcionais para o atendimento atividadeou s aes
hierarquicamente sobrejacentes. A figura 2.4 representa a estrutura
dos objetivos.
Em uma primeira etapa do processo proposto, os requisitos so
expressos somente em nvel inicial,ficando os demais requisitos
derivados a serem identificados e definidos posteriormente, aps
oestabelecimento dos ciclos prioritrios para o desenvolvimento.
Figura 2.4 Estrutura dos Objetivos [Rocco, 2001]
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti24
Figura 2.5 Definio de Requisito [Rocco, 2001]
Descrio dos requisitos nvel 0Cada requisito descrito segundo
estrutura representada na figura 2.6, valendo lembrar que estes
requisitos so somente os de nvel 0.
Esquema de Descrio de Requisito
Nome: Nome: identificador da ao, como ela reconhecida dentre
oscasos de uso do sistema.
Ao
Descrio: Descrio: informao elicitada; tipicamente, uma narrativa
comoos envolvidos descrevem a ao requerida ao software.
Agente Solicitante da ao; quem age. o ente que emite um estmulo
requerendo aexecuo de alguma ao ao sistema.
Produto Objeto produzido por uma ao realizada na criao,
transformao oudestruio do objeto definido no objetivo. Desta
maneira, os produtos dorequisito so composies dos objetos do
objetivo.
Recurso Objeto que corresponde interface entre o agente e o
software, ou a informaoque o agente envia para os objetos do domnio
do software para que possamexecutar alguma ao em prol da produo de
algum produto.
Anotao Descries de requisitos no funcionais que compem um
requisito modelado.
Figura 2.6 Estrutura para Descrio de um Requisito [Rocco,
2001]
2.3 - Viso de Use CasesA seo de Use Cases da especificao de
requisitos tem como objetivo apresentar uma estrutura
grfica abrangendo o sistema a partir de seus principais
processos e agentes. Portanto, a construo doDiagrama de Use Cases
apresenta os atores envolvidos no sistema que est sendo elicitado e
com quaisprocessos os mesmos esto em contato.
Atividades e DependnciasEm geral os Use Cases podero ser
convertidos dos requisitos de nvel 0. Contudo possvel que
sejam derivados diretamente dos objetivos quando estes possurem
requisitos de nvel 0 simples ou empequena quantidade, o que pode
ser mais conveniente para a gerao do modelo de Use Cases.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti25
Estratgias para ModelagemA orientao para modelagem dos Use Cases
sugere que sejam derivados dos Objetivos
identificados anteriormente. Todavia, no sendo usada a abordagem
por objetivos, pode-se partir daespecificao de requisitos
listando-se possveis Use Cases e, a partir disso, montar o
diagramaassociando-os aos seus respectivos atores.
Notaes para Modelagem
Figura 2.7 Diagrama de Use Case
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
2.4 - Cenrios e Ciclo de Vida do SistemaDentro da fase de
Especificao de Requisitos, a construo dos Cenrios e do Ciclo de
Vida tem
como finalidade visualizar a interao dos Atores com o sistema,
em um alto nvel atravs dos Use Cases,e a sequncia permissvel de
ocorrncia/execuo destes Use Cases, os quais sero convertidos
emExpresses Ciclo de Vida.
Atividades e DependnciasA construo das expresses ciclo de vida
so baseadas nos Modelos dos Objetivos e na Viso de
Use Case do sistema.
Estratgias para ModelagemA modelagem do ciclo de vida s pode ser
feita dominando-se a sequncia e repeties de
ocorrncia dos Use Cases, caso isto ocorra. Portanto,
observando-se os objetivos e requisitos, e os UseCases derivados,
deve-se ter clareza do sequenciamento dos Use Cases para se
estabelecer uma sentenade Ciclo de Vida do sistema conforme
ocorrncia destes Use Cases.
Notaes para ModelagemA modelagem do ciclo de vida feita de forma
declarativa, necessitando-se de um conjunto
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti26
gramatical para sua representao. Inicialmente sero utilizadas as
notaes Fusion at que sejammapeadas para UML. A sintaxe geral para o
modelo ciclo de vida segue apresentada abaixo.
Life Cycle [Nome:] Expresso-Regular(Nome-Local-Expresso =
Expresso-Regular)*
-Alfabeto: qualquer evento de entrada ou sada pode ser utilizado
em uma expresso eventos de sada: precedidos pelo smbolo #
-Operadores: sendo x e y expresses ciclo-de-vida: x . y denota x
seguido por y x | y denota a ocorrncia de x ou y x * denota zero ou
mais ocorrncias de x x + denota uma ou mais ocorrncias de x [ x ]
denota que x opcional x | | y significa intercalao arbitrria de x e
y
-Substituies Nome = expresso ciclo-de-vida
-Precedncia de Operadores (ordem decrescente) [ ], *, +, . , | ,
| |
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
2.5 - Planejamento dos Ciclos de Construo do SistemaA tarefa de
planejar os ciclos de desenvolvimento do sistema no sugere
atualmente nenhuma forma
especfica de modelagem. As diretrizes bsicas, contudo, orientam
que os ciclos de construo do sistemasejam programados com o
objetivo de liberar pequenos mdulos aos usurios para que possam
sergradativamente testados e melhorados. A tendncia que cada ciclo
no consuma mais de dois meses paraser construdo (analisado,
projetado e implementado).
Atividades e DependnciasO planejamento dos ciclos, partindo de
prazos estabelecidos e necessidades dos usurios, sugere a
estruturao de cronogramas de construo por ciclo. Assim sendo, as
informaes de objetivos e usecases, bem como o ciclo de vida do
sistema, devem ser o ponto inicial de observao para organizar
osciclos por prioridades do sistema e dos usurios e preparar a
passagem para as fases seguintes do processode construo do
software.
Os ciclos devem ser planejados considerando o tempo para sua
concluso, tendo como objetivo suaimplantao e colocao em teste junto
aos usurios. O objetivo que cada ciclo seja estanque, sendo
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti27
necessria a sua concluso para que possa ser encaminhado o incio
de um novo ciclo. Isto no inviabilizaa construo incremental de
ciclos, pois tambm se tem como objetivo o escalonamento
dodesenvolvimento atravs de verses diferentes de construo dos use
cases ou objetivos do sistema.
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
2.6 - Manuteno de um Glossrio de TermosO glossrio de termos
serve para documentar informaes que requeiram melhores
esclarecimentos,
de modo a melhorar a comunicao e evitar mal-entendidos.
Originalmente denominado dicionrio dedados tambm no mtodo Fusion,
ser referenciado como glossrio de termos pelo seu carter de
registrarno apenas dados, mas tambm quaisquer informaes e restries
que no possam ser colocadas nosdiagramas construdos ao longo do
processo de anlise e projeto de sistemas.
Um glossrio de termos representa uma ferramenta vital onde todas
as definies feitas devem serencontradas. Manter o glossrio de
termos uma atividade contnua durante todo processo de construodo
sistema e por menor que seja a descrio de um item, ainda assim a
melhor forma de deixar claro oseu significado.
O mtodo Fusion orienta para a construo de um glossrio, porm no
obriga a uma sintaxe enotaes especficas. Portanto, neste trabalho,
sugerida uma forma bsica para documentao dos itensatravs de
tabelas. As colees de itens de mesma categoria podem ser
documentadas em tabelasespecficas, otimizando a localizao dos
termos.
Estratgias para ModelagemConsiderando que a manuteno do glossrio
de termos seja uma atividade constante durante todo o
processo de construo do sistema, orienta-se para que o mesmo
seja atualizado ou durante a construodos diagramas ou logo aps o
encerramento dos mesmos. Segue abaixo uma sugesto de como
estruturaras informaes dentro do glossrio de termos.
Notaes para ModelagemA documentao do glossrio, em geral, ser
possvel atravs de uma tabela de trs colunas como
abaixo. No entanto, conforme o momento do processo de construo
do sistema, outras colunas poderoser acrescentadas para melhor
descrever determinados termos.
Nome do Termo Categoria DescrioIdentificao do termomodelado
Designao do tipo do termo emrelao ao seu propsito
demodelagem
Texto descritivo
Figura 2.8 Glossrio de Termos
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti28
PARTE II - PROCESSO CCLICO
Figura Parte II - Processo Cclico
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti29
3. Fase de AnliseA funo da fase de Anlise , baseada no documento
de requisitos, ou seja, no resultado gerado
pelo documento do sistema, identificar as classes de objetos
existentes no sistema, descrever osrelacionamentos entre elas e
definir as operaes que podero ser executadas pelo sistema. A fase
deAnlise mostra "o que" o sistema faz e no "como" ele feito,
obtendo-se ao final desta fase um"documento de especificaes".
A construo de dois modelos estticos so os objetivos da fase de
Anlise, os quais tratam deaspectos diferentes, sendo o Modelo de
Objetos e o Modelo de Interfaces, este ltimo sendo compostopelos
Cenrios e seus Modelos de Ciclo de Vida e pelo Modelo de Operaes.
Assim, esta fase doprocesso responsvel pelas seguintes descries:
classes de objetos (sem associar quaisquer mtodos sclasses);
relacionamentos entre classes; operaes do sistema; sequncia
permissvel de operaes. Noentanto, a proposta de um processo cclico
exige que os requisitos a serem tratados sejam melhordetalhados.
Assim, a proposta para a fase de Anlise prev que os requisitos
sejam refinados modelando-os por Objetivo (Modelo de Requisitos por
Objetivo) e adotando-se os Cenrios para melhor visualiz-los.A
figura 3.1 oferece uma visualizao, atravs de use cases, da
estrutura a ser modelada durante a fase deAnlise.
Figura 3.1 Fase de Anlise
3.1 - Conduo da Fase de AnliseA fase de anlise deve ser
conduzida de forma a transformar as informaes coletadas durante a
fase
de definio de requisitos em modelos que representem as
estruturas estticas do sistema e ocomportamento do mesmo. No
entanto, a partir da fase de Anlise o sistema ser modelado atravs
de umprocesso cclico. Este processo foi estabelecido de forma a
viabilizar a construo incremental do sistema.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti30
Assim sendo, o primeiro passo da fase de Anlise ser estruturar o
ciclo em questo, o que deve serfeito com o aprimoramento dos
requisitos documentados na fase anterior, caraterizando em
umrefinamento dos requisitos a partir dos objetivos antes
brevemente descritos. Inicialmente, anterior aosdetalhes dos
requisitos, deve ser modelado o comportamento do sistema de forma a
identificar quais soas interaes existentes entre o sistema, durante
o(s) use case(s) em questo, e o meio em que estinserido. Isto ser
feito atravs da representao de eventos de entrada e de sada entre o
sistema, o qualseve ser visto como uma caixa preta.
Modelagem Fusion:Cenrios do Sistema por Objetivo: utilizar
notaes padro UML para Diagrama deSequncias;
Modelagem de Refinamento de Requisitos:Modelo de Requisitos por
Objetivo: utilizar notaes da abordagem de Requisitos por
Objetivo
Com uma abordagem orientada a objetos, as primeiras modelagens
devem representar as classes deobjetos atravs de conceitos
relevantes soluo do problema em anlise em geral substantivos
quepodem ser submetidos a uma lista de categorias, conforme
[Larman, 2000] identificados nasinformaes at ento documentadas.
Estes conceitos sero modelados como classes de objetos que
serelacionam entre si atravs de restries de cardinalidades. So
identificados tambm os primeirosatributos de cada classe de objeto.
A sugesto inicial que as associaes (relacionamentos) sejamsimples,
protelando-se associaes dos tipos agregaes, generalizaes e
especializaes para ummomento mais propcio da fase de Projeto.
Modelagem Fusion:Modelo de Objetos: utilizar notaes padro UML do
Diagrama de Classes.
As prximas informaes a serem modeladas caracterizam-se por
representar a estruturacomportamental do sistema. O comportamento
do sistema deve ser documentado de forma a identificarquais so as
interaes existentes entre o sistema e o meio em que est inserido.
Isto j deve ter sido feitonos cenrios atravs da representao de
eventos de entrada e de sada entre o sistema, no entanto agoradeve
ser modelada a sequncia permissvel para ocorrncia destes eventos
dentro do ciclo de vida dosistema. Portanto, neste momento da fase
de Anlise deve-se modelar os eventos de entrada comooperaes do
sistema. Assim, as operaes sero documentadas de forma a identificar
quais estruturas deobjetos devero ser manipuladas para realizar
cada operao e suas responsabilidades. As operaesmodelam os eventos
de entrada e seus efeitos no sistema, os quais podem ser as
alteraes no estado dosistema e/ou os eventos gerados na sada.
A fase de Anlise ser encerrada estabelecendo-se as fronteiras do
sistema, no Modelo de Objetos,em relao ao meio em que est inserido.
Isto ser feito com a construo do Modelo de Objetos doSistema, onde
sero mantidas as estruturas de classes e associaes necessrias s
operaes do sistemajuntamente com os atores/agentes que interagem
com o mesmo.
Modelagem Fusion:Modelo de Interfaces:
Modelo Ciclo de Vida: utilizar notaes Fusion at adaptao
UML;Modelo de Operaes: utilizar notaes padro UML para
Contratos;
Modelo de Objetos do Sistema: utilizar notaes padro UML do
Diagrama de Classes
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti31
juntamente com Atores dos Use Cases.
3.2 - Refinamento dos Requisitos por CicloConsiderando o
processo cclico a ser abordado na fase de Anlise, o primeiro passo
agora partir
dos requisitos documentados, na fase anterior, no formato de
objetivos e aprimorar os conhecimentossobre cada um deles, dentro
de seu respectivo ciclo.
O refinamento dos requisitos feito a partir dos Modelos de
Objetivos do(s) Use Case(s) do ciclo.Sero desenvolvidos os Cenrios
respectivos aos Use Case(s) em questo e os Modelos de Requisitos
porObjetivo.
3.2.1 Cenrios do Sistema por ObjetivoEm paralelo expanso dos
requisitos, descritos na seo 3.2.2, deve ser modelado o
comportamento do sistema de forma a identificar quais so as
interaes existentes entre o sistema,durante o(s) use case(s) em
questo, e o meio em que est inserido. Isto ser feito atravs da
representaode eventos de entrada e de sada entre o sistema, o qual
deve ser visto como uma caixa preta.
Abaixo segue um esquema com a notao a ser utilizada para a
modelagem dos Cenrios, o qualadota o padro UML para Diagrama de
Sequncias.
Atividades e DependnciasA construo dos cenrios deve partir da
especificao de requisitos, mais especificamente a partir
do Modelo de Objetivos e dos Use Cases. Seu desenvolvimento
tambm depende do Modelo deRequisitos por Objetivo, sugerindo que
sejam construdos em paralelo.
Estratgias para ModelagemA principal orientao para montagem dos
Cenrios est na identificao dos atores e suas aes, o
que pode ser feito observando-se as clusulas dos Esquemas de
Descrio de Requisitos do objetivo emquesto. As principais clusulas
so Ao, Agente e Recurso.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti32
Notaes para Modelagem
Figura 3.2 Cenrios com notao UML de Diagrama de Sequncia
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
3.2.2 Modelo de Requisitos por ObjetivoOs requisitos devero
agora ser expandidos para o Objetivo em questo no ciclo. A
estrutura a ser
utilizada exatamente a mesma vista na seo 2.2 de Modelo de
Objetivos, porm agora os requisitosdevero ser melhor detalhados,
abaixo do nvel 0. Vale voltar e observar as figuras 2.4, 2.5 e
2.6.
Portanto, cada requisito ser refinado conforme definio da figura
2.5, estando suas clusulascomentadas na seo 2.2.1, na figura
2.6.
Atividades e DependnciasComo bem pode-se observar, a construo
deste modelo est diretamente ligada ao Modelo de
Objetivos e aos Cenrios.
Estratgias para ModelagemPartindo do Modelo de Objetivos, a
clusula Ao deve ser o ponto inicial de investigao para a
descrio do requisito em si, buscando-se definir outros objetos
que compem o requisito.
Notaes para ModelagemVer seo 2.2.1, figura 2.6.
Estudo de CasoSistSW01 (Apndice A);
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti33
SistSW02 (Apndice B).
3.3 - Modelo de Objetos (Modelo Conceitual)A abordagem do modelo
de objetos visa representar as classes de objetos atravs de
conceitos
identificados nas informaes at ento documentadas. Estes
conceitos sero modelados como classes deobjetos que se relacionam
entre si atravs de associaes e restries de cardinalidades. So
identificadostambm os primeiros atributos de cada classe de objeto.
A sugesto inicial que as associaes(relacionamentos) sejam simples,
protelando-se associaes dos tipos agregaes, generalizaes
eespecializaes para um momento mais propcio da fase de Projeto.
Abaixo segue um esquema com a notao a ser utilizada para a
modelagem dos objetos, o qual adotao padro UML para Diagrama de
Classes.
Atividades e DependnciasA modelagem dos objetos depende dos
requisitos at ento coletados para o ciclo em questo.
Devem ser observados os Cenrios e os Modelos de Requisitos por
Objetivo. A partir do segundo ciclo dedesenvolvimento, vale lembrar
em observar os modelos de objetos j construdos, pois pode-se
reutilizarclasses de objetos j modeladas.
Estratgias para ModelagemUma das tarefas mais complicadas quando
se comea a modelar objetos a identificao das classes
de objetos. Vrias so as tcnicas utilizadas para sua modelagem,
no entanto no existe nenhuma frmulamgica para este fim.
O procedimento bsico, contudo, partir das especificaes de
requisitos correspondentes ao cicloem questo. Nossa sugesto
utilizar de duas tcnicas em conjunto, sendo a tcnica gramatical de
Booch[Booch, 1994] e de uma lista de categorias sugerida em
[Larman, 2000].
A tarefa inicial formar uma lista dos substantivos encontrados
ao longo da especificao derequisitos, os quais sero candidatos a
classes. A partir da deve-se buscar sua identificao nas tabelas
decategorias de [Larman, 2000] buscando qualificar o conceito como
classe de objeto ou como atributo. Alista de substantivos gerada
tambm facilita a eliminao de redundncias (conceitos de
objetossemelhantes ou repetidos).
Busque no modelar chaves (primrias, estrangeiras, ...) como em
bancos de dados. Isto dever serfeito no momento de mapear as
classes de objetos para uma estrutura de dados persistentes.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti34
Notaes para Modelagem
Figura 3.3 Modelo de Objetos com Notaes UML do Diagrama de
Classes
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
3.4 - Modelo de InterfacesO comportamento do sistema deve ser
documentado de forma a identificar quais so as interaes
existentes entre o sistema e o meio em que est inserido. Isto j
deve ter sido feito atravs darepresentao de eventos de entrada e de
sada entre o sistema, atravs dos Cenrios anteriores, mas agoradeve
ser modelada a sequncia permissvel para ocorrncia destes eventos
dentro do ciclo de vida dosistema. A fase de Anlise se encerra
modelando-se os eventos de entrada como operaes do
sistema.Portanto, as operaes sero documentadas de forma a
identificar quais estruturas de objetos devero estardisponveis para
realizar cada operao e suas responsabilidades. As operaes modelam
os eventos deentrada e seus efeitos no sistema, os quais podem ser
as alteraes no estado do sistema e os eventos
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti35
gerados na sada.
3.4.1 Cenrios e Modelo Ciclo de VidaDentro do Modelo de
Interfaces, a construo do Ciclo de Vida tem como finalidade modelar
a
sequncia permissvel de ocorrncia dos eventos de entrada e de
sada, considerando que os Cenrios,construdos no incio da fase de
Anlise, no tem este propsito.
Atividades e DependnciasA construo das expresses ciclo de vida
so baseadas nos Cenrios e fundamentadas nos
requisitos especificados nos use cases e objetivos em questo no
ciclo.
Estratgias para ModelagemA modelagem do ciclo de vida s pode ser
feita dominando-se a sequncia e repeties de
ocorrncia dos eventos previamente modelados. Portanto, deve-se
ter clareza do funcionamento do usecase em questo e dos requisitos
para se alcanar o objetivo que est sendo abordado. Lembra-se que
foiespecificado, ainda na fase de Definio de Requisitos, um Modelo
Ciclo de Vida baseado em use cases, oque facilita o refinamento de
suas expresses/subexpresses.
Notaes para ModelagemA modelagem do ciclo de vida feita de forma
declarativa, necessitando-se de um conjunto
gramatical para sua representao. Inicialmente sero utilizadas as
notaes Fusion at que sejammapeadas para UML. O conjunto notacional
est especificado abaixo, sendo o mesmo descrito na seo2.4.
-Alfabeto:qualquer evento de entrada ou sada pode ser utilizado
em uma expressoeventos de sada: precedidos pelo smbolo #
-Operadores: sendo x e y expresses ciclo-de-vida:x . y denota x
seguido por yx | y denota a ocorrncia de x ou yx * denota zero ou
mais ocorrncias de xx + denota uma ou mais ocorrncias de x[ x ]
denota que x opcionalx | | y significa intercalao arbitrria de x e
y
-SubstituiesNome = expresso ciclo-de-vida
-Precedncia de Operadores (ordem decrescente)[ ], *, +, . , | ,
| |
Estudo de CasoSistSW01 (Apndice A);
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti36
SistSW02 (Apndice B).
3.4.2 Modelo de OperaesA construo do modelo de operaes marca o
momento do processo em que se comea a investigar
as estruturas internas do sistema em construo. As operaes sero
modeladas atravs de fichas com umconjunto de clusulas. Cada clusula
tem seu propsito de transformar os requisitos do objetivo
emreferncias s estruturas at ento modeladas como objetos. Portanto,
cada evento de entrada setransformar em uma operao, merecendo uma
ficha/esquema de modelagem, a partir da qual serodocumentadas as
responsabilidades da operao e os efeitos causados ao sistema aps
sua execuo.
Possveis resultados associados a uma operao do sistema, so:Criar
uma nova instncia de classe;Alterar atributos de objetos
existentes/instanciados;Criar/eliminar tuplas de
relacionamentos;Envia um evento a um agente.
Atividades e DependnciasA construo do Modelo de Operaes depende
praticamente de todas informaes documentadas
at ento para o ciclo em questo. A base da modelagem das operaes,
contudo, formada pelo Modelode Objetos, Cenrios e Ciclo de Vida
alm, claro, das especificaes de requisitos atravs do Modelo
deRequisitos por Objetivo.
Estratgias para ModelagemA estratgia para modelagem das operaes
deve iniciar observando-se os Cenrios e as expresses
Ciclo de Vida do ciclo, transformando cada evento de entrada em
uma ficha de operao. A partir disso,as tarefas restantes tero o
propsito de preencher as demais clusulas do esquema de operaes.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti37
Notaes para ModelagemA modelagem das operaes feita de forma
declarativa, adotando-se clusulas da notao padro UMLdos Contratos.
As clusulas devem estar dispostas em um esquema de operao, conforme
sugestoabaixo.
Esquema de OperaoNome Nome da operao, geralmente o mesmo do
evento de entrada que a originou;
Responsabilidades Texto descritivo sobre as caractersticas
principais da operao, principalmente no que serefere s
responsabilidades da mesma;
Referncias Reads Itens.Nesta clusula devem ser relacionados
quais itens objeto necessita-se manipular (comacesso de leitura)
para executar a operao. Possvel uso da palavra-reservada
supplied(fornecido) precedendo um parmetro da operao;
RefernciasChanges
Itens.Anlogo clusula anterior, nesta devem ser relacionados
quais itens objeto necessita-semanipular (com acesso de
gravao/escrita) para executar a operao. Possvel uso
dapalavra-reservada new (novo) precedendo um Item-objeto, o que
indica que esta operaoir criar um novo objeto no estado do
sistema;
Sada Agentes_E_Eventos.Especificar, quando houver, eventos
gerados ao final da operao juntamente com osdestinatrios dos
mesmos. Portanto, uma lista com todos os agentes e os eventos que
aoperao deve lhes enviar. Cada Agente_E_Evento engloba o nome de um
agente e todosos eventos que lhe possam ser enviados;
Pr-condies Condio.Introduz predicado (lista de clusulas) que
define condies a serem assumidas para que aoperao possa ser
executada. Todas/cada clusula deve ser True para que o predicado
sejasatisfeito (E lgico). Referencia apenas parmetros ou partes do
estado que tenham sidodefinidos em Reads e Changes;
Ps-condies Condio.Introduz predicado (lista de clusulas) que
define os resultados (alteraes no estado dosistema e/ou eventos de
sada) aps a execuo da operao. Relaciona estado do sistemaantes e
depois de ter sido ativada a operao. Palavras-reservadas initial e
final podempreceder um identificador quando da necessidade de
especificar o estado do sistema antes eaps a execuo da operao.
Figura 3.4 Esquema de Operao com recursos UML para Contratos
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
3.5 - Modelo de Objetos do Sistema (Modelo Conceitual)Um modelo
de objetos apresenta um modelo do domnio do problema. Assim, as
classes e os
relacionamentos podem especificar conceitos pertencentes ao
ambiente do sistema, bem como os inerentesao prprio sistema.
Um Modelo de Objetos do Sistema representa um subconjunto de um
Modelo de Objetos
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti38
relacionado ao sistema a ser construdo. Este modelo ser derivado
do Modelo de Objetos excluindo-seas classes e relacionamentos que
pertenam unicamente ao ambiente do sistema e no ao prprio
sistema[Coleman, 1996].
Atividades e DependnciasO Modelo de Objetos do Sistema est
diretamente vinculado ao Modelo de Objetos, devendo-se
tambm observar informaes de requisitos que identifiquem agentes
do sistema, como Cenrios eModelo de Operaes.
Estratgias para ModelagemObservando-se os Cenrios e os Modelos
de Operaes, deve-se filtrar os Modelos de Objetos de
forma a manter apenas objetos necessrios prpria estrutura
interna do sistema. O mtodo Fusionorientava para que fosse criada
uma espcie de fronteira, atravs de uma linha pontilhada,
delimitando osobjetos do sistema e os agentes. No entanto, com a
UML poderemos utilizar a notao paraagentes/atores, atravs de
bonecos-palito, e os objetos que no forem nem agentes nem objetos
do sistema,sero excludos deste novo modelo.
Notaes para ModelagemAs notaes para o Modelo de Objetos do
Sistema sero padro UML onde a nica diferena da
notao do Diagrama de Classes UML (ver seo 3.3) a substituio de
algumas classes-agentes porbonecos-palito na funo de
atores/agentes, sendo este ltimo padro dos Diagramas de Use Case
(verseo 2.3).
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
3.6 - Verificao dos Modelos da Fase de AnliseSeguindo as
orientaes de [Coleman, 1996], nesta seo sero apresentadas algumas
diretrizes para
a verificao dos modelos de anlise no que se refere inteireza e
consistncia em relao aosrequisitos.
Inteireza com requisitos: releia com cuidado o documento de
requisitos e resolva quaisquer dvidascom o cliente/usurios. Em
seguida, verifique se:
Todos os cenrios possveis foram tratados pelo ciclo de
vida;Todas as operaes do sistema foram definidas com o uso de um
esquema de operaes;Todas as informaes estticas foram capturadas
pelo modelo de objetos do sistema;Todas as outras informaes esto
documentadas no glossrio de termos.Consistncia: essas verificaes
relacionam-se com a sobreposio entre os modelos de anlise.
Verifique se:Todas as classes, relacionamentos e atributos
mencionados no modelo de operaes aparecem nomodelo de objetos do
sistema. Todos os outros conceitos devem estar definidos no
glossrio de
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti39
termos ou em alguma outra fonte de referncia;A fronteira do
modelo de objetos do sistema consistente com a interface do sistema
fornecida pelomodelo ciclo-de-vida;Todas as operaes do sistema,
presentes no modelo ciclo-de-vida, possuem um esquema
deoperaes;Todos os identificados utilizados em todos modelos se
encontram do glossrio de termos.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti40
4. Fase de ProjetoA fase de Projeto caracteriza-se por
transformar as informaes modeladas durante a fase de Anlise
em estruturas arquiteturais de projeto com o objetivo de
viabilizar a implementao do sistema. Asinformaes da fase de Projeto
caracterizam a modelagem dinmica do sistema, principalmente em
termosdos objetos necessrios s operaes atravs da troca de mensagens
entre os mesmos. Ao final da fase deProjeto busca-se ter uma
estrutura hierrquica de classes e o refinamento do Modelo de
Objetos doSistema da fase de Anlise, o que ir caracterizar os
requisitos essenciais passagem para a fase deImplementao.Os
objetivos da fase de Projeto passam pela construo inicial dos
Grafos de Interao de Objetos, a partirdo qual so modeladas as
operaes do sistema atravs da troca de mensagens entre os
objetos.Posteriormente o Modelo de Objetos do Sistema poder ser
refinado de forma a viabilizar a estruturahierrquica de classes, ao
final do projeto, prevendo o incio da implementao.
A figura 4.1 oferece uma visualizao, atravs de use cases, da
estrutura a ser modelada durante afase de Projeto.
Figura 4.1 Fase de Projeto
4.1 - Conduo da Fase de ProjetoA fase de Projeto deve ser
conduzida buscando transformar as informaes da fase de Anlise
em
estruturas arquiteturais de projeto com o objetivo de viabilizar
a implementao do sistema. Asinformaes da fase de Projeto
caracterizam a modelagem dinmica do sistema principalmente em
termosdos objetos necessrios s operaes atravs da troca de mensagens
entre os mesmos.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti41
Tudo o que foi analisado deve ser observado para se iniciar a
fase de Projeto, onde deve-se construiras estruturas dinmicas de
trocas de mensagens entre os objetos necessrias para satisfazer os
Modelos deOperaes da fase de Anlise. Assim, para a modelagem dos
Grafos de Interao de Objetos devero serobservados os Modelos de
Objetos do Sistema, o Modelo de Operaes e o Modelo de Ciclo de
Vida.
Modelagem Fusion: Grafos de Interao de Objetos: utilizar notaes
padro UML do Diagrama deColaborao;
Ao final da fase de Projeto deve haver uma espcie de lapidao das
estruturas de classes de forma ase otimizar os Modelos de Objetos
do Sistema. Isto ser feito melhorando estes modelos atravs
derelacionamentos de agregao e atravs da montagem de uma estrutura
hierrquica de classes feita atravsde associaes de generalizao e
especilizao, estas ltimas comumente conhecidas como Grafos deHerana
dentro do mtodo Fusion.
Modelagem Fusion: Refinamento do Modelo de Objetos do Sistema:
utilizar notaes padro UML doDiagrama de Classes; Grafos de Herana:
utilizar notaes padro UML para estrutura de Herana do Diagramade
Classes;
4.2 - Grafos de Interao de ObjetosA abordagem dos Grafos de
Interao de Objetos visa representar a troca de mensagens entre
os
objetos para satisfazer as operaes modeladas na fase de Anlise.
Deve ser desenvolvido um Grafo deInterao de Objetos para cada
operao modelada no sistema.
Abaixo segue um esquema com a notao a ser utilizada para a
modelagem destes grafos, o qualadota o padro UML para Diagramas de
Colaborao.
Atividades e DependnciasA modelagem das trocas de mensagens
entre os objetos depende diretamente da observao dos
Modelos de Operaes, do Modelo de Objetos do Sistema e do Modelo
Ciclo de Vida em um segundoplano. A principal colaborao dos GIO
sero os mtodos que os objetos passaro a ter aps suamodelagem o que
fornece a estrutura dinmica do sistema em projeto.
Estratgias para ModelagemO primeiro passo para modelar as
interaes entre os objetos partir Modelos de Operaes,
geralmente com as operaes tendo o mesmo nome dos eventos de
entradas do Modelo Ciclo de Vida. Apartir da, deve ser gerado um
GIO para cada Modelo de Operao. Assim sendo, cada clusula doModelo
de Operaes dever ser observada buscando as informaes necessrias
para a modelagem dosGIO, conforme descrito abaixo.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti42
Notaes para Modelagem
Figura 4.2 Grafos de Interao de Objetos com notaes UML de
Diagramas de Colaborao
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
4.3 - Refinamento do Modelo de Objetos do SistemaO Modelo de
Objetos do Sistema, inicialmente construdo na fase de Anlise e
delimitado ao
domnio do sistema, deve agora ser refinado de forma a melhorar o
significado e a visualizao de suasestruturas.
Usaremos de dois mecanismos para melhorar nossos modelos, sendo
as associaes de Agregao eHerana, conforme descrito abaixo.
4.3.1 AgregaesA Agregao um mecanismo que permite construir uma
classe agregada a partir de outras classes
componentes e de relacionamentos de classes. Uma classe agregada
pode ser tratada como qualquer outraclasse, podendo possuir
atributos e participar de relacionamentos.
Atividades e DependnciasA identificao das agregaes depende
diretamente dos Modelos de Objetos do Sistema j
construdos at ento, podendo tambm ser necessrio consultar
documentos de requisitos para reconhecercaractersticas de
agregao.
Estratgias para ModelagemUma orientao bastante til para se
identificar agregaes diz respeito anlise da expresso
(geralmente contendo um verbo) existente no relacionamento entre
classes que esto prestes a se
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti43
agregarem. Em geral a agregao modela relacionamentos "parte de"
ou "contm um". Portanto, umaclasse que est associada a outra atravs
de um relacionamento do tipo "has a" forte cadidata agregao. Assim
sendo, uma forma de se identificar este tipo de associao , alm dos
requisitos deobjetos, identificar nos relacionamentos verbos ou
expresses verbais como: tem um, contm um, est em, parte de, ...
Notaes para ModelagemA modelagem das Agregaes utiliza de uma
notao grfica especfica, eliminando-se o nome doverbo/expresso
verbal relativa associao que est sendo substituda.
Figura 4.3 Agregao como parte da notao UML do Diagrama de
Classes
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
4.3.2 Herana - Estrutura Hierrquica de ClassesA Herana um tipo
de relacionamento onde a classe que herda (subclasse/subtipo)
possui todas as
propriedades da classe herdada (superclasse/supertipo), podendo
tambm possuir outras mais, o que noslevar a construir uma Estrutura
Hierrquica de Classes, objetivando-se assim a reutilizao de classes
emoutros projetos.
Atividades e DependnciasA identificao das Estruturas de Herana
tambm depende diretamente dos Modelos de Objetos do
Sistema j construdos at ento, sendo necessrio consultar as
mesmas Estruturas j construdas edocumentos de requisitos para
reconhecer caractersticas de herana, s vezes tambm citadas
comogeneralizaes/especializaes.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti44
Estratgias para ModelagemA orientao para se identificar
generalizaes/especializaes (herana) semalhante usada para
identificar agregaes e diz respeito anlise da expresso
(geralmente contendo um verbo) existente norelacionamento entre
classes envolvidas. A generalizao modela relacionamentos "tipo de"
ou " um".Portanto, uma classe que est associada a outra atravs de
um relacionamento do tipo "king of" ou "is a" forte cadidata a se
tornar subclasse de outra (superclasse).
Notaes para ModelagemA modelagem de Herana utiliza de uma notao
grfica especfica, tambm eliminando-se o nome doverbo/expresso
verbal relativa associao que est sendo substituda.
Figura 4.4 Herana como parte da notao UML do Diagrama de
Classes
Estudo de CasoSistSW01 (Apndice A);SistSW02 (Apndice B).
4.4 - "Visibilidade"O Documento
4.5 - Verificao dos Modelos da Fase de ProjetoNesta seo
apresenta-se orientaes para a verificao dos modelos de projeto em
relao
especificao da fase de anlise e s funcionalidades do sistema,
conforme [Coleman, 1996].Consistncia com a especificao do sistema:
verificar que somente as classes representadas nos
grafos de interao de objetos sejam consideradas como parte do
modelo de objetos do sistema paraposterior implementao. Novas
classes podero ser introduzidas durante a fase de projeto sem que
sejammostradas no modelo de objetos do sistema desenvolvido durante
a anlise.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti45
Verificao do efeito funcional: Verificar se o efeito funcional
de cada grafo de interao de objetos satisfaz especificao da
suaoperao definida no modelo de operaes.
Verificar se todas as clusulas Result do esquema de operaes
encontram-se satisfeitas.Refinamento do modelo de objetos do
sistema: Verificar se as associaes originais do modelo de objetos
do sistema foram devidamenteconvertidas, quando possvel, em
estruturas de agregao e generalizao para otimizao dorespectivo
modelo.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti46
5. Fase de ImplementaoA fase de Projeto de nosso trabalho ter
como caracterstica transformar as informaes modeladas
durante a fase de Projeto em estruturas de cdigo no formato de
prottipos de classes de objetos.Considerando que a modelagem dos
Grafos de Interao de Objetos permitiu a especificao dos
mtodos inerentes a cada classe de objeto e o Refinamento do
Modelo de Objetos do Sistema permitiu amelhora estrutural dos
mesmos, o objetivo agora ser escrever o cdigo-fonte relativo s
estruturas dosobjetos em termos de seus atributos e mtodos.
A proposta deste trabalho a flexibilidade, orientando apenas
para que seja gerado cdigo com asintaxe de uma linguagem de
programao orientada a objetos. Os exemplos sero construdos em C++
ouem Java, dependendo da comodidade em relao s atividades
desenvolvidas no curso.
A figura 5.1 oferece uma visualizao, atravs de use cases, da
estrutura a ser modelada durante afase de Projeto.
Figura 5.1 Fase de Implementao
5.1 - Conduo da Fase de ImplementaoA fase de Implementao deve
ser conduzida observando-se os modelos construdos
principalmente
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti47
durante a fase de Projeto juntamente com as especificaes
contidas no Glossrio de Termos. Lembra-seque sero montados
prottipos estruturais das classes de objetos projetadas, os quais
estaro formadospelo nome da classe, seus atributos e tipos e as
assinaturas dos mtodos.
Modelagem: No h regras notacionais para a estruturao das
classes, sugerindo-se apenas o uso da sintaxe de umalinguagem de
programao orientada a objetos.
5.2 - Gerao dos Prottipos e Estruturas de Classes de ObjetosA
estruturao das classes de objetos ser feita codificando-se estas
classes em linguagem de
programao orientada a objetos, escrevendo-se seus atributos e
assinaturas de mtodos, semnecessariamente implementar estes
ltimos.
Atividades e DependnciasA codificao das estruturas de classes
poder ser feita unicamente observando-se os modelos
gerados na fase de Projeto. Para quaisquer outras informaes pode
ser necessrio consultar o Glossriode Termos.
Estratgias para ModelagemPara que sejam identificadas quais
classes sero implementadas, deve-se observar quais delas so
necessrias s operaes do sistema. Portanto, os Grafos de Interao
de Objetos fornecem a informaosobre quais classes implementar.
Considerando, contudo, que houve o refinamento do Modelo de
Objetosdo Sistema aps a construo dos GIO, provavelmente a tarefa de
selecionar as classes a seremimplementadas j pode ter sido feita,
isto , atravs da excluso, do MOS, das classes desnecessrias
soperaes. Assim sendo, bastar observar o Modelo de Objetos do
Sistema.
Portanto, os atributos podem ser identificados no Modelo de
Objetos do Sistema e/ou Glossrio deTermos e os mtodos nos Grafos de
Interao de Objetos, caso ainda no tenham sido atualizados noModelo
de Objetos do Sistema.
5.3 - Verificao das Estruturas de Classes de ObjetosPara checar
as estruturas de classes, algumas verificaes bsicas sero
teis:Atributos de Dados: verificar que todos os atributos de dados
do Modelo de Objetos do Sistema
apaream nas estruturas de classes;Atributos Objeto: em geral as
estruturas de agregao identificadas nos Modelos de Objetos do
Sistema daro origem a atributos objeto;Mtodos e Parmetros:
garantir que todos os mtodos e argumentos dos Grafos de Interao
de
Objetos apaream nas estruturas de classes;Herana: verificar que
todas as estruturas de herana estejam registradas; garantir que as
estruturas
de classes contenham todos os mtodos comuns preliminarmente
definidos, respeitando as estruturas deherana.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti48
6. ConclusesA proposta de adaptao do Fusion para a UML ainda um
trabalho em andamento, considerando
que ainda existem modelos que no encontram similares na atual
verso da UML. No entanto, os objetivosesto sendo alcanados com as
atuais trocas de notaes.
O balano final do trabalho pode considerar que dos praticamente
oito modelos/tcnicasdesenvolvidos pelo Fusion, j se conseguiu
adaptar totalmente cinco deles. Cita-se o mapeamentocompleto do
Modelo de Objetos, o Modelo de Interfaces, enquanto tratamento dos
Cenrios e dos Modelode Operaes, o Modelo de Objetos do Sistema, o
Grafo de Interao de Objetos e os Grafos de Herana.Enquanto adaptaes
parciais, considera-se em vias de concluso o mapeamento do Modelo
Ciclo deVida. Por fim, cita-se tambm o estudo do Diagrama de
Componentes da UML para adaptao fase deImplementao do Fusion,
podendo vir a auxiliar o gerenciamento dos processos de codificao
dosistema de software.
Portanto, os resultados do trabalho somente no so totais em
virtude dos Grafos de Visibilidade,pois no caso das Descries de
Classes as mesmas so direcionadas especificamente para
cdigo-fonte.
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
Bibliografia
ALHIR, S. Si. UML in a Nutshell - A Desktop Quick Reference.
O'Reilly & Associates, 1998.BOOCH, G. Object-Oriented Analysis
and Design with Applications. Addison Wesley, 1994.COAD, P. &
YOURDON, E. Anlise Baseada em Objetos. Rio de Janeiro: Campus,
1992.COLEMAN, D. et All. Desenvolvimento Orientado a Objetos - O
Mtodo Fusion. Rio de Janeiro:
Campus, 1996.FOWLER, M. & SCOTT, Kendall. UML Distilled -
Applying the Standard Object Modeling Language.
Massachusetts: Addison-Wesley, 1997.GHEZZI, C. et All.
Fundamentals of Software Engineering. New Jersey, Prentice-Hall
International
Editions, 1991JACOBSON, I., CHRISTERSON, M., JONSSON, P. &
VERGAARD, G. Object-Oriented Software
Engineering: A Use Case Driven Approach. Addison-Wesley,
1992.LARMAN, Craig. Utilizando UML e Padres Uma Introduo Anlise e
ao Projeto Orientados a
Objetos. Porto Alegre: Editora Bookman, 2000.MARTIN, J. &
ODELL, J. J. Anlise e Projeto Orientados a Objeto. So Paulo:
MakronBooks, 1995.PAGE-JONES, M. O que Todo Programador Deveria
Saber Sobre Projeto Orientado a Objeto. So Paulo:
MakronBooks, 1997.PENKER, M. & ERIKSSON, H-E. UML Toolkit.
John Wiley, 1997.PRESSMAN, R. S. Engenharia de Software. So Paulo,
MakronBooks, McGraw-Hill, 1995.RUMBAUGH, J. et all. Object-Oriented
Modeling and Design. Prentice-Hall, 1991.SHLAER, S. & MELLOR,
S. J. Anlise de Sistemas Orientada para Objetos. So Paulo:
McGraw-Hill,
1990.WINBLAD, A. L. et alii. Software Orientado a Objeto. So
Paulo: Makron Books, 1993.BECK, Kent. & CUNNINGHAM, W. A
Laboratory For Teaching
Object-Oriented Thinking. OOPSLA'89 Conference
ProceedingsOctober, Louisiana, 1989.
http://c2.com/doc/oopsla89/paper.html
HEWLETT-PACKARD LABORATORIES - TEAM FUSION - Systematic Software
Development using UML.
http//www.hpl.hp.com/fusion/me_method.html
HEWLETT-PACKARD LABORATORIES - Fusion
Newsletter-Fevereiro/1997.http://www.hpl.hp.com/fusion/news/feb97.html
OBJECT MANAGEMENT GROUP - Technology Adoptions - UML
Documents.http://www.omg.org/library/schedule/Technology_Adoptions.htm#tbl_UML_Specification
RATIONAL SOFTWARE CORPORATION - Technical
Papers.http://www.rational.com/support/techpapers/...
-
Anlise e Projeto Orientados a Objetos
Por Maurcio F. Galimberti
Apndice A - Estudo de Caso MiniBib (Biblioteca
Departamental)