Uma Abordagem usando PU

Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson, James Rumbaugh Ulrich Schiel

Receita de bolo Utilizar os conceitos de Processo Unificado Conjuntamente com a experiência de cada um Objetivo: Modelar um sofware (apenas projetar o que seria essa modelagem) Baseado como cliente o professor da disciplina 2

Proposta 3 Desenvolver um sistema de controle de vendedores ambulantes de um empresa. A empresa dividiu cada cidade em que atua em regiões. Cada região é controlada por um supervisor ao qual está subordinado um certo número de vendedores. Todo dia os vendedores passam pela empresa, de manhã, e registram, em um boletim de controle, a hora da partida, o roteiro de visitas planejado e o número de contratos de vendas que levaram. Ao final da tarde, cada vendedor passa por pontos, e registra o resultado das atividades do dia, ou seja, os contratos de venda fechados.

Proposta 4 Até as 20 horas, todos vendedores devem ter registrados suas produções do dia. Cada ponto da empresa, processa a esta hora, um resumo das atividades registradas e o remete para a central da empresa. No outro dia o supervisor analisa os boletins recebidos e passa-os, com alguns comentários, ao controle geral de vendas da empresa. O supervisor, além de controlar a produção dos vendedores, registra o recebimento de novos vendedores e a liberação deles para o departamento pessoal que, por sua vez, controla a contratação, alocação, relocação e demissão de vendedores e supervisores.

5 Ciclo de Vida PU

Disciplinas Requisitos Analise Projeto Implementação Testes 6

7 Requisitos

Obtenção de Requisitos Artefatos Modelo de Casos de Uso Atores Casos de Usos Descrição da arquitetura 8

Obtenção de Requisitos r e s p o n s á v e l TRABALHADOR Analista de Sistemas Especificador de Use-Cases Projetista de Interfaces Arquiteto ARTEFATO Modelo use-case atores glossários Use-cases Protótipos de interfaces Arquitetura 9

Obtenção de Requisitos Passos: 1. Listar potenciais requisitos 2. Entender o contexto do sistema 3. Capturar requisitos funcionais 4. Capturar requisitos não funcionais 10

Requisitos Passos - Concepção Listar potenciais requisitos Desenvolver uma lista de características obtidas de clientes, usuários, analistas e desenvolvedores CARACTERÍSTICA: nome breve descrição ou definição conjunto de valores Estado (proposto, aprovado, incorporado, validado) estimativa de custos prioridade (crítica, importante ou secundária) riscos (crítico, significante, ordinário) 11

Requisitos Passos - Concepção Entender o contexto do sistema Criar um modelo do domínio objetos de negócio (pedidos, contas, contratos,..) objetos do mundo real (veículos, máquinas, trajetos,..) eventos básicos (chegada de um pedido, partida de um transporte,..) usar diagramas UML, em particular diagramas de casos de uso e classe 12

Requisitos Passos - Concepção Capturar requisitos funcionais ATIVIDADES E SUBPASSOS A1) encontrar os atores e use-cases encontrar os atores encontrar e descrever cada use-case descrever o Modelo Use-Case como um todo A2) Priorizar Use-Cases (visão arquitetural) 13

Requisitos Passos - Elaboração A3) Detalhar cada Use-Case estruturar a descrição do use-case (construir um diagrama de estados e analisar cada caminho) formalizar a descrição do use-case (usar diagramas de estado, diagramas de atividade ou diagramas de interação) descrever o Modelo Use-Case como um todo 14

Requisitos Passos - Elaboração A4) Prototipar as interfaces com o usuário projeto lógico da interface do usuário projeto físico da interface do usuário e protótipo 15

Requisitos Concepção/Elaboração PROJETO LÓGICO para cada ator, ver todos use-cases nos quais está envolvido e especificar os elementos de interação (ícones, listas, campos, figuras, etc.) A mesma interface (formulário) pode aparecer em diversos use-cases para diversos atores! 16

Requisitos Concepção/Elaboração QUESTÕES para determinar os elementos de interação: quais informações o ator fornece ao sistema? quais informações o ator necessita do sistema? com quais elementos de interação o ator trabalha? quais ações o ator pode acionar e quais decisões tomar? quais classes de domínio ou entidades de negócio estão envolvidos com elementos de interação? 17

Requisitos - Elaboração Projeto Físico: combinar elementos de interação para formar interfaces que atendam a atores determinar elementos adicionais (folders, janelas, controles, etc.) desenvolver um protótipo para cada interface 18

Requisitos - Elaboração Capturar requisitos funcionais A5) Estruturar o modelo Casos de Uso identificar funcionalidades comuns (generalizações, <<estende>>) identificar funcionalidades adicionais ou opcionais identificar outros relacionamentos entre use-cases (<<inclui>>, inverso de <<estende>>) 19

Requisitos - Elaboração Capturar requisitos não-funcionais Usabilidade requisitos de interfaces metáfora, frequência de uso,.. documentação confiabilidade tolerância a falhas. performance tempos de resposta volumes de transações requisitos físicos equipamentos, material, espaços, configurações de rede, software 20

21 Analise

Análise Os requisitos externos são transformados em um modelo interno preciso e completo para desenvolver o projeto do sistema 22 MODELO USE-CASE linguagem do usuário Visão externa do sistema Estruturado por use-cases Captura a funcionalidade do sistema Usado para o contrato com o cliente Pode conter redundâncias, inconsistências, etc. MODELO DA ANÁLISE Linguagem do desenvolvedor Visão interna do sistema Estruturado por classes Descreve como realizar a funcionalidade Usado para o desenvolvedor entender o sistema Deve ser preciso e inambíguo

Análise - Artefatos 1. MODELO DA ANÁLISE Classe de fronteira EXEMPLO Interface de registro 2. CLASSE DE ANÁLISE Classe de controle processar resumo do dia Classe de entidades Boletim de controle 23

Análise - Artefatos 3. REALIZAÇÃO DE UM USE-CASE RELOGIO partida Processar resumo 4. 8 horas VENDEDOR 1.registra partida 2. abre boletim 3. registra retorno 5. dados boletim 6. Registra resumo Resumo do dia 7. mostra resumo 24 3. completa boletim 10. resumo boletim comentado de controle Resultado do dia mostra resumos 8. analisa resumo 9. comentários SUPERVISOR

Análise - artefatos 3. REALIZAÇÃO DE UM USE-CASE fluxo de eventos Descrição textual do diagrama de colaboração requisitos especiais Descrição textual de requisitos não-funcionais 4. PACOTES DE ANÁLISE Devem ter coesão e fraco acoplamento Candidatos a subsistemas do projeto PACOTE DE SERVIÇOS: é um conjunto de ações coerentes, indivisíveis para uso em vários use-cases 5. DESCRIÇÃO DA ARQUITETURA 25

Analise - Trabalhadores Arquiteto Especificador de Casos de Uso responsável que a realização de um use-case corresponde a sua especificação Especificador de componentes responsável pelas classe de análise e pelos pacotes 26

Análise - Passos 1. Análise Arquitetural 2. Análide de cada Caso de Uso 3. Análise de cada Classe 4. Análise de cada Pacote 27

Análise Arquitetura Lógica MODELO USE-CASE ARQUITETO PACOTE ANÁLISE (esboço) REQUISITOS ADICIONAIS MODELO DO DOMÍNIO Análise arquitetural CLASSE DE ANÁLISE (esboço) DESCRIÇÃO ARQUITETURA (mod. Requisitos) DESCRIÇÃO ARQUITETURA (mod. Análise) 28

Análise Arquitetura Lógica ATIVIDADES E SUBPASSOS A1) Identificar pacotes de análise Encontrar pacotes coesos e fracamente acoplados Identificar funcionalidades comuns entre pacotes (pacotes genéricos) Identificar pacotes de serviço (serviços opcionais, classes relacionadas funcionalmente) Dependências entre pacotes 29

Análise Arquitetura Lógica A2) Identificar classes de entidades óbvias Obtidas a partir das classe do domínio A3) Identificar requisitos especiais comuns Persistência Distribuição e concorrência Aspectos de segurança Tolerância a falhas Gerência de transações 30

Análise Caso de Uso encontrar as classe de análise para realizar o use-case distribuir o comportamento do use-case entre as classes identificar requisitos especiais ESPECIFICADOR DE USE-CASES 31 REQUISITOS ADICIONAIS DESCRIÇÃO ARQUITETURA (mod Análise) MODELO USE-CASE MODELO DO DOMÍNIO Análise de um Use-Case REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) CLASSE DE ANÁLISE (esboço)

Análise Caso de Uso - Passos ATIVIDADES E SUBPASSOS A1) Identificar classes de análise encontrar classes de entidades para armazenar as informações do use-case para cada ator humano, determinar uma classe de fronteira central (representa a janela principal) determinar as classe de fronteira que interagem com as classes de entidade determinar, pelo menos, uma classe de controle que coordena o use-case Construir um diagrama de Classes 32

Análise Caso de Uso - Passos A2) Descrever interações entre objetos construir um diagrama de comunicação toda classe de análise deve participar de algum diagrama de comunicação dar maior ênfase às conexões e condições do que à sequência às conexões de mensagens podem corresponder associações do diagrama de objetos ou não considerar as relações entre use-cases no diagrama A3) Determinar requisitos especiais 33

Análise Caso de Uso - Passos VENDEDOR partida boletim de controle 6. dados boletim 5. 8 horas Processar resumo 1.registra partida 3. registra retorno 2. abre boletim 7. Registra resumo Resumo do dia 8. mostra resumo 4. completa boletim 11. resumo comentado 9. analisa resumo Resultado do dia mostra resumos 10. comentários SUPERVISOR 34

Análise Classes Identificar as responsabilidades de cada classe, baseado em sua função na realização de use-cases Definir os atributos e relacionamentos Capturar requisitos especiais para cada classe CLASSE DE ANÁLISE (esboço) ESPECIFICADOR DE COMPONENTES REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) Análise de uma classe CLASSE DE ANÁLISE (completa) 35

Análise Classes - Passos A1) Identificar responsabilidades Determinar os papéis de cada classe nos diferentes use-cases A2) Definir os atributos tipos de atributos são conceituais classes com muitos atributos podem ser divididas atributos de classes de fronteira são campos em interfaces classes de controle geralmente não tem atributos A3) Identificar associações e agregações A4) Identificar generalizações A5) Determinar requisitos especiais 36

Análise Pacotes Rever as questões de acoplamento fraco e coesão Garantir que cada pacote preenche sua função Rever as dependências entre pacotes de acordo com associações estáticas ou dinâmicas entre as classes, criadas nos passos anteriores 37

38 Projeto

Projeto Adquirir uma compreensão de aspectos de requisitos não funcionais e restrições sobre linguagens de programação, sistemas operacionais, SGBDs, aspectos de distribuição, etc. Criar informações suficientes para a implementação, descrevendo subsistemas, interfaces e classes. Estar apto a dividir a tarefa de implementação em equipes Determinar mais cedo as interfaces entre os subsistemas Criar um modelo que possibilite uma implementação que preencha as estruturas definidas sem altera-las 39

Projeto MODELO DE ANÁLISE MODELO DE PROJETO conceitual físico Genérico (c.r. projeto) específico 3 tipos de classes Depende da implementação Menos formal Mais formal Mais rápido (1/5 do projeto Mais demorado (5 x análise) Poucos níveis Muitos níveis Menos dinamica Mais dinâmica, foco na sequencia Não se mantém no ciclo Se manté em todo ciclo 40

Projeto - Artefatos 1. Modelo de Projeto hierarquia de subsistemas contendo classe de projeto, projetos de use-cases e interfaces 2. Classes de Projeto na linguagem de programação da implementação visibilidade dos atributos (ex. publico, protegido, privado) generalizações herança; associações e agregações atributos métodos em pseudo-código 41

Projeto - Artefatos 3. Realização dos Casos de Uso Diagrama de classes Diagrama de interações (diagramas de sequência) Fluxo de eventos (textual) Requisitos de implementação 42

43 Projeto - Artefatos 4. Subsistema de Projeto (pacotes de análise, componentes, produtos de software, sistemas existentes) - SUBSISTEMAS DE SERVIÇO 5. Interface (separa funcionalidade de implementação) 6. Arquitetura (VISÃO DO PROJETO) (1. Subsistemas, interfaces e dependências 2. Classes chave, classes ativas 3. Realização de use-cases centrais ao sistema 7. Modelo de Distribuição (Diagrama de componentes) 8. Arquitetura (VISÃO DO MODELO DE DISTRIBUIÇÃO) (Diagrama de Implantação)

Projeto - Trabalhadores MODELO DO PROJETO Arquiteto MODELO DE DISTRIBUIÇÃO ARQUITETURA Especificador de use-cases REALIZAÇÃO DE USE CASE CLASSE DE PROJETO Especificador de componentes SUBSISTEMA INTERFACE 44

Projeto - Passos ARQUITETO ESPECIFICADOR DE USE-CASES ESPECIFICADOR DE COMPONENTES Projeto da arquitetura Projeto de uma classe Projeto de um use-case 45 Projeto de um subsistema

Projeto - Arquitetura A1) Identificar nós e suas configurações determinar os nós envolvidos e suas característica determinar os tipos de conexões entre os nós verificar necessidades de processamentos redundantes, backups, etc. A2) Identificar subsistemas e suas interfaces subsistemas da aplicação identificar middleware (SO, SGBD, software de comunicação, pacotes GUI, distribuição, etc.) definir dependências entre os subsistemas identificar as interfaces entre os subsistemas 46

Projeto - Arquitetura A3) Identificar classes de projeto significativas a partir das classes de análise classes ativas (requisitos de concorrência, performance, inicialização, distribuição, prevenção de deadlocks) A4) outros requisitos de projeto (persistência, transparência de distribuição, segurança, recuperação de erros, gerência de transações) 47

Projeto Casos de Uso OBJETIVO: identificar classes de projeto distribuir o comportamento entre os objetos definir requisitos das operações requisitos de implementação do use-case A1) Identificar classes de projeto participantes estudar as classes de análise identificar classes que realizam os requisitos especiais da análise definir as classes de projeto e passar para o projetista de componentes 48

Projeto Casos de Uso A2) Descrever a interação entre objetos o use-case é acionado por uma mensagem de um ator a um objeto traçar um ou vários diagramas de sequência utilize nomes e textos (fluxo de eventos) para descrever as sequências considere as associações entre use-cases no diagrama de sequência A3) Identificar subsistemas e interfaces identificar os subsistemas obtidos a partir de pacotes deste use-case verifique se há classes de projeto especiais e seus subsistemas A4) Descrever a interação entre subsistemas a partir dos caminhos no diagrama se sequência determinar a interação determinar qual interfaces é utilizada por qual mensagem 49

Projeto - Classe Aspectos atributos operações e sua realização relacionamentos estados dependências interfaces requisitos de implementação 50

Projeto - Classe A1) Definir uma classe de projeto a partir de classes de fronteira : depende da linguagem classes de entidades persistentes podem produzir tabelas relacionais classes de controle podem gerar várias classes de projeto (distribuição) ou serem encapsuladas em classes de entidades A2) Definir operações realizar as responsabilidades da classe requisitos especiais (e.g. acesso ao banco de dados) atender às necessidades das interfaces da classe A3) Definir atributos considerar os atributos da análise os tipos dos atributos são determinados pela linguagem de programação valores de atributos usados por vários objetos devem ser transformados em objetos 51

Projeto - Classe A4) Identificar associações e agregações dependendo da linguagem, transformá-los em relacionamentos tentar transformar cardinalidades, papéis, etc. em atributos ou em novas classes para realizar a associação analise a navegabilidade pelas associações A5) Identificar generalizações A6) Descrever métodos realização de operações por pseudo-código, diagramas de atividades, linguagem natural,.. A7) Descrever estados diagrama de estados 52

Projeto - Subsistema 1. Rever as dependências entre subsistemas 2. Rever as interfaces 3. Rever o conteúdo 53

Implementação 1. MODELO DA IMPLEMENTAÇÃO 2. COMPONENTE 3. SUBSISTEMA DE IMPLEMENTAÇÃO 4. INTERFACE 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO 54

Implementação MODELO DA IMPLEMENTAÇÃO É uma hierarquia de subsistemas de implementação contendo componentes e interfaces COMPONENTE É UM PACOTE CONTENDO ELEMENTOS DO PROJETO Diagrama de Componentes <<executable>> (programa executável) <<file>> (arquivo contendo código fonte ou dados) <<library>> (biblioteca estática ou dinâmica) <<table>> (tabela do banco de dados) <<document>> (um documento) 55

Implementação SUBSISTEMAS DE IMPLEMENTAÇÃO um package em Java um project em Visual Basic um diretório de C++ INTERFACES Implementam as interfaces do projeto ARQUITETURA (visão da implementação) Decomposição em subsistemas, compostos de interfaces e componentes e Componentes chave PLANO DE INTEGRAÇÃO Primeira versão executável: testes localizados de integração para facilitar a detecção de erros:=>versão final 56

Implementação - Trabalhadores MODELO DA IMPLEMENTAÇÃO Arquiteto MODELO DE DISTRIBUIÇÃO DESCRIÇÃO DA ARQUITETURA COMPONENTE Engenheiro de componentes SUBSISTEMA DE IMPLEMENTAÇÃO INTERFACE Integrador do sistema PLANO DE INTEGRAÇÃO 57

Implementação - Passos ARQUITETO INTEGRADOR DE SISTEMAS ENGENHEIRO DE COMPONENTES Implementação arquitetural Implementar um subsistema Teste de unidade Integrar sistemas 58 Implementar uma classe

Teste Planejar os testes em cada iteração, tanto os testes de integração quanto os testes de sistema preparar casos de teste, criar procedimentos de teste e procedimentos executáveis Realizar os testes e analisar os resultados 59

Teste - Artefatos Modelo de Teste Casos de Teste 60

61 Ciclo de Vida PU