Professional Documents
Culture Documents
Departamento de Informática
Centro de Ciências Exatas e Tecnologia
Universidade de Caxias do Sul
Resumo
O presente trabalho propõe abordar a análise e projeto orientados a objetos a partir de um método
sistemático e didático, utilizando para construção de seus modelos um conjunto padronizado de notações.
Será adotado o método Fusion de análise e projeto de sistemas orientados a objetos, o qual se expande
com uma fase inicial de coleta e especificação de requisitos, conduzindo-a como um processo linear. As
demais fases de análise, projeto e implementação serão tratadas em um processo cíclico de evolução do
desenvolvimento de sistemas onde serão utilizadas as notações padrão UML (Unified Modeling
Language) para modelagem dos artefatos do sofware.
Palavras-chave: análise e projeto orientados a objetos; método orientado a objetos; método Fusion;
Unified Modeling Language (UML).
1
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
3
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Durante a execução do sistema os objetos podem ser construídos, executar ações, serem destruídos
4
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
ou se tornarem inacessíveis: modelo computacional dinâmico.
Assim sendo, os “átomos” do processo de computação são os objetos:
Objetos trocam mensagens entre si;
As mensagens resultam na ativação de métodos;
O emissor da mensagem não 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 de
maneira bem definida.
Entretanto, o paradigma orientado a objetos deve, além do processo de programação, abranger
também as demais fases do processo de desenvolvimento de sistemas computacionais em específico.
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 evolução de "novas"
tecnologias, este tema ainda proporciona novas propostas de abordagem para o assunto, gerando, ao
mesmo tempo, divergências e similaridades entre os diversos métodos.
Tendo como base este contexto, foram desenvolvidas as primeiras metodologias e também
abordagens parciais para tratar o assunto, como linguagens de especificação e métodos de projeto, por
exemplo.
Considerando-se como abordagens (métodos, técnicas, linguagens de especificação) conhecidas
mundialmente, e altamente influentes para este trabalho, cita-se: "Booch", de Grady Booch; "OMT (Object
Modeling Technique)", de James Rumbaugh; "OOSE (Object-Oriented Software Engineering)", de Ivar
Jacobson; "CRC (Class-Responsability-Collaboration)", técnica exploratória que orienta o
desenvolvimento através do registro das classes em cartões de referência. Estas abordagens serão melhor
comentadas na seção 1.1.1, sem contudo aprofundarmo-nos nas mesmas por não ser este nosso objetivo
com o presente trabalho.
Devido a esta miscelânea de métodos, surgiram duas boas abordagens com propostas de fusão de
conceitos, sendo elas: Fusion [Coleman, 1996] e UML (Unified Modeling Language) [OMG, 2001]. Estas
se caracterizam como a base de nossas atividades e serão devidamente apresentadas com o transcorrer
deste programa.
Atualmente sendo adotada como base para a prática da orientação a objetos nas disciplinas de
Análise e Projeto de Sistemas I e II, seguindo os currículos dos cursos de Bacharelado em Ciência da
Computação e Tecnologia em Processamento de Dados da Universidade de Caxias do Sul, o método
Fusion se apresenta bastante sistemático e didático para o processo de desenvolvimento de software
orientado a objetos, estabelecendo uma rota direta entre a definição dos requisitos e a implementação do
sistema. No entanto, os modelos por ele criados tornam-se às vezes bastante confusos devido a
similaridade de notação entre os mesmos. Além disso, o método não propõe abordagem para a definição
de requisitos, que é uma das fases iniciais do processo de produção de software, que precede as atividades
de “desenvolvimento”.
Já em relação à UML, – padrão estabelecido pela OMG (Object Management Group) – esta “é uma
linguagem gráfica para visualizar, especificar, construir e documentar os artefatos de um sistema de
software. A UML oferece uma forma padrão para se escrever/modelar projetos de sistemas, incluindo
conceitos, tais como processos de negócios e funções de sistema, bem como coisas concretas como
sentenças de linguagem de programação, projetos de bancos de dados e componentes reutilizáveis de
5
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
software” [OMG, 2001].
Mais especificamente, a UML se concretiza como um conjunto de notações bem definidas e
específicas para a construção dos diversos modelos necessários desde a definição de um sistema orientado
a objetos até a sua implementação.
A UML é a unificação e evolução das propostas de vários métodos de orientação a objetos, dentre
eles os principais métodos são Booch, OMT e OOSE, concebidos, respectivamente, por três autores de
renome internacional, sendo Grady Booch, James Rumbaugh e Ivar Jacobson (referenciados
mundialmente como "The Three Amigos"), que extraíram de suas metodologias anteriores aspectos
positivos de cada uma delas. Além disso, suas experiências mostraram que é ineficiente uma metodologia
estanque e que não se adeque a outros processos de desenvolvimento de software, o que os motivou à
criação da UML como uma linguagem flexível, que possa se adaptar a outras metodologias já existentes
ou que por ventura venham a ser criadas.
A partir deste quadro mundial, foi criada uma comissão internacional que iniciou um processo de
padronização da área de orientação a objetos, sendo atualmente a UML versão 1.3 (com proposta da
versão 1.4 em avaliação) reconhecida com exclusividade por esta comissão, denominada Object
Management Group (OMG) [OMG, 2001], como padrão de notação de construção de modelos orientados
a objetos.
Este contexto, aliado ao fato de existir proposta semelhante, quando da adequação da UML ao
processo Objectory de Engenharia de Software, através do trabalho "UML Extension for Objectory
Process for Software Engineering" [//??], vem a motivar o presente projeto, com o qual buscar-se-á
utilizar a UML para acrescentar clareza, eficiência e padronização à construção dos modelos propostos
pelo método Fusion. Além disso, permite a expansão do método Fusion em relação à fase inicial de
definição de requisitos, buscando-se enquadrar a notação da UML para a geração de modelos para esta
fase.
No entanto, a principal motivação para a criação deste trabalho vem da atual estrutura curricular dos
cursos do Dpto. de Informática desta Universidade e, consequentemente, da inserção de seus egressos no
mercado de desenvolvimento de software. Sendo estes cursos formadores de profissionais com perfis de
analistas e projetistas de software, considera-se que os mesmos devem cada vez mais se enquadrar ao
contexto mundial da tecnologia de orientação a objetos. Deve-se, portanto, considerar o processo
gradativo de mudança do paradigma estruturado pelo orientado a objetos, pelo qual passam as empresas
do setor de informática da região, o que as levará, certamente, à adoção de padrões estabelecidos para o
segmento de produção de software.
6
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
As vantagens em se ter um método sistemático para análise e projeto de sistemas (sistemas
orientados a objetos, no nosso caso) nem sempre são apreciadas. Entre elas temos [Coleman, 1996]:
Verificação de requisitos;
Conceitos mais claros;
Maior adequação do projeto ao problema;
Melhor decomposição do projeto para trabalho em equipe;
Melhor comunicação da equipe de desenvolvimento;
Menor esforço de manutenção;
No restante desta seção serão apresentadas as principais abordagens existentes para análise e projeto
de sistemas orientados a objetos. Na subseção 1.1.1 serão brevemente abordadas, conforme [Coleman,
1996], algumas das propostas pioneiras da orientação a objetos, as quais ainda contribuem em muito para
o desenvolvimento de software orientado a objetos, mas que não são o foco deste trabalho. Contudo, serão
enfatizados, nas seções subsequentes, o método Fusion (seção 1.1.2) e o padrão UML (seção 1.1.3) por se
caracterizarem como a base de nosso projeto.
PRÓS
Análise possui um processo bem definido
Modelos da análise com notações concisas e inteligíveis
CONTRAS
Relacionamento entre modelos da análise não é claro
Modelos da análise dificultam percepção do cenário global
Projeto não possui abordagem passo a passo
Não fica claro onde/quando deve-se começar projeto
PRÓS
Conjunto de notações abrangem todos os aspectos de um sistema orientado a objetos
CONTRAS
Notação complexa
Informações se duplicam entre os vários modelos
Ausência de processo bem-definido para o desenvolvimento de sistema
8
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Adota o termo agentes: usuários do sistema
Use Cases capturam funcionalidades do sistema
Demais modelos são construídos sobre use cases
Use cases -- elos de ligação entre as fases
REQUISITOS: declaração em linguagem natural.
Modelo Caso-de-Uso:
identifica agentes e seus casos-de-uso:
Modelo de Objetos do Domínio:
suporta os casos-de-uso: conceitos com o qual o sistema opera
notação similar a de um modelo E-R
Descrições da Interface com o Usuário:
esboços das janelas que os usuários verão na tela
envolve o usuário no processo de desenvolvimento
ANÁLISE: refina os modelos dos requisitos.
Modelo é uma forma de modelo E-R
Objetos e classes requeridos em cada use case
SUBSISTEMAS:
grupos de objetos com comportamento similar
critérios para agrupamento:
forte acoplamento entre objetos
flexibilidade para suportar mudanças nos requisitos
CONSTRUÇÃO: modelos da análise são refinados.
Modelo de Blocos:
Identifica blocos (abstração de blocos de código) do sistema
Cada bloco é composto por um ou mais objetos da análise
Diagrama de Interações:
Participação dos blocos (através de mensagens) com use cases
Modelo de Interface de Blocos:
Interface operacional: formada pela extração das operações realizadas sobre um bloco
Especificação de Blocos:
Modelo opcional sobre o comportamento interno do bloco: máquinas de estados
PRÓS
Contribui com o conceito de use case: base do processo
CONTRAS
Modelos e notações: inadequados e insuficientes
Difícil compreensão de alguns modelos
Dificuldade para verificar inteireza e/ou consistência do sistema desenvolvido
PRÓS
Como técnica exploratória (não é um método) é bastante avançada
Útil no projeto de estruturas de herança
Muito poderosa para o projeto das interações entre os objetos
CONTRAS
Cartões de referência: único registro para as decisões tomadas
Inadequadas para fins de manutenção
Não trata da criação/destruição de objetos
MÉTODOS FORMAIS
Abordagem de engenharia de software baseada na aplicação de matemática discreta à programação
de computadores
Propriedades do sistema são capturadas em um alto nível de abstração
Trabalhos recentes tentam estender estes métodos aos sistemas orientados a objetos
Alto custo de aceitação: exigido muito conhecimento matemático
Método promissor: a longo prazo
11
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Como operações serão implementadas pelas interações entre os objetos;
Como as classes farão referências mútuas e como irão se relacionar por herança;
Os atributos das classes e suas operações;
IMPLEMENTAÇÃO: transforma projeto em código.
Herança, referências e atributos são codificados nas classes específicas;
Interações entre objetos são transformadas nos métodos dos objetos;
Máquinas de estado são usadas para se reconhecer as sequências permitidas para as operações;
Também são consideradas técnicas de inspeção e teste para avaliação de sistemas orientados a
objetos.
DICIONÁRIOS DE DADOS: são adotados durante todo o processo de desenvolvimento e
identificam as entidades existentes no sistema.
Segue abaixo uma visão geral do método Fusion. São identificadas as fases e os modelos gerados
por cada uma delas e como estão interligados.
13
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
14
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
15
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Fase de Análise
A fase de Análise de nosso trabalho marca o início da investigação interna sobre o sistema e propõe
um conjunto de modelos a serem desenvolvidos conforme a figura 1.7. Considerando os ciclos planejados
na fase anterior, todos os modelos deverão ser construídos para cada ciclo. Portanto, as principais
informações modeladas durante a fase de Análise estarão nos Modelos de Objetos e Modelo de Interfaces.
No entanto, conforme a proposta cíclica, o primeiro passo desta fase sugere que os requisitos do ciclo em
questão sejam refinados antes de se iniciar o processo de modelagem dos objetos e operações.
16
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Fase de Projeto
A fase de Projeto caracteriza-se pela modelagem dinâmica do sistema principalmente em termos das
mensagens e dos objetos necessários às operações especificadas na fase de Análise. Portanto, conforme a
figura 1.8, as principais informações serão modeladas através dos Grafos de Interação de Objetos. Isto irá
viabilizar, para o final da fase de Projeto, que sejam feitos melhoramentos em nossos Modelos de Objetos,
buscando iniciar a fase de Implementação com as estruturas/protótipos de classes.
17
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Fase de Implementação
Nossa fase de implementação estará caracterizada em se traduzir informações, presentes
principalmente nos modelos da fase de Projeto, em Estruturas/Protótipos de Classes de Objetos, conforme
observa-se na figura 1.9.
18
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
19
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
20
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Descrição Inicial
Essa descrição expõe uma visão geral do sistema, citando quais módulos o compõem, quais as
necessidades que ele pretende atender e o resultado esperado após sua implementação.
Problema Original
É uma exposição da situação 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 se
está propondo.
Origem do sistema
21
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Esta cláusula deverá identificar se o projeto a ser desenvolvido será de um sistema “novo” ou será
uma manutenção para a atualização de um sistema “já existente”. No caso de ser uma atualização sobre
um sistema já existente, deve-se analisar o quanto do mesmo poderá ser aproveitado e qual será o volume
de alterações que necessitam ser realizadas sobre ele para que o mesmo possa suprir as necessidades dos
clientes. Também no caso da atualização, deve-se analisar a relação custo-benefício para que não seja
mais oneroso efetuar as alterações sobre o sistema existente do que desenvolver um sistema novo, já
voltado para as atuais necessidades.
Contexto de utilização
Esta cláusula consiste na descrição do ambiente onde o sistema irá atuar, tanto em nível local físico
quanto em relação ao tipo de agente que irá interagir com ele.
Limites do sistema
Esta cláusula definirá as responsabilidades do sistema dentro dos objetivos. Devem ser definidos
quais objetivos serão atendidos pelo sistema e quais deles ficarão sob responsabilidade dos usuários ou de
outros sistemas, evitando a criação de falsas expectativas por parte das pessoas envolvidas no projeto.
22
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
23
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Atividades e Dependências
Em geral os Use Cases poderão ser convertidos dos requisitos de nível 0. Contudo é possível que
sejam derivados diretamente dos objetivos quando estes possuírem requisitos de nível 0 simples ou em
pequena quantidade, o que pode ser mais conveniente para a geração do modelo de Use Cases.
24
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Estratégias para Modelagem
A orientação para modelagem dos Use Cases sugere que sejam derivados dos Objetivos
identificados anteriormente. Todavia, não sendo usada a abordagem por objetivos, pode-se partir da
especificação de requisitos listando-se possíveis Use Cases e, a partir disso, montar o diagrama
associando-os aos seus respectivos atores.
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
Atividades e Dependências
A construção das expressões ciclo de vida são baseadas nos Modelos dos Objetivos e na Visão de
Use Case do sistema.
25
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
gramatical para sua representação. Inicialmente serão utilizadas as notações Fusion até que sejam
mapeadas para UML. A sintaxe geral para o modelo ciclo de vida segue apresentada abaixo.
Life Cycle [Nome:] Expressão-Regular
(Nome-Local-Expressão = Expressão-Regular)*
-Alfabeto:
• qualquer evento de entrada ou saída pode ser utilizado em uma expressão
• eventos de saída: precedidos pelo símbolo #
-Operadores: sendo x e y expressões ciclo-de-vida:
• x . y denota x seguido por y
• x | y denota a ocorrência de x ou y
• x * denota zero ou mais ocorrências de x
• x + denota uma ou mais ocorrências de x
• [ x ] denota que x é opcional
• x | | y significa intercalação arbitrária de x e y
-Substituições
• Nome = expressão ciclo-de-vida
-Precedência de Operadores (ordem decrescente)
• [ ], *, +, . , | , | |
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
Atividades e Dependências
O planejamento dos ciclos, partindo de prazos estabelecidos e necessidades dos usuários, sugere a
estruturação de cronogramas de construção por ciclo. Assim sendo, as informações de objetivos e use
cases, bem como o ciclo de vida do sistema, devem ser o ponto inicial de observação para organizar os
ciclos por prioridades do sistema e dos usuários e preparar a passagem para as fases seguintes do processo
de construção do software.
Os ciclos devem ser planejados considerando o tempo para sua conclusão, tendo como objetivo sua
implantação e colocação em teste junto aos usuários. O objetivo é que cada ciclo seja estanque, sendo
26
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
necessária a sua conclusão para que possa ser encaminhado o início de um novo ciclo. Isto não inviabiliza
a construção incremental de ciclos, pois também se tem como objetivo o escalonamento do
desenvolvimento através de versões diferentes de construção dos use cases ou objetivos do sistema.
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
27
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
28
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
3. Fase de Análise
A função da fase de Análise é, baseada no documento de requisitos, ou seja, no resultado gerado
pelo documento do sistema, identificar as classes de objetos existentes no sistema, descrever os
relacionamentos entre elas e definir as operações que poderão ser executadas pelo sistema. A fase de
Análise mostra "o que" o sistema faz e não "como" ele é feito, obtendo-se ao final desta fase um
"documento de especificações".
A construção de dois modelos estáticos são os objetivos da fase de Análise, os quais tratam de
aspectos diferentes, sendo o Modelo de Objetos e o Modelo de Interfaces, este último sendo composto
pelos Cenários e seus Modelos de Ciclo de Vida e pelo Modelo de Operações. Assim, esta fase do
processo é responsável pelas seguintes descrições: classes de objetos (sem associar quaisquer métodos às
classes); relacionamentos entre classes; operações do sistema; sequência permissível de operações. No
entanto, a proposta de um processo cíclico exige que os requisitos a serem tratados sejam melhor
detalhados. Assim, a proposta para a fase de Análise prevê que os requisitos sejam refinados modelando-
os por Objetivo (Modelo de Requisitos por Objetivo) e adotando-se os Cenários para melhor visualizá-los.
A figura 3.1 oferece uma visualização, através de use cases, da estrutura a ser modelada durante a fase de
Análise.
30
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
juntamente com Atores dos Use Cases.
Atividades e Dependências
A construção dos cenários deve partir da especificação de requisitos, mais especificamente a partir
do Modelo de Objetivos e dos Use Cases. Seu desenvolvimento também depende do Modelo de
Requisitos por Objetivo, sugerindo que sejam construídos em paralelo.
31
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Notações para Modelagem
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
Atividades e Dependências
Como bem pode-se observar, a construção deste modelo está diretamente ligada ao Modelo de
Objetivos e aos Cenários.
Estudo de Caso
SistSW01 (Apêndice A);
32
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
SistSW02 (Apêndice B).
Atividades e Dependências
A modelagem dos objetos depende dos requisitos até então coletados para o ciclo em questão.
Devem ser observados os Cenários e os Modelos de Requisitos por Objetivo. A partir do segundo ciclo de
desenvolvimento, vale lembrar em observar os modelos de objetos já construídos, pois pode-se reutilizar
classes de objetos já modeladas.
33
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Notações para Modelagem
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
34
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
gerados na saída.
Atividades e Dependências
A construção das expressões ciclo de vida são baseadas nos Cenários e fundamentadas nos
requisitos especificados nos use cases e objetivos em questão no ciclo.
Estudo de Caso
SistSW01 (Apêndice A);
35
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
SistSW02 (Apêndice B).
Atividades e Dependências
A construção do Modelo de Operações depende praticamente de todas informações documentadas
até então para o ciclo em questão. A base da modelagem das operações, contudo, é formada pelo Modelo
de Objetos, Cenários e Ciclo de Vida além, é claro, das especificações de requisitos através do Modelo de
Requisitos por Objetivo.
36
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Notações para Modelagem
A modelagem das operações é feita de forma declarativa, adotando-se cláusulas da notação padrão UML
dos Contratos. As cláusulas devem estar dispostas em um “esquema de operação”, conforme sugestão
abaixo.
“Esquema” de Operação
Nome Nome da operação, geralmente o mesmo do evento de entrada que a originou;
Responsabilidades Texto descritivo sobre as características principais da operação, principalmente no que se
refere às responsabilidades da mesma;
Referências Reads Itens.
Nesta cláusula devem ser relacionados quais itens objeto necessita-se manipular (com
acesso de leitura) para executar a operação. Possível uso da palavra-reservada supplied
(fornecido) precedendo um parâmetro da operação;
Referências Itens.
Changes Análogo à cláusula anterior, nesta devem ser relacionados quais itens objeto necessita-se
manipular (com acesso de gravação/escrita) para executar a operação. Possível uso da
palavra-reservada new (novo) precedendo um Item-objeto, o que indica que esta operação
irá criar um novo objeto no estado do sistema;
Saída Agentes_E_Eventos.
Especificar, quando houver, eventos gerados ao final da operação juntamente com os
destinatários dos mesmos. Portanto, é uma lista com todos os agentes e os eventos que a
operação deve lhes enviar. Cada Agente_E_Evento engloba o nome de um agente e todos
os eventos que lhe possam ser enviados;
Pré-condições Condição.
Introduz predicado (lista de cláusulas) que define condições a serem assumidas para que a
operação possa ser executada. Todas/cada cláusula deve ser True para que o predicado seja
satisfeito (E lógico). Referencia apenas parâmetros ou partes do estado que tenham sido
definidos em Reads e Changes;
Pós-condições Condição.
Introduz predicado (lista de cláusulas) que define os resultados (alterações no estado do
sistema e/ou eventos de saída) após a execução da operação. Relaciona estado do sistema
antes e depois de ter sido ativada a operação. Palavras-reservadas initial e final podem
preceder um identificador quando da necessidade de especificar o estado do sistema antes e
após a execução da operação.
Figura 3.4 – “Esquema” de Operação com recursos UML para Contratos
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
37
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
relacionado ao sistema a ser construído. Este modelo será derivado do Modelo de Objetos “excluindo-se”
as classes e relacionamentos que pertençam unicamente ao ambiente do sistema e não ao próprio sistema
[Coleman, 1996].
Atividades e Dependências
O Modelo de Objetos do Sistema está diretamente vinculado ao Modelo de Objetos, devendo-se
também observar informações de requisitos que identifiquem agentes do sistema, como Cenários e
Modelo de Operações.
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
39
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
4. Fase de Projeto
A fase de Projeto caracteriza-se por transformar as informações modeladas durante a fase de Análise
em estruturas arquiteturais de projeto com o objetivo de viabilizar a implementação do sistema. As
informações da fase de Projeto caracterizam a modelagem dinâmica do sistema, principalmente em termos
dos objetos necessários às operações através da troca de mensagens entre os mesmos. Ao final da fase de
Projeto busca-se ter uma estrutura hierárquica de classes e o refinamento do Modelo de Objetos do
Sistema da fase de Análise, o que irá caracterizar os requisitos essenciais à passagem para a fase de
Implementação.
Os objetivos da fase de Projeto passam pela construção inicial dos Grafos de Interação de Objetos, a partir
do qual são modeladas as operações do sistema através da troca de mensagens entre os objetos.
Posteriormente o Modelo de Objetos do Sistema poderá ser refinado de forma a viabilizar a estrutura
hierárquica de classes, ao final do projeto, prevendo o início da implementação.
A figura 4.1 oferece uma visualização, através de use cases, da estrutura a ser modelada durante a
fase de Projeto.
40
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Tudo o que foi analisado deve ser observado para se iniciar a fase de Projeto, onde deve-se construir
as estruturas dinâmicas de trocas de mensagens entre os objetos necessárias para satisfazer os Modelos de
Operações da fase de Análise. Assim, para a modelagem dos Grafos de Interação de Objetos deverão ser
observados os Modelos de Objetos do Sistema, o Modelo de Operações e o Modelo de Ciclo de Vida.
Modelagem Fusion:
• Grafos de Interação de Objetos: utilizar notações padrão UML do Diagrama de
Colaboração;
Ao final da fase de Projeto deve haver uma espécie de lapidação das estruturas de classes de forma a
se otimizar os Modelos de Objetos do Sistema. Isto será feito melhorando estes modelos através de
relacionamentos de agregação e através da montagem de uma estrutura hierárquica de classes feita através
de associações de generalização e especilização, estas últimas comumente conhecidas como Grafos de
Herança dentro do método Fusion.
Modelagem Fusion:
• Refinamento do Modelo de Objetos do Sistema: utilizar notações padrão UML do
Diagrama de Classes;
• Grafos de Herança: utilizar notações padrão UML para estrutura de Herança do Diagrama
de Classes;
Atividades e Dependências
A modelagem das trocas de mensagens entre os objetos depende diretamente da observação dos
Modelos de Operações, do Modelo de Objetos do Sistema e do Modelo Ciclo de Vida em um segundo
plano. A principal colaboração dos GIO serão os métodos que os objetos passarão a ter após sua
modelagem o que fornece a estrutura dinâmica do sistema em projeto.
41
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Notações para Modelagem
Figura 4.2 – Grafos de Interação de Objetos com notações UML de Diagramas de Colaboração
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
4.3.1 Agregações
A Agregação é 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 outra
classe, podendo possuir atributos e participar de relacionamentos.
Atividades e Dependências
A identificação das agregações depende diretamente dos Modelos de Objetos do Sistema já
construídos até então, podendo também ser necessário consultar documentos de requisitos para reconhecer
características de agregação.
42
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
agregarem. Em geral a agregação modela relacionamentos "parte de" ou "contém um". Portanto, uma
classe que está associada a outra através de um relacionamento do tipo "has a" é forte cadidata à
agregação. Assim sendo, uma forma de se identificar este tipo de associação é, além dos requisitos de
objetos, identificar nos relacionamentos verbos ou expressões verbais como: tem um, contém um, está em,
é parte de, ...
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
Atividades e Dependências
A identificação das Estruturas de Herança também depende diretamente dos Modelos de Objetos do
Sistema já construídos até então, sendo necessário consultar as mesmas Estruturas já construídas e
documentos de requisitos para reconhecer características de herança, às vezes também citadas como
generalizações/especializações.
43
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
Estratégias para Modelagem
A orientação para se identificar generalizações/especializações (herança) é semalhante à usada para
identificar agregações e diz respeito à análise da expressão (geralmente contendo um verbo) existente no
relacionamento entre classes envolvidas. A generalização modela relacionamentos "tipo de" ou "é um".
Portanto, uma classe que está associada a outra através de um relacionamento do tipo "king of" ou "is a" é
forte cadidata a se tornar subclasse de outra (superclasse).
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
4.4 - "Visibilidade"
O Documento
45
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
5. Fase de Implementação
A fase de Projeto de nosso trabalho terá como característica transformar as informações modeladas
durante a fase de Projeto em estruturas de código no formato de protótipos de classes de objetos.
Considerando que a modelagem dos Grafos de Interação de Objetos permitiu a especificação dos
métodos inerentes a cada classe de objeto e o Refinamento do Modelo de Objetos do Sistema permitiu a
melhora estrutural dos mesmos, o objetivo agora será escrever o código-fonte relativo às estruturas dos
objetos em termos de seus atributos e métodos.
A proposta deste trabalho é a flexibilidade, orientando apenas para que seja gerado código com a
sintaxe de uma linguagem de programação orientada a objetos. Os exemplos serão construídos em C++ ou
em Java, dependendo da comodidade em relação às atividades desenvolvidas no curso.
A figura 5.1 oferece uma visualização, através de use cases, da estrutura a ser modelada durante a
fase de Projeto.
Atividades e Dependências
A codificação das estruturas de classes poderá ser feita unicamente observando-se os modelos
gerados na fase de Projeto. Para quaisquer outras informações pode ser necessário consultar o Glossário
de Termos.
47
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
6. Conclusões
A proposta de adaptação do Fusion para a UML ainda é um trabalho em andamento, considerando
que ainda existem modelos que não encontram similares na atual versão da UML. No entanto, os objetivos
estão sendo alcançados com as atuais “trocas” de notações.
O balanço final do trabalho pode considerar que dos praticamente oito modelos/técnicas
desenvolvidos pelo Fusion, já se conseguiu adaptar totalmente cinco deles. Cita-se o mapeamento
completo do Modelo de Objetos, o Modelo de Interfaces, enquanto tratamento dos Cenários e dos Modelo
de Operações, o Modelo de Objetos do Sistema, o Grafo de Interação de Objetos e os Grafos de Herança.
Enquanto adaptações parciais, considera-se em vias de conclusão o mapeamento do Modelo Ciclo de
Vida. Por fim, cita-se também o estudo do Diagrama de Componentes da UML para adaptação à fase de
Implementação do Fusion, podendo vir a auxiliar o gerenciamento dos processos de codificação do
sistema de software.
Portanto, os resultados do trabalho somente não são totais em virtude dos Grafos de Visibilidade,
pois no caso das Descrições de Classes as mesmas são direcionadas especificamente para código-fonte.
48
Por Maurício F. Galimberti
Análise e Projeto Orientados a Objetos
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. Análise Baseada em Objetos. Rio de Janeiro: Campus, 1992.
COLEMAN, D. et All. Desenvolvimento Orientado a Objetos - O Método 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, 1991
JACOBSON, I., CHRISTERSON, M., JONSSON, P. & ÖVERGAARD, G. Object-Oriented Software
Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.
LARMAN, Craig. Utilizando UML e Padrões – Uma Introdução à Análise e ao Projeto Orientados a
Objetos. Porto Alegre: Editora Bookman, 2000.
MARTIN, J. & ODELL, J. J. Análise e Projeto Orientados a Objeto. São Paulo: MakronBooks, 1995.
PAGE-JONES, M. O que Todo Programador Deveria Saber Sobre Projeto Orientado a Objeto. São Paulo:
MakronBooks, 1997.
PENKER, M. & ERIKSSON, H-E. UML Toolkit. John Wiley, 1997.
PRESSMAN, R. S. Engenharia de Software. São Paulo, MakronBooks, McGraw-Hill, 1995.
RUMBAUGH, J. et all. Object-Oriented Modeling and Design. Prentice-Hall, 1991.
SHLAER, S. & MELLOR, S. J. Análise de Sistemas Orientada para Objetos. São Paulo: McGraw-Hill,
1990.
WINBLAD, A. L. et alii. Software Orientado a Objeto. São Paulo: Makron Books, 1993.
BECK, Kent. & CUNNINGHAM, W. A Laboratory For Teaching
Object-Oriented Thinking. OOPSLA'89 Conference Proceedings
October, 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/...