Análise Orientada a Objetos. Análise e Projeto

Transcrição

1 Análise Orientada a Objetos Análise e Projeto

2 Análise versus Projeto Foco no entendimento do problema Projeto idealizado Comportamento Estrutura do sistema Requisitos funcionais Modelos simples Foco no entendimento da solução Operações e atributos Performance Pensamento no código Ciclo de vida de objetos Requisitos não-funcionais Modelo complexo 2010Análise e Projeto I 2

3 Análise e Projeto OO Durante a Análise OO, a ênfase está em achar e descrever objetos (ou conceitos) no domínio do problema Durante o projeto OO, a ênfase está em achar objetos lógicos de software que poderão ser eventualmente implementados usando uma linguagem OO

4 Análise e Projeto OO Conceito de domínio Representação na análise Representação no projeto Exemplo: O conceito Livro em um sistema de biblioteca. título Livro Representação no código título public class Livro { public void imprimir(); } Livro imprimir() private String titulo;

5 Modelo de Analise e Projeto A construção do modelo de análise e projeto é o principal objetivo desta disciplina O modelo de análise e projeto contém as realizações de casos de uso Pode ser particionado em dois modelos Modelo de Analise Modelo de Projeto 2010Análise e Projeto I 5

6 Realização de Caso de Uso Caso de Uso Realização de Caso de Uso Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto Diagramas de Colaboração Diagramas de Sequência Diagramas de Classe Requisitos Analise e projeto 2010Análise e Projeto I 6

7 Casos de Uso Análise Projeto Diagrama de Classes Diag. Seq. de Eventos do Sistema Diag. Colaboração Modelo conceitual Diag. sequências

8 ATIVIDADES DA ANÁLISE E PROJETO 2010Análise e Projeto I 8

9 Analisar Arquitetura Construir e avaliar uma prova de conceito arquitetural Mostrar que existe uma solução possível de satisfazer os requisitos do sistema relevantes à arquitetura 2010Análise e Projeto I 9

10 Definir uma arquitetura candidata Criar o esqueleto inicial da arquitetura do sistema Identificar classes de análise dos casos de uso arquiteturalmente relevantes Atualizar a realização de caso de uso com as interações entre classes de análise 2010Análise e Projeto I 10

11 Analisar o comportamento Transformar as descrições sobre o comportamento providas pelos caso de uso em um conjunto de elementos nos quais o modelo de projeto vai se basear 2010Análise e Projeto I 11

12 Projetar Componentes Refinar as definições dos elementos acrescentado detalhes sobre como estes elementos implementam o comportamento requerido Refinar e atualizar as realizações de casos de uso com os novos elementos identificados 2010Análise e Projeto I 12

13 Projetar Banco de Dados Identificar classes persistentes no modelo de projeto Projetar as estruturas de banco de dados (Modelo de dados) Definir mecanismos e estratégias para armazenar e recuperar dados 2010Análise e Projeto I 13

14 Refinar Arquitetura Permitir uma transição entre os elementos e mecanismos de análise para os de projeto Manter a consistência e integração da arquitetura Descrever a arquitetura de execução e produção da aplicação 2010Análise e Projeto I 14

15 ANÁLISE DE CASOS DE USO

16 Passos da Atividade de Análise Identificar as classes Identificar persistência Identificar responsabilidades das classes Identificar relacionamentos Identificar atributos 16

17 Identificando as classes No primeiro passo de análise, identificaremos três tipos de classes: Fronteira Entidade Controle Tais classes são identificadas separadamente para cada de uso 17

18 Classes de Fronteira Utilizada para modelar a interação entre um ator e o sistema Para cada interação entre um ator e caso de uso, é criada uma classe de fronteira Possuem o estereótipo <<boundary>> 18

19 Classes de Entidade Utilizadas para modelar a informação manipulada pelo sistema Podem ser persistentes ou não Conceito análogo às entidades dos diagramas ER São identificadas a partir do fluxo de eventos do caso de uso Possuem o estereótipo <<entity>> 19

20 Classes de Controle Classes responsáveis por controlar o fluxo de execução do caso de uso Normalmente é criada uma classe de controle para cada caso de uso Possuem o estereótipo <<control>> 20

21 Exemplo efetuar login Usuario adicionar turma registrar súmulas das aulas remover turma Secretária Professor registrar faltas Aluno editar turma consultar freqüência editar alunos remover alunos adicionar alunos Servidor de 15/03/ / Análise e Projeto I 21

22 Exemplo 2010Análise e Projeto I 22

23 Especificação de Casos de Uso Efetuar Login Fluxo de eventos: 1. Usuário informa login e senha 2. Sistema checa se o login e senha conferem 3. Sistema registra a sessão do aluno e a tela principal do sistema é exibida 15/03/ / Análise e Projeto I 23

24 Exemplo Que classes preciso criar? uma classe de fronteira para lidar com a interação dos atores com o sistema uma classe de entidade para representar as informações relevantes do aluno uma classe de controle para gerenciar o fluxo de execução do caso de uso 24

25 Exemplo TelaLogin ControladorLogin Usuario Há diferentes opções de visualização dos estereótipos. A opção padrão é mostrada acima - os estereótipos são visualizados através da mudança dos ícones das classes. Há também a opção de se visualizar os estereótipos do modo convencional (<<estereótipo>>). <<boundary>> TelaLogin <<control>> ControladorLogin <<entity>> Usuario 25

26 Persistência Mas caso alguma classe de entidade precise ser persistente? Que classe será responsável por realizar as tarefas de persistência? Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>> 26

27 Exemplo <<boundary>> TelaLogin <<control>> ControladorLogin <<entity collection>> CadastroUsuarios <<entity>> Usuario 27

28 Diagramas de interação Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer. Os diagramas de interação (seqüência e colaboração) são muito úteis nesta tarefa 28

29 Exemplo : usuário : TelaLogin : ControladorLogin : CadastroAlunos efetuarlogin(login, senha) efetuarlogin(login, senha) checar(login, senha) registrarsessao() 29

30 Alocando responsabilidades Após identificarmos as responsabilidades (métodos) pelos diagramas de interação, devemos acrescentar os métodos nas classes previamente identificadas (1º passo) 30

31 Classes com métodos 31

32 Identificando relacionamentos As classes identificadas não funcionam isoladamente, elas se relacionam com as demais classes Os diagramas de interação são muito úteis nesta tarefa Para cada ligação presente nos diagramas de interação, é necessário um relacionamento no diagrama de classes 32

33 Classes com relacionamentos 33

34 Identificando Atributos Também é necessário identificar quais os atributos das classes Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade Nesta etapa ainda não precisamos indicar quais os tipos dos atributos 34

35 Diagrama final 35

36 Exemplo 2 Secretária adicionar alunos Servidor de Fluxo de eventos: 1. Secretária informa dados do aluno 2. Secretária seleciona a opção confirmar cadastro 3. Sistema checa se os dados são válidos 4. Sistema adiciona o aluno à base de dados 5. Sistema envia um para o aluno, informando-o seu login e senha 6. Sistema exibe uma mensagem de confirmação de cadastro Identificar as classes do caso de uso adicionar aluno 36

37 FLUXO DE ANÁLISE E PROJETO SIMPLIFICADO Simplificando/Instanciando o processo para um contexto específico

38 Fluxo de atividades simplificado 1. Analisar Arquitetura 2. Analisar Caso de Uso 3. Projetar Classes 4. Projetar Banco de Dados 2010Análise e Projeto I 38

39 ANALISAR ARQUITETURA

40 Analisar Arquitetura Esforço inicial em definir as partes do sistema e seus relacionamentos (Arquitetura Inicial) Definir as convenções de modelagem Identificar os mecanismos de análise Identificação das abstrações-chave 2010Análise e Projeto I 40

41 Arquitetura de Software A estrutura de um sistema de software, que engloba componentes de software; suas propriedades visíveis externamente; e os relacionamentos e interações entre eles As primeiras decisões tomadas no projeto de um sistema As mais importantes! Uma arquitetura de software é composta por componentes e conectores

42 Estilos 42

43 Padrões de Distribuição Ponto a ponto Cliente-servidor Cliente gordo (Fat Client) Servidor gordo (Fat Server) 3 camadas Cliente-servidor Distribuído 43

44 Ponto a ponto Apresentação Negócio Dados Apresentação Negócio Dados 44

45 Cliente-servidor 3 camadas Apresentação Negócio Dados 45

46 Cliente gordo Apresentação Negócio Dados 46

47 Arquitetura Web Tradicional Navegador Web Apresentação Negócio Dados 47

48 Uma Arquitetura Web Clientes web (. etc (Mozilla, IE, Internet Servidor WEB Rede Local Banco de Dados Relacional

49 Uma Arquitetura Web Clientes web (. etc (Mozilla, IE, Internet Servidor WEB Rede Local Banco de Dados Relacional Componente Componente Componente

50 Uma Arquitetura Web Clientes web (. etc (Mozilla, IE, Internet Servidor WEB Rede Local Banco de Dados Relacional Conector (HTTP, ( RMI Conector (Ponte ( SQL

51 Arquitetura Inicial Quais as principais partes do sistema? Como elas interagem entre si? Que padrões arquiteturais utilizar (no todo ou internamente nas partes)? MVC Baseado em camadas Canais e filtros Centrado em repositório 2010Análise e Projeto I 51

52 Exemplo de arquitetura inicial Módulo de Vendas Interface Gráfica Módulo de Estoque Negócio Socket Dados 2010Análise e Projeto I 52

53 Convenções de modelagem O que são? Que diagramas e elementos de modelagem utilizar Definir as regras para utilização desses componentes Convenções de nome Exemplos Casos de uso devem ser nomeados como ações (Cadastrar usuário) Cada realização de caso de uso deve conter: Um diagrama de classes No mínimo um diagrama de seqüência representando o fluxo principal de ações 2010Análise e Projeto I 53

54 Mecanismos de análise O que são? Focam nos requisitos não-funcionais do sistema Decisão estratégica sobre padrões, politicas e práticas a serem utilizadas no projeto Exemplos Persistência Comunicação Gerenciamento de transações Segurança 2010Análise e Projeto I 54

55 Identificar Abstraçõeschave Definir classes de análise preliminares Conhecimento do domínio Requisitos Outros artefatos (Glossário e modelo de negócio) 2010Análise e Projeto I 55

56 ANALISAR CASO DE USO

57 Objetivos Identificar as classes que executam o fluxo de eventos do caso de uso Distribuir o comportamento do caso de uso nestas classes Identificar atributos, responsabilidades e associações das classes 2010Análise e Projeto I 57

58 Passo 1: Encontrar classes de análise O comportamento do caso de uso é distribuído em classes de análise 2010Análise e Projeto I 58

59 Passo 2: Distribuir comportamento Para cada fluxo de eventos Identificar classes de análise participantes Alocar responsabilidades do caso de uso às classes de análise Modelar interações entre as classes através dos diagramas de interação 2010Análise e Projeto I 59

60 Distribuindo comportamento entre as classes Classes de análise Diagrama de seqüência Diagrama de colaboração Caso de uso Classes de análise com responsabilidades 2010Análise e Projeto I 60

61 Alocando responsabilidades Use estereótipos de análise como guia Classes de fronteira Comportamento que envolve comunicação com um ator Classes de entidade Comportamento que envolve informação encapsulada na abstração Classes de controle Comportamento específico ao (lógica de controle do) caso de uso 2010Análise e Projeto I 61

62 Guia: Alocando responsabilidades Quem tem a informação necessária para realizar a responsabilidade isso pode envolver apenas uma classe, mas pode ser preciso criar novas classes ou relacionamentos entre classes 2010Análise e Projeto I 62

63 Modelando interações Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atores A interação é iniciada por um ator e envolve instâncias (objetos) das classes Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso Auxiliam a identificar classes, responsabilidades e relacionamentos Mecanismo de validação da arquitetura 2010Análise e Projeto I 63

64 Vários diagramas podem ser necessários 2010Análise e Projeto I 64

65 Colaboração X Sequência Colaboração Mostra os relacionamentos, além das interações Melhor para visualizar a colaboração Melhor de ser usado em reuniões Sequência Mostra a sequência explicíta de mensagens Melhor para visualizar o fluxo Melhor para cenários complexos 2010Análise e Projeto I 65

66 Passo 3: Descrever Responsabilidades Atualizar os diagramas de classes com as responsabilidades identificadas no de iteração Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras 2010Análise e Projeto I 66

67 Como fazer? diagrama de interação :Cliente // Executar responsabilidade :Fornecedor diagrama de classe Fornecedor // Executar responsabilidade 2010Análise e Projeto I 67

68 Gerenciando a consistência Classes com responsabilidades similares são candidatas a serem combinadas Uma classe com responsabilidades disjuntas é candidata a ser dividida Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas 2010Análise e Projeto I 68

69 Passo 4: Descrever atributos e associações Definir atributos Estabelecer agregações e associações 2010Análise e Projeto I 69

70 Encontrando Atributos Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc. São propriedades/características das classes identificadas informação de propriedade exclusiva do objeto informação que pode ser lida ou escrita por operações, mas sem outro comportamento a não ser fornecer um valor Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe 2010Análise e Projeto I 70

71 Encontrando Relacionamentos Interações entre objetos nos diagrama de interação pode indicar a necessidade de definir um relacionamento entre as classes Adicionar os elementos de um relacionamento Tipo e nome Navegabilidade Multiplicidade Papéis 2010Análise e Projeto I 71

72 Encontrando Relacionamentos Diagrama de Colaboração :Client 1: PerformResponsibility :Supplier Client Link Supplier Diagrama de classe Client 0..* 0..* Prime suppliers Supplier PerformResponsibility() Association 2010Análise e Projeto I 72

73 Passo 5: Qualificar mecanismos de análise Mapear classes de análise em mecanismos de análise Classes de análise Estudante ControladorMatricula Curso Mecanismos de análise Persistente Distribuição, Segurança Persistente, Interface Legado 2010Análise e Projeto I 73

74 Passo 6: Unificar classes de análise Realização de Caso de Uso Realização de Caso de Uso Realização de Caso de Uso Diagramas de Classe Diagramas de Classe Diagramas de Classe Diagramas de Classe 2010Análise e Projeto I 74

75 PROJETAR CLASSES

76 Objetivo Detalhar as partes do sistema Concretização dos conceitos definidos até o momento Detalhes de implementação e ambiente de produção Produtos utilizados Linguagem de programação Distribuição Performance Restrições físicas 2010Análise e Projeto I 76

77 Passos do projeto de classes Para cada classe: 1. Criar classes de projeto 2. Identificar classes persistentes 3. Definir métodos 4. Definir atributos 5. Definir estados 6. Definir relacionamentos 7. Contemplar os requisitos não-funcionais 2010Análise e Projeto I 77

78 Passo 1: Criar classes de projeto Converter classes de análise (Fronteira, Controle e Entidade) em classes de projeto Padrões de projeto podem ser incorporados As classes são refinadas para incorporar os mecanismos arquiteturais 2010Análise e Projeto I 78

79 Projetando classes de fronteira GUI (Graphical User Interface) Que ferramenta de desenvolvimento de interface gráfica será utilizada? Quant pode ser criada pela ferramenta? Que padrões serão utilizados? Sistemas Externos Que tecnologias/mecanismos de integração? Que padrões? Projetar como um subsistema 2010Análise e Projeto I 79

80 Projetando classes de entidade Classes de Entidade são Transitórias Persistentes São detalhadas no passo Identificar classes persistentes 2010Análise e Projeto I 80

81 Projetando classes de controle Decisões que deve ser tomadas: Elas são realmente necessárias? Elas podem/devem ser agrupadas? Como decidir? Complexidade Operações relacionadas Probabilidade de mudar Performance e distribuição 2010Análise e Projeto I 81

82 Passo 2: Identificando classes persistentes Instancias da classe precisam preservar o seu estado Estratégia de persistencia é definida para cada classe persistente Curso Candidato JDBC Serialização BD Relacional Arquivo 2010Análise e Projeto I 82

83 Passo 3: Definir Métodos Tem como propósito mapear responsabilidades identificada na análise para métodos na classe Deve-se considerar Nome, assinatura e visibilidade dos métodos 2010Análise e Projeto I 83

84 Mapeando operações - concreto :Cliente // Realizar alguma operação :Fornecedor Análise :Cliente fazeralgo() :Fornecedor Projeto + concreto 2010Análise e Projeto I 84

85 Passo 4: Definir Atributos Tem como propósito formalizar a definição dos atributos Deve-se considerar Persistência Visibidade, nome, tipo e valor inicial 2010Análise e Projeto I 85

86 Passo 5: Definir estado Tem como objetivo definir como o objeto se comporta Relevante apenas para objetos com ciclo de vida complexo Pode ser especificado em UML Diagrama de estados Diagrama de atividades 2010Análise e Projeto I 86

87 Diagrama de Estados Um diagrama de estados mostra o ciclo de vida de um objeto Estado Nome do estado Variavel: Tipo = valor Evento(args) [condição] / Operacao(args) ^obj.enviarmensagem(args) Ação de entrada Ação de saída Atividade Ações Atividades Transição 2010Análise e Projeto I 87

88 Exemplo de diagrama de estado Inicializado do: Incializa Curso Adiciona Aluno / contador = 0 Adiciona Aluno[ contador < 10 ] Aberto Cancela Cancelado do: Notifica Alunos Cancela Cancela Fechado do: Finaliza curso [ contador = 10 ] 2010Análise e Projeto I 88

89 Passo 6: Definir Relacionamentos Dependências Associações Simples Agregação Composição Generalização 2010Análise e Projeto I 89

90 Passo 7: Contemplar os requisitos não-funcionais Concretização dos mecanismos de análise Incorporar responsabilidades em algumas classes Criar novas classes Exemplos: Segurança Como armazenar as senhas? Que algoritmo usar para criptografar uma mensagem? Distribuição Que tecnologia utilizar? Qual o impacto da tecnologia nos objetos já definidos? Tratamento de logs Que tipo de operações deve ter log (Acesso a dados, execução de negócio, ) 2010Análise e Projeto I 90

91 Projetar Banco de Dados Mapear as classes persistentes em conceitos do Banco de Dados Definir os tipos de dados mais adequados para o BD Normalizar se necessário 2010Análise e Projeto I 91

92 EXEMPLOS DE ARQUITETURAS

93 93

94 94

95 95

96 96

97 97

98 98

99 99

100 100

101 101

102 102

103 103

104 104

105 105

106 106

107 107

108 108

109 109

110 110

111 111

112 112

113 113