A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Análise e Projeto no RUP. 2009MDS - Bacalá215/03/20052/28 Contexto  Após a etapa de análise de requisitos, temos documentos de requisitos e os casos.

Apresentações semelhantes


Apresentação em tema: "Análise e Projeto no RUP. 2009MDS - Bacalá215/03/20052/28 Contexto  Após a etapa de análise de requisitos, temos documentos de requisitos e os casos."— Transcrição da apresentação:

1 Análise e Projeto no RUP

2 2009MDS - Bacalá215/03/20052/28 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.

3 2009MDS - Bacalá315/03/20053/28 Contexto RequisitosAnáliseProjeto

4 2009MDS - Bacalá415/03/20054/28 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?

5 2009MDS - Bacalá515/03/20055/28 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

6 2009MDS - Bacalá615/03/20056/28 Casos de Uso X Análise

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

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

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

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

11 2009MDS - Bacalá11 Realização de Caso de Uso Caso de Uso Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto  Requisitos   Analise e projeto 

12 2009MDS - Bacalá12 Fluxo de Análise e Projeto Diagrama de Atividades

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

14 2009MDS - 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

15 2009MDS - Bacalá15 Definir a arquitetura candidata

16 2009MDS - 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

17 2009MDS - Bacalá17 Analisar comportamento

18 2009MDS - 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

19 2009MDS - Bacalá19 Projetar componentes

20 2009MDS - 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

21 2009MDS - Bacalá21 Projetar Banco de Dados

22 2009MDS - 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

23 2009MDS - Bacalá23 Refinar Arquitetura

24 2009MDS - 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

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

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

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

28 2009MDS - Bacalá28 Fluxo de atividades simplificado 1.Analisar Arquitetura 2.Analisar Caso de Uso 3.Projetar Classes 4.Projetar Banco de Dados

29 Analisar Arquitetura

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

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

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

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

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

35 2009MDS - 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)

36 Analisar Caso de Uso

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

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

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

40 2009MDS - 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 ( >) Controle ( >) Entidade ( >)

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

42 2009MDS - Bacalá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 > Notação em UML

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

44 2009MDS - Bacalá44 Exemplo de classes de fronteira Matricular-se Em disciplina EstudanteSistema Academico > FormRegistroCursos > SistemaAcademico

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

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

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

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

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

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

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

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

53 2009MDS - Bacalá5315/03/200553/28 Exemplo

54 2009MDS - Bacalá5415/03/200554/28 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

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

56 2009MDS - Bacalá5615/03/200556/28 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 ( >).

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

58 2009MDS - Bacalá5815/03/200558/28 Exemplo

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

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

61 2009MDS - 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

62 2009MDS - 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

63 2009MDS - 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

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

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

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

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

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

69 2009MDS - Bacalá6915/03/200569/28 Exemplo

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

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

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

73 2009MDS - Bacalá7315/03/200573/28 Classes com métodos

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

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

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

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

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

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

80 2009MDS - Bacalá8015/03/200580/28 Diagrama final

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

82 2009MDS - Bacalá82 Passo 5: Qualificar mecanismos de análise  Mapear classes de análise em mecanismos de análise Classes de análiseMecanismos de análise EstudantePersistente ControladorMatriculaDistribuição, Segurança CursoPersistente, Interface Legado

83 2009MDS - Bacalá83 Passo 6: Unificar classes de análise Realização de Caso de Uso … … …

84 Projetar classes

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

86 2009MDS - Bacalá86 Passos do projeto de classes 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 Para cada classe:

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Carregar ppt "Análise e Projeto no RUP. 2009MDS - Bacalá215/03/20052/28 Contexto  Após a etapa de análise de requisitos, temos documentos de requisitos e os casos."

Apresentações semelhantes


Anúncios Google