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-processamento-saí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

UML

BoochRumbaugh

Jacobson

Meyer

Harel

Wirfs-BrockFusionGamma et al.

Shlaer-Mellor

Odell

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.

• Diagramas de seqüências, atividades, estado, cooperação. Visão do modelo de implementação

• Os aspectos estruturais e comportamentais são representados da forma como devem ser construídos.

• 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 DEANÁ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íniogarantindo que durante a análise os itens da aplicação se enquadrem nas categorias definidas.

ATIVIDADES ( Berard, 1993)

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. 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 DEANÁ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

ator 1

ator 2

ator 3

casos de uso 1

casos de uso 2

casos de uso 3

casos de uso 4

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ção-especializaçã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

Computador

ServidorPrinter

Fila

Printer

1:Print(File)

[Printer ocupada]1:2:Store(File)

[Printer livre]1:1:Print(File)

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

Registrando o pedido

Alterando o pedido

Cancelandoo pedido

Analisando o pedido

Atendendo o pedido

Aprovando o pedido

Colocandoo pedido em

pendência

Pedidoenviado

Alteração de Pedidosolicitada

Cancelamentode pedidosolicitado

PedidocanceladoPedido será

cancelado

Pedido para análise

requisitado

Pedido paraaprovação

Pedido jápode seratendido

Pedido nãopode seratendido

no momento

Pedido seráatendido

Pedidoatendido

Diagrama de Seqüência

: Bibliotecário : Título : Leitor : Janela

Empréstimo : Empréstimo : Item

1: ache título ( ) 2: $ache (String)

3: ache Item ( )

5: identifica leitor ( )

6: $ache (String)

7: criar (leitor, Item)

4: $ache título (Titulo)

Emprestandosem reserva

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