Análise e Projeto no RUP

Apresentação em tema: "Análise e Projeto no RUP"— Transcrição da apresentação:

1 Análise e Projeto no RUP

2 Contexto Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso em mãos. Queremos agora gerar um primeiro modelo do sistema a partir dos casos de uso. Este modelo é chamado de modelo de análise. 2009 15/03/2005 MDS - Bacalá 2/28 2

3 Contexto Requisitos Análise Projeto 3 2009 15/03/2005 MDS - Bacalá
3/28 3

4 Atividade de Análise Vai proporcionar um método que permita que criemos um modelo de classes do sistema a partir dos casos de uso Trará a resposta para a pergunta: Quais classes preciso para implementar estes casos de uso? 2009 15/03/2005 MDS - Bacalá 4/28 4

5 Análise & RUP A maneira como vamos realizar a etapa de análise se baseia no processo do RUP (Rational Unified Process) A análise será orientada a casos de uso, ou seja, os casos de uso servirão de guia para a etapa de análise 2009 15/03/2005 MDS - Bacalá 5/28 5

6 Casos de Uso X Análise 2009 15/03/2005 MDS - Bacalá 6/28 6

7 Análise & Projeto Os objetivos do fluxo:
Transformar os requisitos em um projeto do sistema do que o sistema será Derivar uma arquitetura robusta do sistema Adaptar o projeto 2009 MDS - Bacalá

8 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 2009 MDS - Bacalá

9 Visão geral dos artefatos
Modelo de análise e projeto Análise e projeto Modelo de caso de uso Documento da arquitetura Modelo de dados Documento requisitos Glossário 2009 MDS - Bacalá

10 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 2009 MDS - Bacalá

11 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  Analise e projeto   Requisitos  2009 MDS - Bacalá

12 Fluxo de Análise e Projeto
Diagrama de Atividades In the Inception Phase, analysis and design is concerned with establishing whether the system as envisioned is feasible, and with assessing potential technologies for the solution (in Perform Architectural Synthesis). If it is felt that little risk attaches to the development (because, for example, the domain is well understood, the system is not novel, and so on) then this workflow detail may be omitted. The early Elaboration Phase focuses on creating an initial architecture for the system (Define a Candidate Architecture) to provide a starting point for the main analysis work. If the architecture already exists (either because it was produced in previous iterations, in previous projects, or is obtained from an application framework), the focus of the work changes to refining the architecture (Refine the Architecture) and analyzing behavior and creating an initial set of elements which provide the appropriate behavior (Analyze Behavior). After the initial elements are identified, they are further refined. Design Components produce a set of components which provide the appropriate behavior to satisfy the requirements on the system. In parallel with these activities, persistence issues are handled in Design the Database. The result is an initial set of components which are further refined in Implementation. 2009 MDS - Bacalá

13 Realizar síntese da arquitetura
2009 MDS - Bacalá

14 Objetivo Construir e avaliar uma prova de conceito arquitetural
Mostrar que existe uma solução possível de satisfazer os requisitos do sistema relevantes à arquitetura The purpose of this workflow detail is to construct and assess an Architectural Proof-of-Concept, with the objective of showing that there exists, or is likely to exist, a solution which will satisfy the architecturally significant requirements, i.e. showing that the system, as envisioned, is feasible. 2009 MDS - Bacalá

15 Definir a arquitetura candidata
2009 MDS - Bacalá

16 Objetivo 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 The purpose of this workflow detail is to: Create an initial sketch of the architecture of the system Define an initial set of architecturally significant elements to be used as the basis for analysis Define an initial set of analysis mechanisms Define the initial layering and organization of the system Define the use-case realizations to be addressed in the current iteration Identify analysis classes from the architecturally significant use cases Update the use-case realizations with analysis class interactions 2009 MDS - Bacalá

17 Analisar comportamento
2009 MDS - Bacalá

18 Objetivo 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 Transform the behavioral descriptions provided by the use cases into a set of elements upon which the design can be based 2009 MDS - Bacalá

19 Projetar componentes 2009 MDS - Bacalá

20 Objetivo 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 The purpose of this workflow detail is to: Refine the definitions of design elements (including capsules and protocols) by working out the 'details' of how the design elements implement the behavior required of them. Refine and update the use-case realizations based on new design element identified (i.e. keeping the use-case realizations updated) Reviewing the design as it evolves Implementing the design elements as components Testing the implemented components to verify functionality and satisfaction of requirements at the component/unit level 2009 MDS - Bacalá

21 Projetar Banco de Dados
2009 MDS - Bacalá

22 Objetivo 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 Identify the persistent classes in the design Design appropriate database structures to store the persistent classes Define mechanisms and strategies for storing and retrieving persistent data in such a way that the performance criteria for the system are met 2009 MDS - Bacalá

23 Refinar Arquitetura 2009 MDS - Bacalá

24 Objetivo 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 The purpose of this workflow detail is to: Provide the natural transition from analysis activities to design activities, identifying: appropriate design elements from analysis elements appropriate design mechanisms from related analysis mechanisms Maintain the consistency and integrity of the architecture, ensuring that: new design elements identified for the current iteration are integrated with pre-existing design elements. maximal re-use of available components and design elements is achieved as early as possible in the design effort. Describe the organization of the system's run-time and deployment architecture Organize the implementation model so as to make the transition between design and implementation seamless 2009 MDS - Bacalá

25 Fluxo de Análise e Projeto Simplificado
Simplificando/Instanciando o processo para um contexto específico

26 Motivação O RUP é um Framework
Genérico e complexo demais, pois visa atender todos os tipos de projetos de desenvolvimento de software Toda disciplina do RUP deve ser analisada e customizada de acordo com as necessidades específicas do projeto antes de sua implantação 2009 MDS - Bacalá

27 Passos da Atividade de Análise
Identificar as classes Identificar persistência Identificar responsabilidades das classes Identificar relacionamentos Identificar atributos 2009 15/03/2005 MDS - Bacalá 27/28 27

28 Fluxo de atividades simplificado
Analisar Arquitetura Analisar Caso de Uso Projetar Classes Projetar Banco de Dados 2009 MDS - Bacalá

29 Analisar Arquitetura

30 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 2009 MDS - Bacalá

31 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 2009 MDS - Bacalá

32 Exemplo de arquitetura inicial
Módulo de Vendas Módulo de Estoque Interface Gráfica Negócio Socket Dados 2009 MDS - Bacalá

33 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 2009 MDS - Bacalá

34 Mecanismos de análise O que são? Exemplos
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 2009 MDS - Bacalá

35 Identificar Abstrações-chave
Definir classes de análise preliminares Conhecimento do domínio Requisitos Outros artefatos (Glossário e modelo de negócio) 2009 MDS - Bacalá

36 Analisar Caso de Uso

37 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 2009 MDS - Bacalá

38 Passos para Analisar Caso de Uso
Para cada caso de uso: Encontrar classes de análise Distribuir comportamento entre as classes Para cada classe: Descrever responsabilidades Descrever atributos e associações Qualificar mecanismos de análise 2009 MDS - Bacalá

39 Passo 1: Encontrar classes de análise
O comportamento do caso de uso é distribuído em classes de análise 2009 MDS - Bacalá

40 O que são classes de análise?
Representam o conceito mais abstrato dos elementos do sistema Primeiro passo concreto até chegar em um sistema executável Categorização temporária São convertidas para classes de projeto Servem para diminuir o gap entre os requisitos e projeto Podem ser dos seguintes tipos Fronteira (<<boundary>>) Controle (<<control>>) Entidade (<<entity>>) 2009 MDS - Bacalá

41 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>> 2009 15/03/2005 MDS - Bacalá 41/28 41

42 Classes de Fronteira Itermediam a interface para qualquer coisa externa ao sistema Exemplos de classes fronteira GUI Interface com outros sistemas Interface com dispositivos Uma classe de Fronteira por interação ator X caso de uso <<boundary>> Notação em UML 2009 MDS - Bacalá

43 O Papel de uma Classe de Fronteira
<<boundary>> <<control>> <<boundary>> Usuário <<boundary>> <<entity>> <<entity>> Modela interação entre o sistema e seu ambiente 2009 MDS - Bacalá

44 Exemplo de classes de fronteira
Sistema Academico Estudante Matricular-se Em disciplina <<boundary>> FormRegistroCursos <<boundary>> SistemaAcademico 2009 MDS - Bacalá

45 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>> 2009 15/03/2005 MDS - Bacalá 45/28 45

46 Classes de Entidade Abstrações chave dos casos de uso
<<entity>> Glossário Descrição do Caso de uso 2009 MDS - Bacalá

47 O Papel de uma Classe de Entidade
<<boundary>> <<control>> <<boundary>> Usuário <<boundary>> <<entity>> <<entity>> Armazenam e gerenciam informação no sistema 2009 MDS - Bacalá

48 Exemplo de classes de entidade
<<entity>> Estudante <<entity>> Curso <<entity>> Horario 2009 MDS - Bacalá

49 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>> 2009 15/03/2005 MDS - Bacalá 49/28 49

50 Classes de Controle Coordenam o comportamento (lógica de controle) do caso de uso Interface entre fronteira e entidade <<control>> 2009 MDS - Bacalá

51 O Papel de uma Classe de Controle
<<boundary>> <<entity>> <<control>> Usuário Coordenam o comportamento do caso de uso 2009 MDS - Bacalá

52 Exemplo de Classe de Controle
Sistema Academico Estudante Matricular-se Em disciplina <<control>> ControladorMatricula matricurlarAluno() 2009 MDS - Bacalá

53 Exemplo 2009 15/03/2005 MDS - Bacalá 53/28 53

54 Exemplo 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 2009 15/03/2005 MDS - Bacalá 54/28 54

55 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 2009 15/03/2005 MDS - Bacalá 55/28 55

56 Exemplo 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>>). 2009 15/03/2005 MDS - Bacalá 56/28 56

57 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>> 2009 15/03/2005 MDS - Bacalá 57/28 57

58 Exemplo 2009 15/03/2005 MDS - Bacalá 58/28 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 2009 MDS - Bacalá

60 Distribuindo comportamento entre as classes
Classes de análise Diagrama de seqüência Diagrama de colaboração Classes de análise com responsabilidades Caso de uso 2009 MDS - Bacalá

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 2009 MDS - Bacalá

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 2009 MDS - Bacalá

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 2009 MDS - Bacalá

64 Vários diagramas podem ser necessários
2009 MDS - Bacalá

65 Anatomia de um Diagrama de Seqüência
Objetos :Cliente :Fornecedor Mensagem reflexiva  Linha da vida  1: Solicita serviço 1.1: Solicita outro serviço Mensagem Foco do controle Numeração hierárquica 2009 MDS - Bacalá

66 Exemplo de diagrama de Seqüência
: Aluno janela de matrícula controle de mat 101 1: preenche info 2: submete 3: ad curso(Jose, mat 101) 4: ad(Jose) 5: curso aberto? 6: ad(Jose) section 1 2009 MDS - Bacalá

67 Diagrama de Colaboração
Objetos :Cliente :Fornecedor 1: Solicita serviço Ligação Mensagem 2009 MDS - Bacalá

68 Exemplo de diagrama de colaboração
janela de curso : JanelaCurso 1: informação do curso 2: processa : Secretaria 3: adiciona curso gerenciador : GerenciadorCurriculo curso : Curso 4: novo curso 2009 MDS - Bacalá

69 Exemplo 2009 15/03/2005 MDS - Bacalá 69/28 69

70 Colaboração X Sequência
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 2009 MDS - Bacalá

71 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 2009 MDS - Bacalá

72 Como fazer? :Fornecedor diagrama de :Cliente interação diagrama de
// Executar responsabilidade Fornecedor diagrama de classe // Executar responsabilidade 2009 MDS - Bacalá

73 Classes com métodos 2009 15/03/2005 MDS - Bacalá 73/28 73

74 Passo 4: Descrever atributos e associações
Definir atributos Estabelecer agregações e associações 2009 MDS - Bacalá

75 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 2009 15/03/2005 MDS - Bacalá 75/28 75

76 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 2009 MDS - Bacalá

77 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 2009 15/03/2005 MDS - Bacalá 77/28 77

78 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 2009 MDS - Bacalá

79 Encontrando Relacionamentos
1: PerformResponsibility Diagrama de Colaboração :Client :Supplier Link Client Supplier Client Supplier Diagrama de classe 0..* 0..* Prime suppliers PerformResponsibility() Association 2009 MDS - Bacalá

80 Diagrama final 2009 15/03/2005 MDS - Bacalá 80/28 80

81 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 2009 MDS - Bacalá

82 Passo 5: Qualificar mecanismos de análise
Mapear classes de análise em mecanismos de análise Classes de análise Mecanismos de análise Estudante Persistente ControladorMatricula Distribuição, Segurança Curso Persistente, Interface Legado 2009 MDS - Bacalá

83 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 … … … 2009 MDS - Bacalá

84 Projetar classes

85 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 2009 MDS - Bacalá

86 Passos do projeto de classes
Para cada classe: Criar classes de projeto Identificar classes persistentes Definir métodos Definir atributos Definir estados Definir relacionamentos Contemplar os requisitos não-funcionais 2009 MDS - Bacalá

87 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 2009 MDS - Bacalá

88 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… 2009 MDS - Bacalá

89 Projetando classes de entidade
Classes de Entidade são Transitórias Persistentes São detalhadas no passo “Identificar classes persistentes” 2009 MDS - Bacalá

90 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 2009 MDS - Bacalá

91 Passo 2: Identificando classes persistentes
Instancias da classe precisam preservar o seu estado Estratégia de persistencia é definida para cada classe persistente JDBC Curso BD Relacional Serialização Candidato Arquivo 2009 MDS - Bacalá

92 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 2009 MDS - Bacalá

93 Mapeando operações - concreto Análise Projeto + concreto :Cliente
:Fornecedor // Realizar alguma operação Análise Projeto :Cliente :Fornecedor fazerAlgo() + concreto 2009 MDS - Bacalá

94 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 2009 MDS - Bacalá

95 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 2009 MDS - Bacalá

96 Diagrama de Estados Um diagrama de estados mostra o ciclo de vida de um objeto Evento(args) [condição] / Operacao(args) ^obj.enviarMensagem(args) Nome do estado Estado Variavel: Tipo = valor Ação de entrada Ação de saída Ações Atividade Atividades Transição 2009 MDS - Bacalá

97 Exemplo de diagrama de estado
Adiciona Aluno / contador = 0 Adiciona Aluno[ contador < 10 ] [ contador = 10 ] Cancela Inicializado Aberto Fechado Cancelado do: Incializa Curso do: Finaliza curso do: Notifica Alunos 2009 MDS - Bacalá

98 Passo 6: Definir Relacionamentos
Dependências Associações Simples Agregação Composição Generalização 2009 MDS - Bacalá

99 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, …) 2009 MDS - Bacalá

100 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 2009 MDS - Bacalá