Baixe o app para aproveitar ainda mais
Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original
* * * * 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. A empresa possui diversos pontos distribuídos na cidade. 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 um pontos, e registra o resultado das atividades do dia, ou seja, os contratos de venda fechados. 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. * * ARTEFATOS Modelo Use-Case ator Use-Case descrição da arquitetura * * Profissionais Analista de sistemas arquiteto Especificador de Use-Case projetista de interfaces * * PASSOS listar requisitos entender o contexto do sistema capturar requisitos funcionais capturar requisitos não-funcionais * * listar requisitos Resultado:Lista de características obtidas de clientes, usuários, analistas e desenvolvedores PARA CADA REQUISITO: 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) * * 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 classe * * capturar requisitos funcionais ARTÍFICE ARTEFATO Analista de Sistemas Especificador de Use-Cases Projetista de Interfaces Arquiteto Modelo use-case atores glossários Protótipos de interfaces Use-cases Arquitetura responsável * * 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) * * capturar requisitos funcionais ATIVIDADES E SUBPASSOS 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 * * capturar requisitos funcionais ATIVIDADES E SUBPASSOS 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 * * 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.) N.B. a mesma interface (formulário) pode aparecer em diversos use-cases para diversos atores! 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? * * 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 * * capturar requisitos funcionais ATIVIDADES E SUBPASSOS A5) Estruturar o modelo Use-Case identificar funcionalidades comuns (generalizações, <<estende>>) identificar funcionalidades adicionais ou opcionais identificar outros relacionamentos entre use-cases (<<inclui>>, inverso de <<estende>>) * * capturar requisitos não-funcionais ATIVIDADES usabilidade requisitos de interfaces metáfora, frequência de uso, .. documentação confiabilidade tolerância a falhas. * * capturar requisitos não-funcionais ATIVIDADES performance tempos de resposta volumes de transações requisitos físicos equipamentos, material, espaços, configurações de rede, software * * * * Os requisitos externos são transformados em um modelo interno preciso e completo para desenvolver o projeto do sistema * * 2. CLASSE DE ANÁLISE Classe de fronteira Classe de controle Classe de entidades EXEMPLO Interface de registro processar resumo do dia Boletim de controle 1. MODELO DA ANÁLISE * * 3. REALIZAÇÃO DE UM USE-CASE Diagramas de classe Diagramas de colaboração Resultado do dia Processar resumo boletim de controle VENDEDOR partida Resumo do dia SUPERVISOR mostra resumos 1.registra partida 3. registra retorno 2. abre boletim 3. completa boletim 5. dados boletim 6. Registra resumo 8. analisa resumo 9. comentários 7. mostra resumo 10. resumo comentado RELOGIO 4. 8 horas * * 3. REALIZAÇÃO DE UM USE-CASE (cont.) requisitos especiais fluxo de eventos Descrição textual de requisitos não-funcionais Descrição textual do diagrama de colaboração 4. PACOTES DE ANÁLISE PACOTE DE SERVIÇOS Devem ter coesão e fraco acoplamento Candidatos a subsistemas do projeto é um conjunto de ações coerentes, indivisíveis para uso em vários use-cases 5. DESCRIÇÃO DA ARQUITETURA * * arquiteto Especificador de Use-Case Especificador de componentes ARTÍFICES responsável pela integridade global do modelo de análise (corretude, consistência e legibilidade), tanto pela sua funcionalidade quanto pela arquitetura responsável que a realização de um use-case corresponde a sua especificação responsável pelas classe de análise e pelos pacotes * * PASSOS Análise arquitetural Análise de cada Use-Case Análise de cada classe Análise de cada pacote * * Análise arquitetural Análise arquitetural MODELO USE-CASE REQUISITOS ADICIONAIS MODELO DO DOMÍNIO DESCRIÇÃO ARQUITETURA (mod. Requisitos) ARQUITETO DESCRIÇÃO ARQUITETURA (mod. Análise) CLASSE DE ANÁLISE (esboço) PACOTE ANÁLISE (esboço) * * Análise arquitetural 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 * * Análise arquitetural (cont.) 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 * * Análise de cada Use-Case encontrar as classe de análise para realizar o use-case distribuir o comportamento do use-case entre as classes identificar requisitos especiais Análise de um Use-Case MODELO USE-CASE REQUISITOS ADICIONAIS MODELO DO DOMÍNIO DESCRIÇÃO ARQUITETURA (mod Análise) ESPECIFICADOR DE USE-CASES CLASSE DE ANÁLISE (esboço) REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) * * Análise de cada Use-Case 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 * * Análise de cada Use-Case (cont.) A2) Descrever interações entre objetos construir um diagrama de colaboração toda classe de análise deve participar de algum diagrama de colaboraçã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 * * Resultado do dia Processar resumo boletim de controle VENDEDOR partida Resumo do dia mostra resumos 1.registra partida 3. registra retorno 2. abre boletim 4. completa boletim 6. dados boletim 7. Registra resumo 9. analisa resumo 10. comentários 8. mostra resumo 11. resumo comentado 5. 8 horas RELÓGIO SUPERVISOR Análise de cada Use-Case (cont.) * * Análise de cada classe 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 Análise de uma classe REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) ESPECIFICADOR DE COMPONENTES CLASSE DE ANÁLISE (completa) CLASSE DE ANÁLISE (esboço) * * Análise de cada classe A3) Identificar associações e agregações 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 A1) Identificar responsabilidades Determinar os papéis de cada classe nos diferentes use-cases A4) Identificar generalizações A5) Determinar requisitos especiais * * Análise de cada pacote Rever as dependências entre pacotes de acordo com associações estáticas ou dinâmicas entre as classes, criadas nos passos anteriores Garantir que cada pacote preenche sua função Rever as questões de acoplamento fraco e coesão * * 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, descre- vendo 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 OBJETIVOS * * 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 * * 1. MODELO DE PROJETO É uma hierarquia de subsistemas contendo classe de projeto, projetos de use-cases e interfaces 2. CLASSE 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 * * 3. REALIZAÇÃO DO USE-CASE Diagrama de classes Diagrama de interações (diagramas de sequência) Fluxo de eventos (textual) Requisitos de implementação * * 7. MODELO DE DISTRIBUIÇÃO (Diagrama de nós e conexões) 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 4. SUBSISTEMA DE PROJETO (pacotes de análise, componentes, produtos de software, sistemas existentes) - SUBSISTEMAS DE SERVIÇO 8. ARQUITETURA (VISÃO DO MODELO DE DISTRIBUIÇÃO) * * Arquiteto Especificador de use-cases Especificador de componentes MODELO DO PROJETO ARQUITETURA MODELO DE DISTRIBUIÇÃO REALIZAÇÃO DE USE CASE CLASSE DE PROJETO SUBSISTEMA INTERFACE * * Projeto de um use-case Projeto de uma classe Projeto de um subsistema Projeto da arquitetura ARQUITETO ESPECIFICADOR DE COMPONENTES ESPECIFICADOR DE USE-CASES * * Projeto da arquitetura A1) Identificar nós e configurações de rede determinar os nós envolvidos e suas características determinar os tipos de conexões entre os nós verificar necessidades de processamentos redundantes, backups, etc. * * Projeto da arquitetura (cont.) 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 Pacote (análise) Subsistema novo Software existente Não serve como subsistema É integrado com sistemas existentes * * Projeto da arquitetura (cont.) 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) * * Projeto de um 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 OBJETIVO: identificar classes de projeto distribuir o comportamento entre os objetos definir requisitos das operações requisitos de implementação do use-case * * Projeto de um use-case (cont.) 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 * * Projeto de um use-case (cont.) 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 * * Projeto de uma 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 ASPECTOS: atributos operações e sua realização relacionamentos estados dependências interfaces requisitos de implementação * * Projeto de uma classe (cont.) 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 * * Projeto de uma classe (cont.) 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 * * Projeto de um subsistema A1) Rever as dependências entre subsistemas A2) Rever as interfaces A3) Rever o conteúdo * * 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 * * 1. MODELO DA IMPLEMENTAÇÃO É uma hierarquia de subsistemas de implementação contendo componentes e interfaces 2. COMPONENTE <<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) É UM PACOTE CONTENDO ELEMENTOS DO PROJETO Estereótipos: * * 2. COMPONENTE - exemplos <<executable>> ProcessaBoletim.java <<table>> Resumo BOLETIM __________ __________ RESUMO __________ __________ <<table>> Contrato realiza realiza gera gera * * 3. SUBSISTEMAS DE IMPLEMENTAÇÃO um package em Java um project em Visual Basic um diretório de C++ CORRESPONDÊNCIA 1-1 COM SUBSISTEMAS DE PROJETO 4. INTERFACES Implementam as interfaces do projeto * * 5. ARQUITETURA (visão da implementação) 6. PLANO DE INTEGRAÇÃO Decomposição em subsistemas, compostos de interfaces e componentes Componentes chave Primeira versão executável testes localizados de integração para facilitar a detecção de erros versão final * * Arquiteto Integrador do sistema Engenheiro de componentes MODELO DA IMPLEMENTAÇÃO DESCRIÇÃO DA ARQUITETURA MODELO DE DISTRIBUIÇÃO PLANO DE INTEGRAÇÃO COMPONENTE SUBSISTEMA DE IMPLEMENTAÇÃO INTERFACE * * * * PASSOS Implementação arquitetural Integrar sistemas Implementar subsistema Testar componentes Implementar uma classe * * Integrar sistemas Implementar uma classe Implementar um subsistema Implementação arquitetural ARQUITETO ENGENHEIRO DE COMPONENTES INTEGRADOR DE SISTEMAS Teste de unidade * * Implementação arquitetural identificar componentes significativos Integrar sistemas determinar sequência de construção integrar construções (compilar e linkar novos componentes) * * Implementar subsistema garantir conteúdo do subsistema Implementar uma classe implementar métodos determinar operações/métodos auxiliares * * Teste OBJETIVOS 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 * * Teste - artefatos 1. MODELO DE TESTE Planejar os testes em cada iteração, tanto os 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 2. CASO DE TESTE * * Fases X Etapas Fases Concepção Elaboração Construção Transição Requisitos Análise Projeto Implementação Testes Iter. #1 Iter. #2 _ _ _ _ _ Iter. #n-1 Iter. #n * * As quatro Fases Fase de Concepção estabelece o business case (prioridade de negócio) Delimitar o escopo do sistema Determinar arquitetura candidata (elementos novos, arriscados) Identificar riscos críticos Identificar potenciais usuários ou clientes do sistema Passos * * As quatro Fases Fase de Elaboração determina uma arquitetura estável Determinar linha base da arquitetura cobrindo funcionalidades significantes Identificar riscos críticos que podem derrubar planos, orçamentos, e prazos Determinar níveis de qualidade (confiabilidade, tempos de resposta) Definir use-cases que cobrem ca. de 80% da funcionalidade do sistema Determinar limites de pessoal, custos, prazos. Passos * * As quatro Fases Fase de Construção determina capacidades operacionais iniciais Estender o modelo de use-cases para toda a aplicação Finalizar a análise, projeto, implementação e testes Checar integridade da arquitetura (com possíveis alterações) Monitorar ricos críticos Passos * * As quatro Fases Fase de transição transforma versão beta em um sistema operacional Preparar atividades de transição Avisar clientes sobre mudanças no ambiente (hardware, software, distribuição, ..) Preparar documentação final Carregar o novo sistema Corrigir possíveis defeitos detectados no beta-teste Passos * * Iterativo e incremental Uma ITERAÇÃO genérica é composta pelas 5 etapas: Requisitos, Análise, Projeto, Implementação e Testes Após cada iteração ou cada fase: planejar a próxima iteração à luz da experiência anterior modificar o processo, adaptar ferramentas, treinamento, etc. * * Iterativo e incremental requisitos análise projeto Implement. testes planejamento consolidação ITERAÇÃO * * Iterativo e incremental Planejando as ITERAÇÕES Planejando as FASES tempos por fase milestones iterações por fase plano do projeto cronograma conteúdo: - quais use-cases serão realizados - iterações anteriores e posteriores * * Riscos Possíveis riscos: Gerenciar uma lista de riscos: descrição prioridade (crítico, signifcante, rotineiro) impacto responsabilidades contingência (o que fazer?) relacionados a um produto não conseguir a arquitetura não realizar os requisitos * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Compartilhar