Anlise e Projeto no RUP 2010 Anlise e

Análise e Projeto no RUP 2010 Análise e Projeto I

Tópicos abordado n n Visão geral do RUP Introdução à disciplina de Análise & Projeto n n n Atividades Papéis Artefatos 2010 Análise e Projeto I 2

Processos de Software n n Definição: “Todos os elementos do mundo real envolvidos no desenvolvimento e manutenção de um produto de software” Processos vem sendo propostos pela indústria, países e academia n n n n Análise Estruturada (Yourdon, Gane) Método de Jackson Objectory (Jacobson) V-Model (Alemanha) Catalysis Rational Unified Process - RUP XP - e. Xtreme Programming 2010 Análise e Projeto I 3

Características de um Processo Eficiente n n Orienta o desenvolvimento, operação e manutenção de software Reduz risco e aumenta previsibilidade Utiliza boas práticas de desenvolvimento de software Permite controle sobre o desenvolvimento dentro de custos, prazos e níveis de qualidade desejados Qualidade x produtividade 2010 Análise e Projeto I 4

O que é Processo Unificado n Modelo de Processo Padrão n n n Descrição de atividades que compõem um processo que adota UML Mais simples que a proposta da Rational Produto comercial n n n Desenvolvido e mantido pela Rational Integrado a uma suíte de produtos Disponível em CD-ROM / Internet n n n http: //www. labes. ufpa. br/quites/rup/ Conhecido como Rational Unified Process E-coach: treinamento a distância n http: //www. rational. com/rup n Para o treinamento online, clicar em “Trials & Betas” 2010 Análise e Projeto I 5

Características do RUP n n n Usa UML Baseado em componentes Framework para processos n n n Orientado a casos de uso Iterativo e incremental Centrado na arquitetura 2010 Análise e Projeto I 6

Orientado a Casos de uso n O que é um caso de uso? n Usados para capturar os requisitos funcionais do sistema “Falam” a “linguagem do usuário” n Estão sempre associados a um ator n Representação de uma funcionalidade do sistema, que fornece um resultado de valor para um usuário 2010 Análise e Projeto I 7

Orientado a Casos de uso n Por que o RUP é orientado a casos de uso? n n Casos de uso são usados para especificar requisitos Durante a análise, projeto e implementação os casos de uso são “realizados” Durante os testes, verifica-se se o sistema realiza o que está descrito no Modelo de Casos de Uso Casos de uso são usados no planejamento e acompanhamento das iterações 2010 Análise e Projeto I 8

Iterativo e Incremental R A/P I/T R R A/P I/T I I Tempo R A/P I/T I Fonte: Rational 2010 Análise e Projeto I 9

Iterativo e Incremental n n n Dividir para conquistar! O desenvolvimento ocorre em várias iterações, cada uma delas resultando em extensão de funcionalidade e/ou maior conhecimento do sistema Os maiores riscos devem ser tratados nas primeiras iterações 2010 Análise e Projeto I 10

Centrado na Arquitetura Estimula a definição de uma arquitetura robusta nas fases iniciais do desenvolvimento n A arquitetura guia o projeto e implementação das diversas partes do sistema n Os casos de uso dizem o que deve ser feito e a arquitetura descreve como n 2010 Análise e Projeto I 11

“Espírito” do RUP n O gerenciamento de Riscos deve ser feito continuamente n n A cada iteração (novos) riscos devem ser identificados e tratados; Isto “garante” que o desenvolvimento terá sucesso; 2010 Análise e Projeto I 12

“Espírito” do RUP n Foco em Funcionalidades para o Cliente n n Especificação, organização e documentação dos requisitos é facilitada através dos diagramas de casos de uso; Casos de uso guiam todo o processo de desenvolvimento O que desenvolver, testar e validar em cada iteração; Casos de uso são funcionalidades para o cliente; 2010 Análise e Projeto I 13

“Espírito” do RUP n Foco em Software Executável n n Artefatos são construídos para facilitar e documentar o processo de desenvolvimento; Mas, não é necessário construir todos os artefatos indicados pelo RUP; 2010 Análise e Projeto I 14

“Espírito” do RUP n Aprenda a lidar com Mudanças n n Mudanças são inevitáveis no processo de desenvolvimento; Adote estratégias para gerenciar mudanças n n n Tomada de decisão sobre uma mudança; Impacto desta mudança no sistema; Minimizar o custo desta mudança; 2010 Análise e Projeto I 15

“Espírito” do RUP n Defina uma Arquitetura estável cedo n n Uma arquitetura do sistema é definida, implementada e testada no início do processo (Elaboração) para garantir que o sistema atenderá aos requisitos funcionais e nãofuncionais; Com a arquitetura definida, o processo de construção é mais simples; 2010 Análise e Projeto I 16

“Espírito” do RUP n Considere continuamente a Qualidade n O controle de qualidade deve ser feito desde o início do processo de desenvolvimento n n n Inspeção de software; Teste dos casos de uso implementados; Definição de casos de teste a partir dos casos de uso; 2010 Análise e Projeto I 17

“Espírito” do RUP n Desenvolvimento Iterativo n n n “Impossível” desenvolver o sistema em uma única iteração; A cada iteração mais detalhes são adicionados; Diversas vantagens: n n Redução da Complexidade; Facilidade para lidar com mudanças nos requisitos, cronograma, etc. 2010 Análise e Projeto I 18

Conceitos do RUP n n n Fases e Iterações Fluxos de Atividades Artefatos Responsáveis 2010 Análise e Projeto I 19

Estrutura do RUP n Processo Iterativo, baseado no modelo Espiral n n Iterativo: baseado em sucessivas versões Espiral 2010 Análise e Projeto I 20

Fases do RUP Concepção Elaboração Construção Transição Estabelecer o escopo e viabilidade econômica do projeto Eliminar principais riscos e definir arquitetura estável Desenvolver o produto até que ele esteja pronto para beta testes Entrar no ambiente do usuário 2010 Análise e Projeto I 21

Fases e Iterações n Cada fase pode comportar diversas iterações Concepção Elaboração Construção Iteração preliminar 1 2 i i+2 i+3 . . . Transição j j+1 . . . tempo grandes marcos 2010 Análise e Projeto I 22

Fluxos de Atividades do RUP n n Agrupam atividades correlacionadas Fluxos de atividades básicos: n n n n modelagem do negócio requisitos análise e projeto implementação testes distribuição Fluxos de atividades de suporte: n n n gerência de configuração e mudanças gerência do projeto configuração do ambiente 2010 Análise e Projeto I 23

Fases, Iterações e Fluxos de Atividades Fonte: Rational 2010 Análise e Projeto I 24

Responsáveis, Atividades e Artefatos n Os fluxos de atividades do RUP são descritos através de responsáveis, atividades e artefatos Fonte: Rational 2010 Análise e Projeto I 25

Conceitos-chave 2010 Análise e Projeto I 26

Análise & Projeto 2010 Análise e Projeto I

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 2010 Análise e Projeto I 28

Análise versus Projeto n n n Foco no entendimento do problema Projeto idealizado Comportamento Estrutura do sistema Requisitos funcionais Modelos simples n n n n 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 2010 Análise e Projeto I 29

Visão geral dos artefatos Modelo de análise e projeto Modelo de caso de uso Análise e projeto Documento da arquitetura Modelo de dados Glossário Documento requisitos 2010 Análise e Projeto I 30

Modelo de Analise e Projeto n n n 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 n n Modelo de Analise Modelo de Projeto 2010 Análise e Projeto I 31

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 Requisitos Analise e projeto 2010 Análise e Projeto I 32

Fluxo de Análise e Projeto Diagrama de Atividades 2010 Análise e Projeto I 33

Realizar síntese da arquitetura 2010 Análise e Projeto I 34

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

Definir a arquitetura candidata 2010 Análise e Projeto I 36

Objetivo n n n 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 2010 Análise e Projeto I 37

Analisar comportamento 2010 Análise e Projeto I 38

Objetivo n 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 2010 Análise e Projeto I 39

Projetar componentes 2010 Análise e Projeto I 40

Objetivo n n 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 2010 Análise e Projeto I 41

Projetar Banco de Dados 2010 Análise e Projeto I 42

Objetivo n n n 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 2010 Análise e Projeto I 43

Refinar Arquitetura 2010 Análise e Projeto I 44

Objetivo n n n 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 2010 Análise e Projeto I 45

Fluxo de Análise e Projeto Light Simplificando/Instanciando o processo para um contexto específico 2010 Análise e Projeto I

Motivação n O RUP é um Framework n n 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 2010 Análise e Projeto I 47

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

Analisar Arquitetura 2010 Análise e Projeto I

Analisar Arquitetura n n 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 2010 Análise e Projeto I 50

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

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

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

Mecanismos de análise n O que são? n n n 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 n n Persistência Comunicação Gerenciamento de transações Segurança 2010 Análise e Projeto I 54

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

Analisar Caso de Uso 2010 Análise e Projeto I

Objetivos n n n 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 2010 Análise e Projeto I 57

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

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

Classes de Fronteira n n Itermediam a interface para qualquer coisa externa ao sistema <<boundary>> Exemplos de classes fronteira n n GUI Interface com outros sistemas Interface com dispositivos Uma classe de Fronteira por interação ator X caso de uso Notação em UML 2010 Análise e Projeto I 60

O Papel de uma Classe de Fronteira <<boundary>> <<control>> <<boundary>> Usuário <<boundary>> <<entity>> Modela interação entre o sistema e seu ambiente 2010 Análise e Projeto I 61

Exemplo de classes de fronteira Estudante <<boundary>> Form. Registro. Cursos Matricular-se Em disciplina Sistema Academico <<boundary>> Sistema. Academico 2010 Análise e Projeto I 62

Classes de Entidade n Abstrações chave dos casos de uso <<entity>> Glossário <<entity>> Descrição do Caso de uso 2010 Análise e Projeto I 63

O Papel de uma Classe de Entidade <<boundary>> <<control>> <<boundary>> Usuário <<boundary>> <<entity>> Armazenam e gerenciam informação no sistema 2010 Análise e Projeto I 64

Exemplo de classes de entidade <<entity>> Estudante <<entity>> Curso <<entity>> Horario 2010 Análise e Projeto I 65

Classes de Controle n n Coordenam o comportamento (lógica de controle) do caso de uso Interface entre fronteira e entidade <<control>> 2010 Análise e Projeto I 66

O Papel de uma Classe de Controle <<boundary>> <<control>> <<boundary>> Usuário <<boundary>> <<entity>> Coordenam o comportamento do caso de uso 2010 Análise e Projeto I 67

Exemplo de Classe de Controle Estudante Matricular-se Em disciplina Sistema Academico <<control>> Controlador. Matricula matricurlar. Aluno() 2010 Análise e Projeto I 68

Passo 2: Distribuir comportamento n Para cada fluxo de eventos n n n 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 2010 Análise e Projeto I 69

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

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

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

Modelando interações n n n 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 n n Auxiliam a identificar classes, responsabilidades e relacionamentos Mecanismo de validação da arquitetura 2010 Análise e Projeto I 73

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

Anatomia de um Diagrama de Seqüência Objetos : Fornecedor : Cliente Linha da vida 1: Solicita serviço Mensagem Foco do controle 2010 Análise e Projeto I Mensagem reflexiva 1. 1: Solicita outro serviço Numeração hierárquica 75

Exemplo de diagrama de Seqüência janela de matrícula : Aluno controle de matrícula mat 101 section 1 1: preenche info 2: submete 3: ad curso(Jose, mat 101) 4: ad(Jose) 5: curso aberto? 6: ad(Jose) 2010 Análise e Projeto I 76

Diagrama de Colaboração Objetos : Cliente Ligação 1: Solicita serviço : Fornecedor Mensagem 2010 Análise e Projeto I 77

Exemplo de diagrama de colaboração janela de curso : 1: informação do curso 2: processa Janela. Curso 3: adiciona curso : Secretaria gerenciador : curso : Gerenciador. Curriculo Curso 4: novo curso 2010 Análise e Projeto I 78

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

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

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

Gerenciando a consistência n n n 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 2010 Análise e Projeto I 82

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

Encontrando Atributos n n Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc. São propriedades/características das classes identificadas n n n 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 2010 Análise e Projeto I 84

Encontrando Relacionamentos n n 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 n n Tipo e nome Navegabilidade Multiplicidade Papéis 2010 Análise e Projeto I 85

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

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

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

Projetar classes 2010 Análise e Projeto I

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

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

Passo 1: Criar classes de projeto n n n 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 2010 Análise e Projeto I 92

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

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

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

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

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

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

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

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

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

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

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

Passo 7: Contemplar os requisitos não-funcionais n Concretização dos mecanismos de análise n n n Incorporar responsabilidades em algumas classes Criar novas classes Exemplos: n n n 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, …) 2010 Análise e Projeto I 104

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

Exemplo 2010 Análise e Projeto I 106

Exemplo 15/03/2005 2010 Análise e Projeto I 107/28 107

Exemplo Efetuar Login n 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 n 15/03/2005 2010 Análise e Projeto I 108/28 108

Exemplo 15/03/2005 2010 Análise e Projeto I 109/28 109

Diagrama final 15/03/2005 2010 Análise e Projeto I 110/28 110

Exemplo 15/03/2005 2010 Análise e Projeto I 111/28 111

Exemplo Efetuar Login n 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 n 15/03/2005 2010 Análise e Projeto I 112/28 112

Diagrama final 15/03/2005 2010 Análise e Projeto I 113/28 113

Exemplo 15/03/2005 2010 Análise e Projeto I 114/28 114

2010 Análise e Projeto I 115

2010 Análise e Projeto I