Levantamento de classes (Análise de casos de uso)

Transcrição

1 Plano Levantamento de classes (Análise de casos de uso) Prof. Cesar Augusto Tacla Levantamento no método APOO Projeto por padrões: MVC e Observador Estereótipos de classes Visão geral do método Engenharia de sistemas Análise de requisitos Análise Refinar a descrição dos casos de uso Levantamento das classes Estudo da interação entre objetos Projeto Refinamento do diagrama de classes Definição do comportamento de classes Modelo de implantação Implementação Modelo de implementação Codificação Análise Modelo de casos de uso Linguagem do cliente/usuário Visão externa do sistema Estruturado pelos casos de uso Contrato entre cliente e desenvolvedores sobre o que o sistema deve fazer Pode haver redundânciase inconsistências nos requisitos Captura a funcionalidade do sistema Define casos de uso que são analisados no modelo de análise Modelo de análise Linguagem dos desenvolvedores Visão interna do sistema Estruturado por classes estereotipadas e pacotes Utilizado pelos desenvolvedorespara definir como projetar e implementar o sistema Nãodeve haver redundânciase inconsistências nos requisitos Rascunha como realizar a funcionalidade Define realizações de casos de uso, cada uma representando a análise de um caso de uso Por que fazer análise? Especificar casos de uso Visão geral do sistema Compreensão de sistemas legados Visão conceitual independente das tecnologias Diferentes plataformas Diferentes fornecedores (concorrência) Sistemas críticos Modelo de análise: abordagens Mantê-lo atualizado Considerá-lo um artefato intermediário Fazê-lo em conjunto* com o levantamento dos requisitos com o projeto *Recomendável somente se o sistema for extremamente simples e os requisitos forem bem conhecidos 1

2 Plano Posição dentro do método APOO Projeto por padrões: MVC e Observador Classes estereotipadas Projeto por Padrões Padrão É uma solução comprovada a um problema recorrente (Gamma e co-autores, 1995) Padrões especificam abstrações que estão acima do nível de classes, objetos isolados ou de componentes. Por que utilizar padrões? Vocabulário comum Facilitar documentação e manutenção Auxiliar o projeto de uma arquitetura com determinadas propriedades Padrão MVC MVC: Model-View-Controller Modelo-Visão-Controlador DESACOPLAMENTO VISÃO Controle MODELO Padrão MVC: camada do modelo Encapsula dados do negócio Encapsula as regras do negócio Acesso ao BD e sistemas de informação da empresa para consultar/persistir dados Não se preocupa com quem mostra os dados como serão mostrados. Padrão MVC: camada da visão Interação com o usuário Interação com outros sistemas Interação com dispositivos Diversas visões dos dados do negócio Se preocupa apenas em apresentá-los. Não se interessa em como foram obtidos 2

3 Padrão MVC: camada de controle Padrão MVC: formas (a) Fluxo de apresentação das informações Intermediação entre visão e modelo Escolha da apresentação em função da língua do usuário, permissões de aceso extrato especial extrato extrato palm Saldo agência Mostrar extrato CC Mostrar saldo agência CC CC CC CC 10/10/ ,00 +23,00 CC CC 10/10/ /10/ ,00 +23,00-5,30-5,30 10/10/ /10/ ,00 +23,00-5,30-5,30 09/10/ , , (a) Eventos de interface, entrada de informações ações Visão Controle Modelo do negócio Padrão MVC: formas (b) Aplicação do padrão MVC (b) Eventos de interface, entrada de informações ações Visão Controle Modelo do negócio Estado modelo Aplicações que necessitam mostrar os dados do negócio de diferentes formas: Tipo do dispositivo de saída Necessidades dos usuários Visão selecionada Padrão MVC em aplicações WEB Modelo 2: centrado em Servlets Evolução (JEE) Sem camadas Modelo 1: centrado em páginas Modelo 2: centrado em Servlets Frameworks (não há padrão): struts Frameworks padrões: Java Server Faces Mais detalhes em 3

4 Modelo 2: centrado em Servlets Plano apresentação Posição dentro do método APOO Projeto por padrões: MVC e Observador Classes estereotipadas Conjunto de servlets autenticação, login, dispatcher Padrão observador Modelo de eventos swing Desacoplar: reduzir as dependências entre classes Objeto observador Exemplo Modelo de eventos Swing Eventos são gerados e tratados de forma padrão O evento botão pressionado pode ter vários observadores O botão não sabe quantos e nem quais são os observadores Botão pressionado Registra-se notifica Objeto observador Modelo eventos: sujeito e observador Botão é denominada sujeito Possui vários observadores Modelo eventos: observador Observador deve se registrar Deve tratar os eventos JButton button = new JButton( Clique-me ); button.addactionlistener(ctrlassinatura); adicionar 1. public void actionperformed(actionevent e) { 2. String s = new String(e.getActionCommand()); 3. numcliques++; 4. System.out.println("Botao [" + 5. e.getactioncommand() + "] 6. clicado: " + numcliques); 7. } Lista de observadores 4

5 Modelo de eventos swing Modelo de eventos: notificação Usuário Clica no botão AWT Abstract Window Toolkit Botão Subject Gerador de eventos Observador Botão pressionado addactionlistener(this) actionperformed(actionevent e) Objeto observador AWT envia uma instância de ActionEvent para o botão chamando o método processevent Executa o método processevent que recebe todos os eventos do botão e passa o evento aos observadores da lista Executa o método ActionPerformed Exercícios Exercício 1: baixe o código JContador.zip, execute-o. Em seguida, modifique-o incluindo mais dois botões: clique-me 1 e clique-me 2. Faça com que o controle escute eventos que ocorram nestes novos botões. Tente diferenciar os cliques no objeto de controle e mostre o horário de ocorrência dos eventos. Exercício 2: quando o usuário clicar no botão cliqueme 2, remover o controle da lista de ouvidores de eventos do botão clique-me 2. Exercício 3: Construa o diagrama de classes e o de seqüência (cenário: o usuário clica uma vez no botão clique-me ). 3 assunto observador Exercícios Exercício 1: baixe o código JGeradorEventos.zip, execute-o. Em seguida, modifique-o incluindo mais dois objetos ouvidores que sejam notificados dos eventos gerados. janela Exercício 2: Crie uma nova classe de objetos ouvidores denominada Ouvidor2. Responda: qual a vantagem de criar ouvidores? Exercício 3: Construa o diagrama de classes e o de seqüência para o cenário seguinte: o gerador de eventos gera um evento e dois objetos instâncias da classe Ouvidor são notificados. 5

6 Aplicação do padrão observador Quando uma modificação em um objeto implica modificações em outros e não se sabe quantos objetos precisam ser modificados. Quando um objeto deve ser capaz de notificar outros objetos, mas sem pressupostos sobre os objetos a serem notificados. Padrão Observador: classes Sujeito (subject): classe dos objetos observados que geram os eventos. Observador (observer): classe dos objetos que observam e tratam os eventos gerados pelo sujeito. Evento: o que é observável Plano Posição dentro do método APOO Projeto por padrões: MVC e Observador Estereótipos de classes Estereótipos de classes Esclarece a função da classe <<entidade>> ou <<entity>> <<controle>> ou <<control>> <<fronteira>> ou <<boundary>> Estereótipo <<entidade>> Informações do domínio do problema Longo-prazo (persistente ou não) Camada do modelo Independentes do contexto (+reuso) <<entidade>> Nome da classe atributos métodos Estereótipo <<fronteira>> Interações entre sistema e atores Aparecem frequentemente na camada de visão Dependentes do contexto (-reuso) Ex. Interação com outros sistemas Interfaces com usuários Interfaces com dispositivos <<fronteira>> Nome da classe atributos métodos 6

7 Estereótipo <<controle>> controle/lógica de um caso de uso Comandam a execução de um caso Dependentes do contexto (-reuso) <<controle>> Nome da classe atributos Plano Posição dentro do método APOO Projeto por padrões: MVC e Observador Estereótipos de classes métodos Método para levantamento Exemplo: conversão C - F Para cada caso de uso Para cada ator Crie uma classe <<fronteira>> Crie uma classe <<controle>> Identificar as classes <<entidade>> Ver descrição dos casos de uso em IV seção 4 Levantamento preliminar (1) Levantamento preliminar (1) requisitos análise 7

8 Levantamento preliminar (2) Resumo class Classes de análise (levantamento) Modelo de casos de uso IUConversao CtrlConversao Historico Caso de uso Diagrama de casos de uso Descrições Glossário Modelo do domínio realização Modelo de análise Classes de análise IUHistorico CtrlHistorico ConversaoCF Cenários de colaboração Diagrama de sequência 8