Análise e Projeto OO com Fusion e UML

Análise e Projeto Orientados a Objetos
ANÁLISE E PROJETO ORIENTADOS A OBJETOS:

MÉTODO FUSION EXPANDIDO E ADAPTADO À UML
Por Maurício F. Galimberti

MFGalimb@ucs.tche.br
Departamento de Informática
Centro de Ciências Exatas e Tecnologia
Universidade de Caxias do Sul
Equipe do Projeto FILM

Coordenador:
Prof. MSc. Maurício F. Galimberti
Colaboradores:
Prof. MSc. José Eduardo C. Bussmann
Prof. MSc. Giovanni E. Rocco
Prof. MSc. Daniel L. Notari
Bolsistas:
Fabrício Lazzari
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
1. Introdução à Análise e Projeto de Sistemas Orientados a Objetos ................................................ 4

1.1 - Análise e Projeto Orientados a Objetos................................................................................ 6
1.1.1 - Métodos de Análise e Projeto Orientados a Objetos ...................................................... 7
1.1.2 - Método Fusion de Análise e Projeto Orientado a Objetos.............................................11
1.1.3 - Padrões de Modelagem de Objetos usando UML - Unified Modeling Language...........12
1.2 - Método Fusion Expandido e Adaptado à UML ...................................................................13
1.2.1 - Condução das Fases do Método de Especificação e Construção do Software................15
PARTE I - PROCESSO LINEAR...................................................................................................19
2.Fase de Estruturação e Especificação de Requisitos .....................................................................20
2.1 - Documento Contextual do Sistema .....................................................................................21
2.2 - Modelo de Objetivos ..........................................................................................................22
2.2.1 Estrutura dos Objetivos ..................................................................................................23
2.3 - Visão de Use Cases.............................................................................................................24
2.4 - Cenários e Ciclo de Vida do Sistema ..................................................................................25
2.5 - Planejamento dos Ciclos de Construção do Sistema............................................................26
2.6 - Manutenção de um Glossário de Termos ............................................................................27
PARTE II - PROCESSO CÍCLICO ................................................................................................28
3. Fase de Análise...........................................................................................................................29
3.1 - Condução da Fase de Análise .............................................................................................29
3.2 - Refinamento dos Requisitos por Ciclo ................................................................................31
3.2.1 Cenários do Sistema por Objetivo ..................................................................................31
3.2.2 Modelo de Requisitos por Objetivo ................................................................................32
3.3 - Modelo de Objetos (Modelo Conceitual) ............................................................................33
3.4 - Modelo de Interfaces ..........................................................................................................34
3.4.1 Cenários e Modelo Ciclo de Vida...................................................................................35
3.4.2 Modelo de Operações.....................................................................................................36
3.5 - Modelo de Objetos do Sistema (Modelo Conceitual) ..........................................................37
3.6 - Verificação dos Modelos da Fase de Análise ......................................................................38
4. Fase de Projeto ...........................................................................................................................40
4.1 - Condução da Fase de Projeto ..............................................................................................40
4.2 - Grafos de Interação de Objetos ...........................................................................................41
2
4.3 - Refinamento do Modelo de Objetos do Sistema..................................................................42

4.3.1 Agregações ....................................................................................................................42
4.3.2 Herança - Estrutura Hierárquica de Classes ....................................................................43
4.4 - "Visibilidade" .....................................................................................................................44
4.5 - Verificação dos Modelos da Fase de Projeto .......................................................................44
5. Fase de Implementação...............................................................................................................46
5.1 - Condução da Fase de Implementação .................................................................................46
5.2 - Geração dos Protótipos e Estruturas de Classes de Objetos .................................................47
5.3 - Verificação das Estruturas de Classes de Objetos................................................................47
6. Conclusões .................................................................................................................................48
Bibliografia ....................................................................................................................................49
Apêndice A - Estudo de Caso MiniBib (Biblioteca Departamental) ................................................50
3
1. Introdução à Análise e Projeto de Sistemas Orientados a Objetos

A orientação a objetos surgiu como uma abordagem de programação que procura explorar o nosso
lado intuitivo. Os "átomos" da computação orientada a objetos (os próprios objetos), são análogos aos
objetos existentes no mundo físico, o que produz um modelo de programação muito diferente da
tradicional visão "funcional" e "procedimental" [Coleman, 1996].
Modelo computacional orientado a funções:
Os "átomos" da computação são as funções;
Funções atuam sobre um único estado compartilhado;
Qualquer função pode atuar sobre qualquer parte do estado.
Figura 1.1 - Modelo Computacional Orientado a Funções [Coleman, 1996]

Neste modelo a estrutura não se altera com o passar do tempo, apesar de ocorrerem alterações nos
valores armazenados na mesma: modelo computacional estático.
Modelo computacional orientado a objetos:
A única maneira de se obter ou alterar o estado de um objeto é pelo envio de mensagens;
Cada objeto “é responsável” pela resposta a uma determinada mensagem;
Os objetos, quando compartilham uma única interface, são agrupados em classes;
Figura 1.2 - Modelo Computacional Orientado a Objetos, [Coleman, 1996]
Durante a execução do sistema os objetos podem ser construídos, executar ações, serem destruídos
4
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
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.
1.1 - Análise e Projeto Orientados a Objetos

Esta seção apresenta a importância de se ter, além do processo de programação, um método
sistemático que deve abranger também as demais fases do processo de desenvolvimento de sistemas
computacionais em específico.
Como principais características em se ter um método, cita-se:
Oferecer sistemática para as fases de definição de requisitos, análise, projeto e implementação;
Evitar codificação precoce: programas de difícil manutenção e que não satisfazem os requisitos do
usuário;
Métodos sistemáticos consomem mais tempo nas fases iniciais do desenvolvimento de software.
6
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.
1.1.1 - Métodos de Análise e Projeto Orientados a Objetos

Sem ter o objetivo de aprofundar os conhecimentos em quaisquer trabalhos abaixo, esta seção
descreve características básicas, a grande maioria sob o ponto de vista de [Coleman, 1996], sobre
propostas pioneiras na orientação a objetos. Desejando-se conhecer melhor estes trabalhos, são citadas
suas principais referências bibliográficas.
OMT (OBJECT MODELING TECHNIQUE) [Rumbaugh, 1991]

ANÁLISE: modelagem do mundo real.
Modelo de Objetos:
captura estrutura estática de um sistema:
classes e relacionamentos
atributos e operações que caracterizam cada classe
notação: diagrama E-R estendido
Modelo Dinâmico:
captura o comportamento dinâmico de cada classe:
máquina de estados: como objetos da classe respondem aos eventos
evento representa um estímulo externo
estado é uma abstração dos valores dos atributos e relacionamentos
Modelo Funcional:
mostra o que o sistema deve fazer: uso de DFDs
PROJETO: decisões a respeito dos subsistemas e aspectos gerais da arquitetura.
Projeto do Sistema:
divide em subsistemas
aloca processos e defini a arquitetura geral
Projeto de Objetos:
algoritmos dos métodos
determina métodos das classes
particiona projeto em módulos para a programação
7
IMPLEMENTAÇÃO: codificação do projeto dos objetos.
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
BOOCH [Booch, 1994]

Processo com natureza descritiva (o que podemos fazer) e não prescritiva (o que devemos fazer)
Notações (sem ordenamento do processo):
Diagramas de Classes:
classes e relacionamentos (estático): variação do E-R
esboços são produzidos no início do desenvolvimento e completados durante a
identificação dos relacionamentos
Diagramas de Objetos:
objetos e “relacionamentos” (dinâmico): troca de mensagens
esboços são produzidos no início do desenvolvimento e completados durante a
identificação dos relacionamentos
Diagramas de Tempo:
apresentam informações de ordenação (sem mensagens)
eixo-x (tempo ) e eixo-y (fluxo de controle entre os objetos)
também identificam tempo de criação e destruição de objetos
Diagramas de Estados:
transição de estados dos objetos
Diagramas de Módulos e Diagramas de Processos:
grafos identificam visão física do sistema
diagrama de Módulos:
alocação de classes e objetos em módulos e dependência dos módulos
Diagrama de Processos:
processadores, dispositivos e conexão de comunicação entre eles
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
OBJECTORY [Jacobson, 1992]

Baseia-se em use cases:
diálogo/transações entre o sistema e um usuário
8
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
CRC (CLASSE-RESPONSABILIDADE-COLABORADOR) [Beck, 1989]

IDENTIFICAR CLASSES E RESPONSABILIDADES:
Objetos são agrupados, gerando classes em cartões
Ações dos objetos transformadas em responsabilidades das classes: tarefas a serem
executadas pela classe
ATRIBUIR RESPONSABILIDADES:
Responsabilidades são alocadas às classes
Distribuição das tarefas do sistema
9
IDENTIFICAR COLABORAÇÕES:
Identificação das interações entre as classes: exame de cada par classe/responsabilidade
buscando suas dependências com outras classes
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
FUSION [Coleman, 1996]

O método Fusion caracteriza o centro dos estudos para nossa abordagem de orientação a objetos.
Portanto, neste contexto apenas é apresentada a figura 1.3 que representa o sentido de seu “batismo”, na
tradução de uma fusão de abordagens e métodos. Deixaremos os detalhes do método Fusion para a
subseção a seguir e, como bem será fundamentado, este método será visto ao longo de todo o nosso
trabalho.
Figura 1.3 - Método Fusion [Coleman, 1996]
UNIFIED MODELING LANGUAGE (UML) [OMG, 2001]

A UML, juntamente com o método Fusion, forma a base de nossos estudos. Portanto haverá uma
10
seção específica para tratá-la (seção 1.1.3). Neste momento vale lembrar apenas que a UML é uma
linguagem gráfica para visualizar, especificar, construir e documentar artefatos de sistemas de software.
Assim, a UML não se caracteriza como um método ou processo de construção de software, sendo este
fato, e a sua padronização, os avais para sua utilização em nosso trabalho, o que também poderá ser feito
em empresas de desenvolvimento que adotem métodos e processos proprietários/particulares para
construção de software.
1.1.2 - Método Fusion de Análise e Projeto Orientado a Objetos

O Fusion se caracteriza como um método de análise e projeto de sistemas voltado para a produção
de software orientado a objetos. Este método estabelece uma rota direta entre a definição dos requisitos e a
implementação do sistema, partindo, contudo, de uma definição de requisitos pré-estabelecida.
Para a condução das fases de análise e projeto, o método Fusion estabelece um conjunto conciso e
completo de notações bem-definidas.
A construção do software a partir do método Fusion considera um processo dividido em fases. O
Fusion estabelece o que deve ser feito em cada fase, orientando a sequência de ações de cada fase e os
critérios que suportam o ponto de passagem para as fases subsequentes.
O método Fusion não “cobre” a captura de requisitos. Portanto, o mesmo prevê que os requisitos
sejam fornecidos por usuários e documentados seguindo-se alguma técnica de elicitação e de
especificação de requisitos "qualquer".
Assim sendo, a divisão proposta pelo método Fusion para o processo de desenvolvimento é Análise,
Projeto e Implementação, conforme segue um breve resumo.
ANÁLISE: o que o sistema faz e não como é feito.
“Descobre” os objetos e as classes existentes no sistema e seus relacionamentos;
Define o comportamento esperado do sistema;
Modelos são produzidos para identificar:
Classes de objetos que existem no sistema;
Relacionamentos entre essas classes;
Operações que podem ser executadas no sistema;
Sequências permissíveis para eventos de entrada e de saída;
Não associa métodos às classes.
PROJETO: define como serão implementadas as operações do sistema através do comportamento
dos objetos em tempo de execução.
Operações são divididas em interações de objetos;
Operações são associadas às classes;
Como objetos farão referências mútuas entre si;
Relacionamentos de herança entre as classes;
Modelos do projeto identificam:
11
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.
Figura 1.4 - Estrutura do Método Fusion [Coleman, 1996]
1.1.3 - Padrões de Modelagem de Objetos usando UML - Unified Modeling Language

A UML teve seu desenvolvimento iniciado em outubro de 1994 quando Grady Booch e Jim
Rumbaugh, da Rational Software Corporation, começaram seus trabalhos de unificar os métodos Booch e
12
OMT. Em 1995 juntou-se com aqueles Ivar Jacobson e sua companhia uniu-se à Rational e seu método
OOSE passou a colaborar com a proposta da UML.
//?? Continuar com uma visão estrutural da UML a partir da OMG: não mais de uma ou duas
páginas. Procurar uma figura representativa.
1.2 - Método Fusion Expandido e Adaptado à UML

A proposta deste trabalho é resultado do projeto FILM, o qual está institucionalizado na
Universidade de Caxias do Sul pelo Departamento de Informática e tem como objetivo adaptar e expandir
o método Fusion de análise e projeto de sistemas orientado a objetos. Este ajuste do método também
expande o espectro do método Fusion, acrescentando ao mesmo a abordagem da fase inicial de
especificação de requisitos, a qual não é considerada na versão original do método Fusion [Galimberti,
2001].
Para a expansão do método e adequação de seus modelos, utiliza-se da proposta da Unified
Modeling Language (UML). A UML propõe flexibilidade aos diversos processos de desenvolvimento de
software, expandindo métodos orientados a objetos e disponibilizando um conjunto de notações para a
construção dos modelos da orientação a objetos [Galimberti, 2001].
Para a fase de Definição de Requisitos o projeto está baseado na proposta “Um Modelo de
Estruturação de Requisitos para o Método Fusion Adaptado à UML” [Rocco, 2001]. No entanto,
dependendo dos objetivos e carga horária de um curso de APOO, será possível partir de especificações
textuais e, preferencialmente, adoção de use cases para a definição de requisitos.
A estrutura geral proposta pelo projeto FILM está demonstrada na figura 1.5 abaixo, a qual foi
construída a partir das notações de use case da UML. Esta figura objetiva visualizar a estrutura geral
proposta através dos processos e de suas fases. A partir da seção 1.2.1 será oferecida uma visão mais
específica sobre as informações a serem documentadas em cada fase através de seus modelos.
13
Figura 1.5 – Estrutura do FILM com atores e processos (linear e cíclico)
14
1.2.1 - Condução das Fases do Método de Especificação e Construção do Software

O projeto FILM prevê as fases de Estruturação e Especificação de Requisitos, Análise, Projeto,
Implementação e Testes. A seguir serão apresentadas e comentadas as estruturas de cada uma das fases
propostas no projeto FILM e a serem abordadas nos capítulos posteriores.
Fase de Estruturação e Especificação de Requisitos

A metodologia a ser trabalhada inicia com a Fase de Estruturação e Especificação de Requisitos.
Considerando um processo linear para sua abordagem, deveremos documentar as informações que estão
sendo elicitadas conforme a figura 1.6 abaixo. Os principais documentos serão o Documento Contextual
do Sistema, Modelo de Objetivos, Visão de Use Case e Cenários e Ciclo de Vida do Sistema. O
Planejamento do restante do processo cíclico de desenvolvimento do sistema marca o encerramento desta
fase de Especificação de Requisitos.
Figura 1.6 - Fase de Estruturação e Especificação de Requisitos
15
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.
Figura 1.7 - Fase de Análise
16
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.
Figura 1.8 - Fase de Projeto
17
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.
Figura 1.9 - Fase de Implementação
18
PARTE I - PROCESSO LINEAR
Figura Parte I – Processo Linear
19
2. Fase de Estruturação e Especificação de Requisitos

A fase de Estruturação e Especificação de Requisitos será tratada através de um processo linear,
onde serão definidos os requisitos para todo o sistema em função de seus objetivos principais. Portanto,
esta fase se propõe a investigar e documentar o domínio do problema em estudo tendo como foco os
objetivos que serão buscados quando da preparação da solução do problema. Futuramente, após as
definições dos ciclos que se iniciam na fase de Análise, todos os requisitos voltarão a ser melhor
documentados a partir de outras ferramentas de modelagem.
Para facilitar o trabalho de documentação de requisitos, este capítulo orienta o estudante a buscar
um conjunto inicial de informações constantes do Documento Contextual do Sistema. Em seguida será
abordada uma técnica para se documentar requisitos a partir de objetivos, onde serão utilizados os
Modelos de Objetivos e a Visão de Use Cases para expressar os principais processos identificados no
domínio do problema em estudo. Logo após a construção dos use cases será descrita uma maneira de se
documentar a interação dos agentes/atores com o sistema e em que sequência isto pode ocorrer.
O tratamento dado aos requisitos antes da fase de Análise estará temporariamente encerrado com o
planejamento das fases seguintes em termos de processos cíclicos de construção do sistema.
Haverá, contudo, uma seção a parte no capítulo voltada a abordar a manutenção de um Glossários de
Termos, necessário durante todo o tempo em que será construído o sistema e que, por se constituir em
algo bastante simples, não mereceu um capítulo específico para seu estudo.
20
Figura 2.1 – Fase de Estruturação e Especificação de Requisitos
2.1 - Documento Contextual do Sistema

O Documento Contextual do Sistema é dividido em cinco cláusulas que ajudam a criar uma visão
macro do sistema. A partir deste documento já se pode ter uma idéia do sistema e seu enquadramento no
ambiente ao qual vai servir, podendo-se prever a viabilidade de construção do projeto.
A orientação é para que este documento contenha as cláusulas, ou seções, conforme abaixo:
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
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.
2.2 - Modelo de Objetivos

O processo de elicitação deve ser concomitante ao modelo de objetivos, o qual define a estruturação
das informações. A estrutura das informações prevê a definição do objetivo e a descrição dos objetos que
o compõem. São sugeridas questões que tem o propósito de descobrir, ante ao objetivo, os objetos
resultado, sujeitos, objetos e ferramentas, conforme as figuras 2.2 e 2.3.
Figura 2.2 – A definição de um objetivo [Rocco, 2001]
22
“Esquema” de Descrição de Objetivo

Objetivo Elicitadas as informações, pode-se definir um objetivo para o sistema em
questão. Descrição do objetivo, que em geral responde a um
questionamento por quê.
Resultado Qual o resultado esperado? Por que há a necessidade?
Objeto Para o que esse objetivo se faz necessário ao sistema?

Sujeito Quem atua em prol desse objetivo?
Ferramenta Quais são os recursos necessários para os sujeitos interagirem com o
objeto?
Figura 2.3 - Estrutura para a descrição de objetivo [Rocco, 2001]
2.2.1 Estrutura dos Objetivos

Esta estrutura tem por finalidade compor a estrutura hierárquica dos requisitos derivados de cada
objetivo. Neste momento apenas os requisitos de nível mais alto são abordados, pois para contemplar um
requisito outros requisitos podem ser necessários. Essa estrutura é dada pela associação entre objetivo e
requisitos e refinamentos entre os requisitos. O objetivo define uma atividade realizada no sistema,
enquanto que os requisitos definem as ações necessárias para a realização completa da atividade.
Essa abordagem hierárquica do modelo permite estruturar os requisitos em níveis verticais de
abstração, nos quais os requisitos são associados por qualificadores E, que indica requisitos
complementares, e por qualificadores OU, que indica requisitos opcionais para o atendimento à atividade
ou às ações hierarquicamente sobrejacentes. A figura 2.4 representa a estrutura dos objetivos.
Em uma primeira etapa do processo proposto, os requisitos são expressos somente em nível inicial,
ficando os demais requisitos derivados a serem identificados e definidos posteriormente, após o
estabelecimento dos ciclos prioritários para o desenvolvimento.
Figura 2.4 – Estrutura dos Objetivos [Rocco, 2001]
23
Figura 2.5 – Definição de Requisito [Rocco, 2001]
Descrição dos requisitos nível 0

Cada requisito é descrito segundo estrutura representada na figura 2.6, valendo lembrar que estes
requisitos são somente os de nível 0.
“Esquema” de Descrição de Requisito
Ação Nome: Nome: identificador da ação, como ela é reconhecida dentre os
casos de uso do sistema.
Descrição: Descrição: informação elicitada; tipicamente, uma narrativa como
os envolvidos descrevem a ação requerida ao software.
Agente Solicitante da ação; quem age. É o ente que emite um estímulo requerendo a
execução de alguma ação ao sistema.
Produto Objeto produzido por uma ação realizada na criação, transformação ou
destruição do objeto definido no objetivo. Desta maneira, os produtos do
requisito são composições dos objetos do objetivo.
Recurso Objeto que corresponde à interface entre o agente e o software, ou a informação
que o agente envia para os objetos do domínio do software para que possam
executar alguma ação em prol da produção de algum produto.
Anotação Descrições de requisitos não funcionais que compõem um requisito modelado.
Figura 2.6 – Estrutura para Descrição de um Requisito [Rocco, 2001]
2.3 - Visão de Use Cases

A seção de Use Cases da especificação de requisitos tem como objetivo apresentar uma estrutura
gráfica abrangendo o sistema a partir de seus principais processos e agentes. Portanto, a construção do
Diagrama de Use Cases apresenta os atores envolvidos no sistema que está sendo elicitado e com quais
processos os mesmos estão em contato.
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
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.
Notações para Modelagem
Figura 2.7 – Diagrama de Use Case
Estudo de Caso
SistSW01 (Apêndice A);
SistSW02 (Apêndice B).
2.4 - Cenários e Ciclo de Vida do Sistema

Dentro da fase de Especificação de Requisitos, a construção dos Cenários e do Ciclo de Vida tem
como finalidade visualizar a interação dos Atores com o sistema, em um alto nível através dos Use Cases,
e a sequência permissível de ocorrência/”execução” destes Use Cases, os quais serão convertidos em
Expressões Ciclo de Vida.
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.

A modelagem do ciclo de vida só pode ser feita dominando-se a sequência e repetições de
ocorrência dos Use Cases, caso isto ocorra. Portanto, observando-se os objetivos e requisitos, e os Use
Cases derivados, deve-se ter clareza do sequenciamento dos Use Cases para se estabelecer uma sentença
de Ciclo de Vida do sistema conforme ocorrência destes Use Cases.

A modelagem do ciclo de vida é feita de forma declarativa, necessitando-se de um conjunto
25
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
2.5 - Planejamento dos Ciclos de Construção do Sistema

A tarefa de planejar os ciclos de desenvolvimento do sistema não sugere atualmente nenhuma forma
específica de modelagem. As diretrizes básicas, contudo, orientam que os ciclos de construção do sistema
sejam programados com o objetivo de liberar pequenos módulos aos usuários para que possam ser
gradativamente testados e melhorados. A tendência é que cada ciclo não consuma mais de dois meses para
ser construído (analisado, projetado e implementado).
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
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
2.6 - Manutenção de um Glossário de Termos

O glossário de termos serve para documentar informações que requeiram melhores esclarecimentos,
de modo a melhorar a comunicação e evitar mal-entendidos. Originalmente denominado dicionário de
dados também no método Fusion, será referenciado como glossário de termos pelo seu caráter de registrar
não apenas dados, mas também quaisquer informações e restrições que não possam ser colocadas nos
diagramas construídos ao longo do processo de análise e projeto de sistemas.
Um glossário de termos representa uma ferramenta vital onde todas as definições feitas devem ser
encontradas. Manter o glossário de termos é uma atividade contínua durante todo processo de construção
do sistema e por menor que seja a descrição de um item, ainda assim é a melhor forma de deixar claro o
seu significado.
O método Fusion orienta para a construção de um glossário, porém não obriga a uma sintaxe e
notações específicas. Portanto, neste trabalho, é sugerida uma forma básica para documentação dos itens
através de tabelas. As coleções de itens de mesma categoria podem ser documentadas em tabelas
específicas, otimizando a localização dos termos.

Considerando que a manutenção do glossário de termos seja uma atividade constante durante todo o
processo de construção do sistema, orienta-se para que o mesmo seja atualizado ou durante a construção
dos diagramas ou logo após o encerramento dos mesmos. Segue abaixo uma sugestão de como estruturar
as informações dentro do glossário de termos.

A documentação do glossário, em geral, será possível através de uma tabela de três colunas como
abaixo. No entanto, conforme o momento do processo de construção do sistema, outras colunas poderão
ser acrescentadas para melhor descrever determinados termos.
Nome do Termo Categoria Descrição
Identificação do termo Designação do tipo do termo em Texto descritivo
modelado relação ao seu propósito de
modelagem
Figura 2.8 – Glossário de Termos
27
PARTE II - PROCESSO CÍCLICO
Figura Parte II - Processo Cíclico
28
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.
Figura 3.1 – Fase de Análise
3.1 - Condução da Fase de Análise

A fase de análise deve ser conduzida de forma a transformar as informações coletadas durante a fase
de definição de requisitos em modelos que representem as estruturas estáticas do sistema e o
comportamento do mesmo. No entanto, a partir da fase de Análise o sistema será modelado através de um
processo cíclico. Este processo foi estabelecido de forma a viabilizar a construção incremental do sistema.
29
Assim sendo, o primeiro passo da fase de Análise será estruturar o ciclo em questão, o que deve ser
feito com o aprimoramento dos requisitos documentados na fase anterior, caraterizando em um
refinamento dos requisitos a partir dos objetivos antes brevemente descritos. Inicialmente, anterior aos
detalhes dos requisitos, deve ser modelado o comportamento do sistema de forma a identificar quais são
as interações existentes entre o sistema, durante o(s) use case(s) em questão, e o meio em que está
inserido. Isto será feito através da representação de eventos de entrada e de saída entre o sistema, o qual
seve ser visto como uma caixa preta.
Modelagem Fusion:
Cenários do Sistema por Objetivo: utilizar notações padrão UML para Diagrama de
Sequências;
Modelagem de Refinamento de Requisitos:
Modelo de Requisitos por Objetivo: utilizar notações da abordagem de Requisitos por Objetivo
Com uma abordagem orientada a objetos, as primeiras modelagens devem representar as classes de
objetos através de conceitos relevantes à solução do problema em análise – em geral substantivos que
podem ser submetidos a uma lista de categorias, conforme [Larman, 2000] – identificados nas
informações até então documentadas. Estes conceitos serão modelados como classes de objetos que se
relacionam entre si através de restrições de cardinalidades. São identificados também os primeiros
atributos de cada classe de objeto. A sugestão inicial é que as associações (relacionamentos) sejam
simples, protelando-se associações dos tipos agregações, generalizações e especializações para um
momento mais propício da fase de Projeto.
Modelagem Fusion:
Modelo de Objetos: utilizar notações padrão UML do Diagrama de Classes.
As próximas informações a serem modeladas caracterizam-se por representar a estrutura
comportamental do sistema. O comportamento do sistema deve ser documentado de forma a identificar
quais são as interações existentes entre o sistema e o meio em que está inserido. Isto já deve ter sido feito
nos cenários através da representação de eventos de entrada e de saída entre o sistema, no entanto agora
deve ser modelada a sequência permissível para ocorrência destes eventos dentro do ciclo de vida do
sistema. Portanto, neste momento da fase de Análise deve-se modelar os eventos de entrada como
operações do sistema. Assim, as operações serão documentadas de forma a identificar quais estruturas de
objetos deverão ser manipuladas para realizar cada operação e suas responsabilidades. As operações
modelam os eventos de entrada e seus efeitos no sistema, os quais podem ser as alterações no estado do
sistema e/ou os eventos gerados na saída.
A fase de Análise será encerrada estabelecendo-se as fronteiras do sistema, no Modelo de Objetos,
em relação ao meio em que está inserido. Isto será feito com a construção do Modelo de Objetos do
Sistema, onde serão mantidas as estruturas de classes e associações necessárias às operações do sistema
juntamente com os atores/agentes que interagem com o mesmo.
Modelagem Fusion:
Modelo de Interfaces:
Modelo Ciclo de Vida: utilizar notações Fusion até adaptação à UML;
Modelo de Operações: utilizar notações padrão UML para Contratos;
Modelo de Objetos do Sistema: utilizar notações padrão UML do Diagrama de Classes
30
juntamente com Atores dos Use Cases.
3.2 - Refinamento dos Requisitos por Ciclo

Considerando o processo cíclico a ser abordado na fase de Análise, o primeiro passo agora é partir
dos requisitos documentados, na fase anterior, no formato de objetivos e aprimorar os conhecimentos
sobre 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.
Serão desenvolvidos os Cenários respectivos aos Use Case(s) em questão e os Modelos de Requisitos por
Objetivo.
3.2.1 Cenários do Sistema por Objetivo

Em paralelo à expansão dos requisitos, descritos na seção 3.2.2, deve ser modelado o
comportamento do sistema de forma a identificar quais são as interações existentes entre o sistema,
durante o(s) use case(s) em questão, e o meio em que está inserido. Isto será feito através da representação
de eventos de entrada e de saída entre o sistema, o qual deve ser visto como uma “caixa preta”.
Abaixo segue um esquema com a notação a ser utilizada para a modelagem dos Cenários, o qual
adota o padrão UML para Diagrama de Sequê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.

A principal orientação para montagem dos Cenários está na identificação dos atores e suas ações, o
que pode ser feito observando-se as cláusulas dos “Esquemas” de Descrição de Requisitos do objetivo em
questão. As principais cláusulas são “Ação”, “Agente” e “Recurso”.
31
Figura 3.2 – Cenários com notação UML de Diagrama de Sequência
Estudo de Caso
3.2.2 Modelo de Requisitos por Objetivo

Os requisitos deverão agora ser expandidos para o Objetivo em questão no ciclo. A estrutura a ser
utilizada é exatamente a mesma vista na seção 2.2 de Modelo de Objetivos, porém agora os requisitos
deverão ser melhor detalhados, abaixo do nível 0. Vale voltar e observar as figuras 2.4, 2.5 e 2.6.
Portanto, cada requisito será refinado conforme definição da figura 2.5, estando suas cláusulas
comentadas na seção 2.2.1, na figura 2.6.
Como bem pode-se observar, a construção deste modelo está diretamente ligada ao Modelo de
Objetivos e aos Cenários.

Partindo do Modelo de Objetivos, a cláusula “Ação” deve ser o ponto inicial de investigação para a
descrição do requisito em si, buscando-se definir outros objetos que compõem o requisito.

Ver seção 2.2.1, figura 2.6.
Estudo de Caso
32
3.3 - Modelo de Objetos (Modelo Conceitual)

A abordagem do modelo de objetos visa representar as classes de objetos através de conceitos
identificados nas informações até então documentadas. Estes conceitos serão modelados como classes de
objetos que se relacionam entre si através de associações e restrições de cardinalidades. São identificados
também os primeiros atributos de cada classe de objeto. A sugestão inicial é que as associações
(relacionamentos) sejam simples, protelando-se associações dos tipos agregações, generalizações e
especializações para um momento mais propício da fase de Projeto.
Abaixo segue um esquema com a notação a ser utilizada para a modelagem dos objetos, o qual adota
o padrão UML para Diagrama de Classes.
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.

Uma das tarefas mais complicadas quando se começa a modelar objetos é a identificação das classes
de objetos. Várias são as técnicas utilizadas para sua modelagem, no entanto não existe nenhuma fórmula
mágica para este fim.
O procedimento básico, contudo, é partir das especificações de requisitos correspondentes ao ciclo
em questão. Nossa sugestão é utilizar de duas técnicas em conjunto, sendo a técnica 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 especificação de
requisitos, os quais serão candidatos a classes. A partir daí deve-se buscar sua identificação nas tabelas de
categorias de [Larman, 2000] buscando qualificar o conceito como classe de objeto ou como atributo. A
lista de substantivos gerada também facilita a eliminação de redundâncias (conceitos de objetos
semelhantes ou repetidos).
Busque não modelar chaves (primárias, estrangeiras, ...) como em bancos de dados. Isto deverá ser
feito no momento de mapear as classes de objetos para uma estrutura de dados persistentes.
33
Figura 3.3 – Modelo de Objetos com Notações UML do Diagrama de Classes
Estudo de Caso
3.4 - Modelo de Interfaces

O comportamento do sistema deve ser documentado de forma a identificar quais são as interações
existentes entre o sistema e o meio em que está inserido. Isto já deve ter sido feito através da
representação de eventos de entrada e de saída entre o sistema, através dos Cenários anteriores, mas agora
deve ser modelada a sequência permissível para ocorrência destes eventos dentro do ciclo de vida do
sistema. A fase de Análise se encerra modelando-se os eventos de entrada como operações do sistema.
Portanto, as operações serão documentadas de forma a identificar quais estruturas de objetos deverão estar
disponíveis para realizar cada operação e suas responsabilidades. As operações modelam os eventos de
entrada e seus efeitos no sistema, os quais podem ser as alterações no estado do sistema e os eventos
34
gerados na saída.
3.4.1 Cenários e Modelo Ciclo de Vida

Dentro do Modelo de Interfaces, a construção do Ciclo de Vida tem como finalidade modelar a
sequência permissível de ocorrência dos eventos de entrada e de saída, considerando que os Cenários,
construídos no início da fase de Análise, não tem este propósito.
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.

A modelagem do ciclo de vida só pode ser feita dominando-se a sequência e repetições de
ocorrência dos eventos previamente modelados. Portanto, deve-se ter clareza do funcionamento do use
case em questão e dos requisitos para se alcançar o objetivo que está sendo abordado. Lembra-se que foi
especificado, ainda na fase de Definição de Requisitos, um Modelo Ciclo de Vida baseado em use cases, o
que facilita o refinamento de suas expressões/subexpressões.

A modelagem do ciclo de vida é feita de forma declarativa, necessitando-se de um conjunto
gramatical para sua representação. Inicialmente serão utilizadas as notações Fusion até que sejam
mapeadas para UML. O conjunto notacional está especificado abaixo, sendo o mesmo descrito na seção
2.4.
-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
35
3.4.2 Modelo de Operações

A construção do modelo de operações marca o momento do processo em que se começa a investigar
as estruturas internas do sistema em construção. As operações serão modeladas através de fichas com um
conjunto de cláusulas. Cada cláusula tem seu propósito de transformar os requisitos do objetivo em
referências às estruturas até então modeladas como objetos. Portanto, cada evento de entrada se
transformará em uma operação, merecendo uma ficha/esquema de modelagem, a partir da qual serão
documentadas as responsabilidades da operação e os efeitos causados ao sistema após sua execução.
Possíveis resultados associados a uma operação do sistema, são:
Criar uma nova instância de classe;
Alterar atributos de objetos existentes/instanciados;
Criar/eliminar “tuplas” de relacionamentos;
Envia um evento a um agente.
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.

A estratégia para modelagem das operações deve iniciar observando-se os Cenários e as expressões
Ciclo de Vida do ciclo, transformando cada evento de entrada em uma ficha de operação. A partir disso,
as tarefas restantes terão o propósito de preencher as demais cláusulas do esquema de operações.
36
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
3.5 - Modelo de Objetos do Sistema (Modelo Conceitual)

“Um modelo de objetos apresenta um modelo do domínio do problema. Assim, as classes e os
relacionamentos podem especificar conceitos pertencentes ao ambiente do sistema, bem como os inerentes
ao próprio sistema.
Um Modelo de Objetos do Sistema representa um subconjunto de um Modelo de Objetos
37
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].
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.

Observando-se os Cenários e os Modelos de Operações, deve-se filtrar os Modelos de Objetos de
forma a manter apenas objetos necessários à própria estrutura interna do sistema. O método Fusion
orientava para que fosse criada uma espécie de fronteira, através de uma linha pontilhada, delimitando os
objetos do sistema e os agentes. No entanto, com a UML poderemos utilizar a notação para
agentes/atores, através de bonecos-palito, e os objetos que não forem nem agentes nem objetos do sistema,
serão excluídos deste “novo” modelo.

As notações para o Modelo de Objetos do Sistema serão padrão UML onde a única diferença da
notação do Diagrama de Classes UML (ver seção 3.3) é a substituição de algumas classes-agentes por
bonecos-palito na função de atores/agentes, sendo este último padrão dos Diagramas de Use Case (ver
seção 2.3).
Estudo de Caso
3.6 - Verificação dos Modelos da Fase de Análise

Seguindo as orientações de [Coleman, 1996], nesta seção serão apresentadas algumas diretrizes para
a verificação dos modelos de análise no que se refere à inteireza e à consistência em relação aos
requisitos.
Inteireza com requisitos: releia com cuidado o documento de requisitos e resolva quaisquer dúvidas
com o cliente/usuários. Em seguida, verifique se:
Todos os cenários possíveis foram tratados pelo ciclo de vida;
Todas as operações do sistema foram definidas com o uso de um esquema de operações;
Todas as informações estáticas foram capturadas pelo modelo de objetos do sistema;
Todas as outras informações estão documentadas no glossário de termos.
Consistência: essas verificações relacionam-se com a sobreposição entre os modelos de análise.
Verifique se:
Todas as classes, relacionamentos e atributos mencionados no modelo de operações aparecem no
modelo de objetos do sistema. Todos os outros conceitos devem estar definidos no glossário de
38
termos ou em alguma outra fonte de referência;
A fronteira do modelo de objetos do sistema é consistente com a interface do sistema fornecida pelo
modelo ciclo-de-vida;
Todas as operações do sistema, presentes no modelo ciclo-de-vida, possuem um esquema de
operações;
Todos os identificados utilizados em todos modelos se encontram do glossário de termos.
39
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.
Figura 4.1 – Fase de Projeto
4.1 - Condução da Fase de Projeto

A fase de Projeto deve ser conduzida buscando transformar as informações da 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.
40
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;
4.2 - Grafos de Interação de Objetos

A abordagem dos Grafos de Interação de Objetos visa representar a troca de mensagens entre os
objetos para satisfazer as operações modeladas na fase de Análise. Deve ser desenvolvido um Grafo de
Interação de Objetos para cada operação modelada no sistema.
Abaixo segue um esquema com a notação a ser utilizada para a modelagem destes grafos, o qual
adota o padrão UML para Diagramas de Colaboração.
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.

O primeiro passo para modelar as interações entre os objetos é partir Modelos de Operações,
geralmente com as operações tendo o mesmo nome dos eventos de entradas do Modelo Ciclo de Vida. A
partir daí, deve ser gerado um GIO para cada Modelo de Operação. Assim sendo, cada cláusula do
Modelo de Operações deverá ser observada buscando as informações necessárias para a modelagem dos
GIO, conforme descrito abaixo.
41
Figura 4.2 – Grafos de Interação de Objetos com notações UML de Diagramas de Colaboração
Estudo de Caso
4.3 - Refinamento do Modelo de Objetos do Sistema

O Modelo de Objetos do Sistema, inicialmente construído na fase de Análise e delimitado ao
domínio do sistema, deve agora ser refinado de forma a melhorar o significado e a visualização de suas
estruturas.
Usaremos de dois mecanismos para melhorar nossos modelos, sendo as associações de Agregação e
Herança, conforme descrito abaixo.
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.
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.

Uma orientação bastante útil para se identificar agregações diz respeito à análise da expressão
(geralmente contendo um verbo) existente no relacionamento entre classes que estão prestes a se
42
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, ...

A modelagem das Agregações utiliza de uma notação gráfica específica, eliminando-se o nome do
verbo/expressão verbal relativa à associação que está sendo substituída.
Figura 4.3 – Agregação como parte da notação UML do Diagrama de Classes
Estudo de Caso
4.3.2 Herança - Estrutura Hierárquica de Classes

A Herança é um tipo de relacionamento onde a classe que herda (subclasse/subtipo) possui todas as
propriedades da classe herdada (superclasse/supertipo), podendo também possuir outras mais, o que nos
levará a construir uma Estrutura Hierárquica de Classes, objetivando-se assim a reutilização de classes em
outros projetos.
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
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).

A modelagem de Herança utiliza de uma notação gráfica específica, também eliminando-se o nome do
verbo/expressão verbal relativa à associação que está sendo substituída.
Figura 4.4 – Herança como parte da notação UML do Diagrama de Classes
Estudo de Caso
4.4 - "Visibilidade"
O Documento
4.5 - Verificação dos Modelos da Fase de Projeto

Nesta seção apresenta-se orientações para a verificação dos modelos de projeto em relação à
especificação da fase de análise e às funcionalidades do sistema, conforme [Coleman, 1996].
Consistência com a especificação do sistema: verificar que somente as classes representadas nos
grafos de interação de objetos sejam consideradas como parte do modelo de objetos do sistema para
posterior implementação. Novas classes poderão ser introduzidas durante a fase de projeto sem que sejam
mostradas no modelo de objetos do sistema desenvolvido durante a análise.
44
Verificação do efeito funcional:
• Verificar se o efeito funcional de cada grafo de interação de objetos satisfaz à especificação da sua
operação definida no modelo de operações.
• Verificar se todas as cláusulas Result do esquema de operações encontram-se satisfeitas.
Refinamento do modelo de objetos do sistema:
• Verificar se as associações originais do modelo de objetos do sistema foram devidamente
convertidas, quando possível, em estruturas de agregação e generalização para otimização do
respectivo modelo.
45
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.
Figura 5.1 – Fase de Implementação
5.1 - Condução da Fase de Implementação

A fase de Implementação deve ser conduzida observando-se os modelos construídos principalmente
46
durante a fase de Projeto juntamente com as especificações contidas no Glossário de Termos. Lembra-se
que serão montados protótipos estruturais das classes de objetos projetadas, os quais estarão formados
pelo nome da classe, seus atributos e tipos e as “assinaturas” dos métodos.
Modelagem:
• Não há regras notacionais para a estruturação das classes, sugerindo-se apenas o uso da sintaxe de uma
linguagem de programação orientada a objetos.
5.2 - Geração dos Protótipos e Estruturas de Classes de Objetos

A estruturação das classes de objetos será feita codificando-se estas classes em linguagem de
programação orientada a objetos, escrevendo-se seus atributos e “assinaturas” de métodos, sem
necessariamente implementar estes últimos.
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.

Para que sejam identificadas quais classes serão implementadas, deve-se observar quais delas são
necessárias às operações do sistema. Portanto, os Grafos de Interação de Objetos fornecem a informação
sobre quais classes implementar. Considerando, contudo, que houve o refinamento do Modelo de Objetos
do Sistema após a construção dos GIO, provavelmente a tarefa de selecionar as classes a serem
implementadas já pode ter sido feita, isto é, através da “exclusão”, do MOS, das classes desnecessárias às
operações. Assim sendo, bastará observar o Modelo de Objetos do Sistema.
Portanto, os atributos podem ser identificados no Modelo de Objetos do Sistema e/ou Glossário de
Termos e os métodos nos Grafos de Interação de Objetos, caso ainda não tenham sido atualizados no
Modelo de Objetos do Sistema.
5.3 - Verificação das Estruturas de Classes de Objetos

Para checar as estruturas de classes, algumas verificações básicas serão úteis:
Atributos de Dados: verificar que todos os atributos de dados do Modelo de Objetos do Sistema
apareçam nas estruturas de classes;
Atributos Objeto: em geral as estruturas de agregação identificadas nos Modelos de Objetos do
Sistema darão origem a atributos objeto;
Métodos e Parâmetros: garantir que todos os métodos e argumentos dos Grafos de Interação de
Objetos apareçam nas estruturas de classes;
Herança: verificar que todas as estruturas de herança estejam registradas; garantir que as estruturas
de classes contenham todos os métodos comuns preliminarmente definidos, respeitando as estruturas de
herança.
47
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
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/...

Apêndice A - Estudo de Caso MiniBib (Biblioteca Departamental)

Análise e Projeto OO com Fusion e UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Análise e Projeto OO com Fusion e UML

Uploaded by

Copyright:

Available Formats

Análise e Projeto Orientados a Objetos

ANÁLISE E PROJETO ORIENTADOS A OBJETOS:

Por Maurício F. Galimberti

Equipe do Projeto FILM

1. Introdução à Análise e Projeto de Sistemas Orientados a Objetos ................................................ 4

4.3 - Refinamento do Modelo de Objetos do Sistema..................................................................42

1. Introdução à Análise e Projeto de Sistemas Orientados a Objetos

Figura 1.1 - Modelo Computacional Orientado a Funções [Coleman, 1996]

Figura 1.2 - Modelo Computacional Orientado a Objetos, [Coleman, 1996]

1.1 - Análise e Projeto Orientados a Objetos

1.1.1 - Métodos de Análise e Projeto Orientados a Objetos

OMT (OBJECT MODELING TECHNIQUE) [Rumbaugh, 1991]

BOOCH [Booch, 1994]

OBJECTORY [Jacobson, 1992]

CRC (CLASSE-RESPONSABILIDADE-COLABORADOR) [Beck, 1989]

FUSION [Coleman, 1996]

Figura 1.3 - Método Fusion [Coleman, 1996]

UNIFIED MODELING LANGUAGE (UML) [OMG, 2001]

1.1.2 - Método Fusion de Análise e Projeto Orientado a Objetos

Figura 1.4 - Estrutura do Método Fusion [Coleman, 1996]

1.1.3 - Padrões de Modelagem de Objetos usando UML - Unified Modeling Language

1.2 - Método Fusion Expandido e Adaptado à UML

Figura 1.5 – Estrutura do FILM com atores e processos (linear e cíclico)

1.2.1 - Condução das Fases do Método de Especificação e Construção do Software

Fase de Estruturação e Especificação de Requisitos

Figura 1.6 - Fase de Estruturação e Especificação de Requisitos

Figura 1.7 - Fase de Análise

Figura 1.8 - Fase de Projeto

Figura 1.9 - Fase de Implementação

PARTE I - PROCESSO LINEAR

Figura Parte I – Processo Linear

2. Fase de Estruturação e Especificação de Requisitos

Figura 2.1 – Fase de Estruturação e Especificação de Requisitos

2.1 - Documento Contextual do Sistema

2.2 - Modelo de Objetivos

Figura 2.2 – A definição de um objetivo [Rocco, 2001]

“Esquema” de Descrição de Objetivo

Objeto Para o que esse objetivo se faz necessário ao sistema?

2.2.1 Estrutura dos Objetivos

Figura 2.4 – Estrutura dos Objetivos [Rocco, 2001]

Figura 2.5 – Definição de Requisito [Rocco, 2001]

Descrição dos requisitos nível 0

2.3 - Visão de Use Cases

Notações para Modelagem

Figura 2.7 – Diagrama de Use Case

2.4 - Cenários e Ciclo de Vida do Sistema

Estratégias para Modelagem

Notações para Modelagem

2.5 - Planejamento dos Ciclos de Construção do Sistema

2.6 - Manutenção de um Glossário de Termos

Estratégias para Modelagem

Notações para Modelagem

PARTE II - PROCESSO CÍCLICO

Figura Parte II - Processo Cíclico

Figura 3.1 – Fase de Análise

3.1 - Condução da Fase de Análise

3.2 - Refinamento dos Requisitos por Ciclo

3.2.1 Cenários do Sistema por Objetivo

Estratégias para Modelagem

Figura 3.2 – Cenários com notação UML de Diagrama de Sequência

3.2.2 Modelo de Requisitos por Objetivo

Estratégias para Modelagem

Notações para Modelagem