Upload
internet
View
104
Download
0
Embed Size (px)
Citation preview
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
“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
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