ANÁLISE OO
Aspectos Avançados em
Engenharia de Software
Aula 2
Fernanda Campos
UFJF/DCC
INICIANDO A ANÁLISE






Quando um software precisa ser desenvolvido?
Como caracterizá-lo para a orientação a Objetos?
Quais os objetos relevantes?
Como eles se relacionam?
Como os objetos se comportam no contexto do
software?
Como especificar ou modelar o problema para
desenvolver um projeto efetivo?
ANÁLISE OO
A análise OO busca responder
a essas questões, sendo ela a
primeira atividade do processo
de desenvolvimento.
PRINCÍPIOS DO MODELO DE
ANÁLISE





Modelar o domínio da aplicação
Descrever os módulos de funções
Representar o modelo de comportamento
Particionar os modelos para expor melhor os
detalhes
Modelos iniciais representam a essência do
problema, enquanto os modelos posteriores
fornecem detalhes de implementação.
OBJETIVO DA ANÁLISE OO
O
objetivo da AOO é definir
todas as classes
(relacionamentos e
comportamento) que são
relevantes para a solução do
problema a ser resolvido.
TAREFAS DA OOA
1. Requisitos básicos do usuário devem ser comunicados entre
usuário e engenheiro de software.
2. Classes devem ser identificadas (atributos e métodos devem
ser definidos)
3. Uma hierarquia de classes deve ser especificada
4. Relacionamentos objetos para objetos (conexões) devem ser
representados
5. O comportamento de cada objeto deve ser modelado
Tarefas de 1 a 5 devem ser interativamente repetidas até que o
modelo se complete.
ANÁLISE OO


Em vez de examinar o problema numa
abordagem entrada-processamentosaída a OO introduz uma concepção
mais natural.
Parte da observação do comportamento
dos objetos.
ANÁLISE OO



O objetivo da AOO é desenvolver uma série de
modelos que descrevam como o software
funciona para atender aos requisitos do
usuário.
Constrói um modelo de análise em múltiplas
partes para satisfazer os objetivos.
O modelo de análise depende de informações,
funções e comportamentos no contexto dos
requisitos do software.
MODELOS DE OOA





Método de Booch
Modelo de Coad e Yordon
Método de Jacobson
Modelo de Rambaugh
Modelo de Wirts-Brock
UML - Unified Modeling Language
Rumbaugh
Booch
Odell
Jacobson
UML
Meyer
Shlaer-Mellor
Harel
Gamma et al.
Fusion
Wirfs-Brock
Representação de um sistema
em UML


Cinco visões cada uma definida por um
conjunto de diagramas:
Visão do modelo do usuário
•
representa o sistema a partir da perspectiva do
usuário, atores em UML.
• Casos de uso

Visão do modelo estrutural
•
Dados e funcionalidades são vistos de dentro do
sistema, a estrutura estática é modelada (classes,
objetos e relacionamentos).
• Diagrama de classes
Representação de um sistema
em UML

Visão do modelo comportamental
•
Representa os modelos dinâmicos ou comportamentais do sistema e
mostra também as interações ou colaborações entre os vários
elementos estruturais descritos nas outras visões.
•

Visão do modelo de implementação
•
Os aspectos estruturais e comportamentais são representados da
forma como devem ser construídos.
•

Diagramas de seqüências, atividades, estado, cooperação.
Diagrama componentes e implantação
Visão do modelo do ambiente
•
Os aspectos estruturais e comportamentais do ambiente, no qual o
sistema deve ser implementado devem ser representados.
•
Diagrama de implantação.
Análise de Domínio
ANÁLISE DE DOMÍNIO

“A análise de domínio é a identificação,
análise e especificação de requisitos
comuns de um domínio específico de
aplicação, tipicamente para reutilização
em múltiplos projetos dentro da
aplicação do domínio” (Firesmith, 1993).
ANÁLISE DE DOMÍNIO



A Análise de Domínio para sistemas OO pode ocorrer em
diferentes níveis de abstração.
No nível de empresas e negócios as técnicas associadas com
a Análise OO podem ser acopladas a diversas abordagens de
Engenharia de Software no esforço de definir classes, objetos,
relacionamentos e comportamentos que modelam todo o
negócio. A nível de área de negócio um modelo e objetos que
descrevem o trabalho de uma área especial do negócio podem
ser definidos.
No nível da aplicação o modelo de objeto foca nos requisitos
de um usuário ou cliente na medida em que esses requisitos
afetam a aplicação a ser construída.
ANÁLISE DE DOMÍNIO

É comum a proposta de se trabalhar
num nível médio de abstração da
análise de domínio, que se caracteriza
pelo desejo da empresa em criar uma
biblioteca de classes reutilizáveis
(componentes) que será largamente
utilizada numa categoria inteira de
aplicações.
ANÁLISE DE DOMÍNIO

Um domínio específico de aplicação
pode variar muito (aplicações bancárias,
multimídia, etc) mas o objetivo da
análise de domínio é identificar e criar
classes
que
serão
largamente
aplicáveis, de forma que sejam
reutilizadas.
ANÁLISE DE DOMÍNIO


A analise de domínio pode ser vista
como uma atividade guarda chuva para
o processo de desenvolvimento de
software.
Não está diretamente relacionada a um
projeto de software específico, já que
seu objetivo e desenvolver componentes
reutilizáveis.
ANÁLISE DE DOMÍNIO

Entradas e saídas chaves para o
processo de análise de domínio.
• Figura 8.2 página 147 – Pressman 6ª Edição
PROCESSO DE
ANÁLISE DE DOMÍNIO

A análise de domínio pode ser
caracterizada por uma série de
atividades que se iniciam
com a
identificação
do
domínio
a
ser
investigado e termina pela especificação
das classes e objetos que caracterizam
o domínio.
ATIVIDADES ( Berard, 1993)
1. Definir o domínio a ser investigado.
identificar áreas de negócios, tipo de sistema, interesse
do produto, aplicações OO e não OO já definidas,
casos de testes, planos, padrões, métricas, etc.
2. Categorizar os itens extraídos do domínio

de forma a estabelecer uma hierarquia de
classificação. Elaborar uma taxionomia.
3 Coletar uma amostra representativa das aplicações do
domínio
garantindo que durante a análise os itens da aplicação
se enquadrem nas categorias definidas.
ATIVIDADES ( Berard, 1993)
4. Analisar cada aplicação na amostra, segundo os passos
da analise de domínio
 identificar objetos reutilizáveis candidatos
 indicar as razões pelas quais o objeto foi identificado para
reuso.
 definir adaptações no objeto que também podem ser
reutilizadas
 estimar a porcentagem de aplicações no domínio que
podem fazer reuso do objeto
 identificar os objetos pelo nome e usar técnicas de
configuração e gerenciamento para controlá-los.
5. Desenvolver um modelo de análise para os objetos.
O
modelo de análise servirá de base para o projeto e
construção dos objetos de domínio
PROCESSO DE
ANÁLISE DE DOMÍNIO


Além desses passos a análise de domínio
deve criar um conjunto de diretrizes e
desenvolver exemplos que ilustrem como os
objetos do domínio podem ser usados para
criar novas aplicações.
O objetivo é desenvolver software no domínio
com alto percentual de reutilização, baixo
custo, alta qualidade e curto prazo de
comercialização.
PROCESSO DE ANÁLISE OO

O processo da Análise OO não se inicia com
os objetos, mas pelo entendimento da maneira
como o software será usado
•
•
•

pelas pessoas - se é um sistema interativo
pelas máquinas - se é um sistema de controle de
processo
por outros programas - se o sistema controla outras
aplicações.
Tão logo este cenário de uso é identificado a
modelagem do sistema se inicia.
PROCESSO DE ANÁLISE OO

Alguns modelos podem auxiliar o
levantamento de requisitos do usuários
como o casos de uso.
Casos de uso



Requisitos de software são sempre a
primeira atividade da análise.
Baseado nestes requisitos o engenheiro
de software pode criar cenários para
identificar os usos do software a ser
construído
Os cenários, chamados casos de uso,
descrevem como o software será usado.
Casos de uso



Para criar um caso de uso primeiro
identifica-se os tipos de pessoas (ou
equipamentos) que usarão o sistema ou
produto.
Em geral esses atores representam
papéis na operação do sistema.
O ator se comunica com o sistema ou
produto, mas, é externo a ele.
Casos de usos

Atores e usuários são diferentes
• Um usuário pode ter vários papéis quando
•
usando o sistema
Um ator representa um classe de entidades
externas
Casos de usos




Começa-se por fazer a pergunta:
•
O que é que os usuários do sistema podem fazer e
como é que o sistema responde?
É necessário determinar quem são os usuários e
demais intervenientes que interagem com o
sistema.
A esses intervenientes dá-se o nome de atores.
Nos diagramas de casos de uso os
atores são representados por:
NOME
Casos de usos

Um ator é sempre um elemento externo ao sistema.
Para descobrir atores podemos fazer as seguintes
perguntas:
•
•
•
•
•
•
•
•
•
Quem usa o sistema?
Quem instala o sistema?
Quem inicia o sistema?
Quem faz a manutenção do sistema?
Quem desliga o sistema?
Que outros sistemas usam este sistema?
Quem recebe informação sobre este sistema?
Quem fornece informação ao sistema?
O que acontece automaticamente no sistema?
Casos de usos


Depois de identificarmos os atores, é
necessário identificar casos de uso para
cada um
Um caso de uso é um modo de os
atores usarem o sistema. É uma ação
que um ator pode realizar no sistema.
Casos de usos

Para identificar casos de uso podemos fazer
as seguintes perguntas:
•
•
•
•
Que funções pretende o ator do sistema?
Que informação armazena o sistema? Quais atores
vão utilizar essa informação?
O sistema precisa de avisar os atores sobre as
mudanças do seu estado interno?
Há acontecimentos externos ao sistema que este
necessite saber? Se, sim quem fornece tal
informação?
Casos de usos


Em geral um caso de uso se resume na
descrição do papel do ator ao interagir
com o sistema.
Deve fornecer um cenário não ambíguo
da interação entre atores e software.
Casos de usos



O processo de identificação dos casos
de uso é interativo.
Não é necessário identificar de imediato
todos os atores.
Depois de identificados os atores e
respectivos casos de uso elabora-se um
diagrama de casos de uso.
Casos de uso - representações
Nome do caso de uso
Sistema
Casos de uso - representações
casos de uso 1
casos de uso 2
ator 1
casos de uso 3
ator 3
casos de uso 4
ator 2
Identificação das classes

Após o desenvolvimento de cenários
para o sistema é hora de identificar
classes candidatas.
Definição de Estruturas e
Hierarquias


Uma vez classes e objetos sejam
identificados, o analista inicia o modelo de
estrutura das classes e das hierarquias.
É o momento da elaboração de diagramas
de classes com generalizaçãoespecialização e/ou todo-parte.
Definição do Modelo de
Relacionamento



O primeiro passo para entender o
relacionamento entre classes é identificar as
responsabilidades de cada classe.
O segundo passo é identificar os
colaboradores das classes que as ajudam a
alcançar cada responsabilidade.
Aí é estabelecida a conexão entre classes.
Definição do Modelo de
Relacionamento



O relacionamento existe entre duas
classes conectadas.
Colaboradores estão sempre
conectados de alguma forma.
O tipo mais comum de relacionamento é
o binário – uma conexão entre duas
classes (cliente-servidor).
Diagrama de Colaboração
Fila
Computador
[Printer ocupada]
1:2:Store(File)
1:Print(File)
[Printer livre]1:1:Print(File)
ServidorPrinter
Printer
Definição do Modelo de
Comportamento



O modelo de classes e objetos representam
elementos estáticos do modelo de análise OO.
Para projetar a transição para o
comportamento dinâmico do sistema é
necessário representar o comportamento do
sistema em função dos eventos e do tempo.
Os diagramas de estado e seqüência indicam
como o sistema irá responder aos eventos
externos e aos estímulos.
Diagrama de Estado
Alteração de Pedido
solicitada
Pedido
enviado
Registrando
o pedido
Alterando
o pedido
Pedido para
análise
requisitado
Analisando
o pedido
Pedido não
pode ser
atendido
no momento
Pedido já
pode ser
atendido
Colocando
o pedido em
pendência
Cancelando
o pedido
Pedido será
cancelado
Pedido para
aprovação
Cancelamento
de pedido
solicitado
Pedido
cancelado
Aprovando
o pedido
Pedido será
atendido
Atendendo
o pedido
Pedido
atendido
Diagrama de Seqüência
: Bibliotecário
Emprestando
sem reserva
: Janela
Empréstimo
1: ache título ( )
3: ache Item ( )
: Título
: Leitor
: Empréstimo : Item
2: $ache (String)
4: $ache título (Titulo)
5: identifica leitor ( )
6: $ache (String)
7: criar (leitor, Item)
UML - Unified Modeling Language
DIAGRAMAS









Diagrama de Casos de Uso
Diagrama de Classes
Diagrama de Objetos
Diagrama de Estado
Diagrama de Seqüência
Diagrama de Colaboração
Diagrama de Atividades
Diagrama de Componentes
Diagrama de Desenvolvimento
UML - Unified Modeling Language
DIAGRAMAS

Diagrama de Casos de Uso: Atores e suas conexões com Casos de
Uso

Diagrama de Classes: Estrutura estática das classes do sistema

Diagrama de Objetos: Exemplifica Diagrama de Classes Complexo

Diagrama de Estado: Estados possíveis que objetos de uma classe
pode ter e que eventos causam a mudança de estado
UML - Unified Modeling Language
DIAGRAMAS
•
Diagrama de Seqüência: Colaboração Dinâmica através troca de mensagens
entre objetos a partir de uma função ou seqüência de tempo
•
Diagrama de Colaboração: Colaboração Dinâmica através da interação entre
objetos (ênfase no contexto)
•
Diagrama de Atividades: Fluxo seqüencial das atividades
•
Diagrama de Componentes: Estrutura Física de código em termos de
componentes de código
•
Diagrama de Desenvolvimento: Arquitetura Física do Hardware e Software