Processo Unificado de Desenvolvimento de Software G Booch

Processo Unificado de Desenvolvimento de Software G. Booch, Ivar Jacobson, James Rumbaugh Rational Software Corporation UNIVERSIDADE FEDERAL DA PARAÍBA DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO © Ulrich Schiel

PRECURSORES Object Modeling Technique - OMT de J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy e W. Lorensen (TMO - Técnica de Modelagem de Objetos), 1991 Objectology - A Use-Case Driven Approach de I. Jacobson, M. Ericsson e A. Jacobson, 1992 Object Oriented Analysis and Design - OOA & OOD de G. Booch, 1994

CARACTERÍSTICAS íbaseado em componentes que realizam interfaces íusa UML íaspectos: * dirigido por Use-Cases * centrado em arquitetura * iterativo e incremental íos 4 Ps: pessoal, projeto, produto e processo

P 4 = Pessoa, Projeto, Produto, Processo PESSOAS financiam, escolhem, desenvolvem, gerenciam, testam, usam e são beneficiadas por produtos PROJETOS sofrem alterações. Determinam os tipos de pessoas que irão trabalhar no projeto e os artefatos que serão usados ciclo Sistema-i fase iteração Sistema-i+1

P 4 = Pessoa, Projeto, Produto, Processo PRODUTO código fonte, código de máquina, subsistemas, classes, diagramas: interação, de estados e outros artefatos ARTEFATO é qualquer tipo de informação criada por uma pessoa (diagramas UML, textos, modelos de interfaces) PROCESSO define quem faz o que, quando e como PU é um processo. Considera fatores organizacionais, do domínio, ciclo de vida e técnicos

Modelos descrevem o sistema a ser desenvolvido, sob um certo ponto-de-vista, e seu ambiente, ou seja, os atores REQUISITOS - funcionais e não-funcionais ANÁLISE classes e responsabilidades PROJETO classes de projeto, subsistemas, interfaces DISTRIBUIÇÃO nós físicos e os componentes em cada nó IMPLEMENTAÇÃO código fonte (DLLs, Java. Beams, Active. X) TESTE casos de teste (baseado nos use-cases)

Dirigido a Use-Cases Cada use-case representa uma sequência de ações que produzem um resultado de utilidade para um ator Um ator é uma pessoa ou outro sistema Cada use-case é um requisito funcional do sistema Modelo Use-Case = use-cases = funcionalidade do sistema Os Use-Cases acompanham todo o processo de desenvolvimento: Especificação de Requisitos, Análise, Projeto, Implementação e Testes

Dirigido a Use-Cases Porque USE-CASES? ? êCapturar os requisitos: o Diagrama Use-Case mostra quais atores usam quais use-cases êDirigir o processo: para realizar os use-cases são definidos classificadores (classes, subsistemas, interfaces) e relacionamentos (colaborações) entre estes êElaborar a arquitetura, determinar iterações, determinação dos manuais de usuário dirige Use-Cases Arquitetura do sistema influi

Dirigido a Use-Cases Modelo USE-CASE Modelo ANÁLISE Classe de fronteira Classe de controle Modelo PROJETO Classe Modelo IMPLEMENT <executável> relacionamento <arquivo> Classe de entidades <arquivo>

Dirigido a Use-Cases êDirigir o processo: ANÁLISE: definir as CLASSES DE ANÁLISE para realizar um use-case (classes limite, classes de controle e classes de entidades) PROJETO: ENTRADA: modelo de análise, pacote de construção de interfaces, SGBD, sistemas existentes. SAIDA: classificadores (classes, subsistemas, interfaces), relacionamentos e colaborações IMPLEMENTAÇÃO: criação de programas executáveis e arquivos que realizam os use-cases TESTE: casos de teste e procedimentos de teste. Testar entradas, resultados e condições

Centrado na arquitetura DECISÕES SOBRE: • a organização do sistema como um todo • os elementos estruturais, interfaces e seu comportamento • composição de elementos estruturais e comportamentais em subsistemas A ARQUITETURA descreve as partes essenciais do sistema, importantes para todos desenvolvedores Menos de 10% das classes são relevantes para a arquitetura Descrição de REQUISITOS ADICIONAIS: segurança, distribuição, concorrência, plataformas, etc.

Centrado na arquitetura Use-Cases influem Plataforma de software Disponibilidade de blocos reusáveis Sistemas existentes Hardware existente Requisitos não-funcionais (performance, segurança) Arquitetura

Centrado na arquitetura função PRODUTO forma Use-Case Arquitetura Sequência para o arquiteto: ØCriar uma visão preliminar da arquitetura ØAnalisar os use-cases chave (5 -10%) e especificar um subsistema para cada um ØPela especificação dos subsistemas aparecem mais detalhes da arquitetura e novos use-cases ØRepetir o passo acima, até terminar o sistema

4 FASES CONCEPÇÃO ELABORAÇÃO CONSTRUÇÃO TRANSIÇÃO

Iterativo e incremental Projetos grandes são divididos em mini-projetos Cada mini-projeto é uma iteração Cada iteração gera um incremento PORQUE ITERATIVO E INCREMENTAL • atenuar riscos • obter arquitetura robusta • facilitar alterações táticas ou contínuas • conseguir aprendizado mais cedo • Um grupo de use-cases que estendem usabilidade Fatores de risco mais importantes MINIPROJETO

Iterativo e incremental Fases

Iterativo e incremental Cada fase termina com um MARCO (milestone): Um CICLO é uma sequência das 4 fases. Um projeto pode necessitar de vários ciclos. INICIO: INICIO o que o sistema fará? Como poderia ser a arquitetura? Prazos e custos? • identificar os riscos • fixar subconjunto chave -> arquitetura candidata • estimativas iniciais (custos, esforços, alocações e qualidade do produto) • iniciar caso gerencial (business case)

Iterativo e incremental ELABORAÇÃO: use-cases especificados e esqueleto da arquitetura definido • identificar e reduzir riscos de construção • especificar maioria dos use-cases • fixar a arquitetura em proporções executáveis • preparar o plano de projeto (para a próxima fase) • estimar e justificar o orçamento • finalizar o business case CONSTRUÇÃO: software feito • iterações garantindo viabilidade em forma executável -> incrementos TRANSIÇÃO: beta-teste feito por poucos usuários. Treinamento, documentação • eliminar problemas e erros não identificados previamente

O PROCESSO UNIFICADO

EXEMPLO 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.

Modelos Requisitos produz ARTEFATOS Análise Projeto Implementação Testes produzido-por composto-por ARTÍFICES PASSOS e ATIVIDADES

Obtenção dos Requisitos ARTEFATOS èModelo Use-Case èator èUse-Case èdescrição da arquitetura

Obtenção dos Requisitos ARTÍFICES èAnalista de sistemas èarquiteto èEspecificador de Use-Case èprojetista de interfaces

Obtenção dos Requisitos PASSOS èlistar potenciais requisitos èentender o contexto do sistema ècapturar requisitos funcionais ècapturar requisitos não-funcionais

Obtenção dos Requisitos - Passos è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)

Obtenção dos Requisitos - Passos è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

Obtenção dos Requisitos - Passos ècapturar requisitos funcionais ARTÍFICE Analista de Sistemas Especificador de Use-Cases Projetista de Interfaces Arquiteto r e s p o n s á v e l ARTEFATO • Modelo use-case • atores • glossários Use-cases Protótipos de interfaces Arquitetura

Obtenção dos Requisitos - Passos ècapturar requisitos funcionais ATIVIDADES E SUBPASSOS u A 1) encontrar os atores e use-cases v encontrar os atores v encontrar e descrever cada use-case v descrever o Modelo Use-Case como um todo u A 2) Priorizar Use-Cases (visão arquitetural)

Obtenção dos Requisitos - Passos ècapturar requisitos funcionais ATIVIDADES E SUBPASSOS u A 3) Detalhar cada Use-Case v estruturar a descrição do use-case (construir um diagrama de estados e analisar cada caminho) v formalizar a descrição do use-case (usar diagramas de estado, diagramas de atividade ou diagramas de interação) v descrever o Modelo Use-Case como um todo

Obtenção dos Requisitos - Passos ècapturar requisitos funcionais ATIVIDADES E SUBPASSOS u A 4) Prototipar as interfaces com o usuário v projeto lógico da interface do usuário v projeto físico da interface do usuário e protótipo

Obtenção dos Requisitos 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?

Obtenção dos Requisitos 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

Obtenção dos Requisitos ècapturar requisitos funcionais ATIVIDADES E SUBPASSOS A 5) Estruturar o modelo Use-Case v identificar funcionalidades comuns (generalizações, <<estende>>) v identificar funcionalidades adicionais ou opcionais v identificar outros relacionamentos entre use-cases (<<inclui>>, inverso de <<estende>>)

Obtenção dos Requisitos ècapturar requisitos não-funcionais ATIVIDADES u usabilidade vrequisitos de interfaces metáfora, frequência de uso, . . v documentação u confiabilidade v tolerância a falhas.

Obtenção dos Requisitos ècapturar requisitos não-funcionais ATIVIDADES u performance v tempos de resposta v volumes de transações u requisitos físicos v equipamentos, material, espaços, configurações de rede, v software

Análise

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

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

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

Análise - artefatos 3. REALIZAÇÃO DE UM USE-CASE (cont. ) u fluxo de eventos Descrição textual do diagrama de colaboração u 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

Análise ARTÍFICES èarquiteto • responsável pela integridade global do modelo de análise (corretude, consistência e legibilidade), tanto pela sua funcionalidade quanto pela arquitetura èEspecificador de Use-Case • 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

Análise PASSOS èAnálise arquitetural èAnálise de cada Use-Case èAnálise de cada classe èAnálise de cada pacote

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

Análise - passos èAnálise arquitetural ATIVIDADES E SUBPASSOS u A 1) Identificar pacotes de análise v Encontrar pacotes coesos e fracamente acoplados v Identificar funcionalidades comuns entre pacotes (pacotes genéricos) v Identificar pacotes de serviço (serviços opcionais, classes relacionadas funcionalmente) v Dependências entre pacotes

Análise - passos èAnálise arquitetural (cont. ) A 2) Identificar classes de entidades óbvias Obtidas a partir das classe do domínio A 3) Identificar requisitos especiais comuns v Persistência v Distribuição e concorrência vaspectos de segurança v tolerância a falhas v gerência de transações

Análise - passos è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 ESPECIFICADOR DE USE-CASES MODELO USE-CASE REQUISITOS ADICIONAIS REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) MODELO DO DOMÍNIO DESCRIÇÃO ARQUITETURA (mod Análise) Análise de um Use-Case CLASSE DE ANÁLISE (esboço)

Análise - passos èAnálise de cada Use-Case u A 1) Identificar classes de análise v encontrar classes de entidades para armazenar as informações do use-case v para cada ator humano, determinar uma classe de fronteira central (representa a janela principal) v determinar as classe de fronteira que interagem com as classes de entidade v determinar, pelo menos, uma classe de controle que coordena o use-case CONSTRUIR UM DIAGRAMA DE CLASSES

Análise - passos èAnálise de cada Use-Case (cont. ) u A 2) Descrever interações entre objetos v construir um diagrama de colaboração v toda classe de análise deve participar de algum diagrama de colaboração v dar maior ênfase às conexões e condições do que à sequência v às conexões de mensagens podem corresponder associações do diagrama de objetos ou não v considerar as relações entre use-cases no diagrama u A 3) Determinar requisitos especiais

Análise - passos èAnálise de cada Use-Case (cont. ) RELÓGIO VENDEDOR partida boletim de controle 5. 8 horas 6. dados boletim Processar resumo 7. Registra resumo 1. registra partida 2. abre boletim Resumo do dia 3. registra retorno 4. completa boletim Resultado do dia 8. mostra resumo 11. resumo comentado 9. analisa resumo mostra resumos 10. comentários SUPERVISOR

Análise - passos è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 ESPECIFICADOR DE COMPONENTES CLASSE DE ANÁLISE (esboço) REALIZAÇÃO DE UM USE-CASE (diagramas de classes e de colaboração) Análise de uma classe CLASSE DE ANÁLISE (completa)

Análise - passos èAnálise de cada classe u A 1) Identificar responsabilidades v Determinar os papéis de cada classe nos diferentes use-cases u A 2) Definir os atributos v tipos de atributos são conceituais v classes com muitos atributos podem ser divididas v atributos de classes de fronteira são campos em interfaces vclasses de controle geralmente não tem atributos u A 3) Identificar associações e agregações u A 4) Identificar generalizações u A 5) Determinar requisitos especiais

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

Projeto OBJETIVOS • 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

Projeto

Projeto - artefatos 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

Projeto - artefatos 3. REALIZAÇÃO DO USE-CASE u Diagrama de classes u Diagrama de interações (diagramas de sequência) u Fluxo de eventos (textual) u Requisitos de implementação

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 nós e conexões) 8. ARQUITETURA (VISÃO DO MODELO DE DISTRIBUIÇÃO)

Projeto - artífices 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

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

Projeto - passos èProjeto da arquitetura u A 1) Identificar nós e configurações de rede v determinar os nós envolvidos e suas características v determinar os tipos de conexões entre os nós v verificar necessidades de processamentos redundantes, backups, etc.

Projeto - passos èProjeto da arquitetura (cont. ) u A 2) Identificar subsistemas e suas interfaces v subsistemas da aplicação v identificar middleware (SO, SGBD, software de comunicação, pacotes GUI, distribuição, etc. ) v definir dependências entre os subsistemas v identificar as interfaces entre os subsistemas Subsistema novo Pacote (análise) Software existente Não serve como subsistema É integrado com sistemas existentes

Projeto - passos èProjeto da arquitetura (cont. ) u A 3) Identificar classes de projeto significativas v a partir das classes de análise v classes ativas (requisitos de concorrência, performance, inicialização, distribuição, prevenção de deadlocks) u A 4) outros requisitos de projeto (persistência, transparência de distribuição, segurança, recuperação de erros, gerência de transações)

Projeto - passos èProjeto de um use-case OBJETIVO: • identificar classes de projeto • distribuir o comportamento entre os objetos • definir requisitos das operações • requisitos de implementação do use-case u A 1) Identificar classes de projeto participantes v estudar as classes de análise v identificar classes que realizam os requisitos especiais da análise v definir as classes de projeto e passar para o projetista de componentes

Projeto - passos èProjeto de um use-case (cont. ) u A 2) Descrever a interação entre objetos v o use-case é acionado por uma mensagem de um ator a um objeto v traçar um ou vários diagramas de sequência v utilize nomes e textos (fluxo de eventos) para descrever as sequências v considere as associações entre use-cases no diagrama de sequência

Projeto - passos èProjeto de um use-case (cont. ) u A 3) Identificar subsistemas e interfaces v identificar os subsistemas obtidos a partir de pacotes deste use-case v verifique se há classes de projeto especiais e seus subsistemas u A 4) Descrever a interação entre subsistemas v a partir dos caminhos no diagrama se sequência determinar a interação v determinar qual interfaces é utilizada por qual mensagem

Projeto - passos èProjeto de uma classe ASPECTOS: • atributos • operações e sua realização • relacionamentos • estados • dependências • interfaces • requisitos de implementação A 1) Definir uma classe de projeto v a partir de classes de fronteira : depende da linguagem v classes de entidades persistentes podem produzir tabelas relacionais v classes de controle podem gerar várias classes de projeto (distribuição) ou serem encapsuladas em classes de entidades

Projeto - passos èProjeto de uma classe (cont. ) A 2) Definir operações v realizar as responsabilidades da classe v requisitos especiais (e. g. acesso ao banco de dados) v atender às necessidades das interfaces da classe A 3) Definir atributos v considerar os atributos da análise v os tipos dos atributos são determinados pela linguagem de programação v valores de atributos usados por vários objetos devem ser transformados em objetos

Projeto - passos èProjeto de uma classe (cont. ) A 4) Identificar associações e agregações v dependendo da linguagem, transformá-los em relacionamentos v tentar transformar cardinalidades, papéis, etc. em atributos ou em novas classes para realizar a associação v analise a navegabilidade pelas associações A 5) Identificar generalizações A 6) Descrever métodos v realização de operações por pseudo-código, diagramas de atividades, linguagem natural, . . A 7) Descrever estados v diagrama de estados

Projeto - passos èProjeto de um subsistema A 1) Rever as dependências entre subsistemas v A 2) Rever as interfaces v A 3) Rever o conteúdo

Implementação - artefatos 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

Implementação - artefatos 1. MODELO DA IMPLEMENTAÇÃO É uma hierarquia de subsistemas de implementação contendo componentes e interfaces 2. COMPONENTE É UM PACOTE CONTENDO ELEMENTOS DO PROJETO Estereótipos: • <<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)

Implementação - artefatos 2. COMPONENTE - exemplos BOLETIM __________ <<executable>> Processa. Boletim. java realiza gera RESUMO __________ realiza <<table>> Resumo <<table>> Contrato

Implementação - artefatos 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

Implementação - artefatos 5. ARQUITETURA (visão da implementação) • Decomposição em subsistemas, compostos de interfaces e componentes • Componentes chave 6. PLANO DE INTEGRAÇÃO • Primeira versão executável • testes localizados de integração para facilitar a detecção de erros • versão final

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

Implementação - artífices

Implementação PASSOS èImplementação arquitetural èIntegrar sistemas èImplementar subsistema èImplementar uma classe èTestar componentes

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

Implementação - passos èImplementação arquitetural u identificar componentes significativos èIntegrar sistemas u determinar sequência de construção u integrar construções (compilar e linkar novos componentes)

Implementação - passos èImplementar subsistema u garantir conteúdo do subsistema èImplementar uma classe u implementar métodos u determinar operações/métodos auxiliares

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

Teste - artefatos 1. MODELO DE TESTE J Planejar os testes em cada iteração, tanto os os testes de integração quanto os testes de sistema J preparar casos de teste, criar procedimentos de teste e procedimentos executáveis J Realizar os testes e analisar os resultados 2. CASO DE TESTE

Fases X Etapas Fases

As quatro Fases èFase de Concepção u estabelece o business case (prioridade de negócio) Passos J Delimitar o escopo do sistema J Determinar arquitetura candidata (elementos novos, arriscados) J Identificar riscos críticos J Identificar potenciais usuários ou clientes do sistema

As quatro Fases èFase de Elaboração u determina uma arquitetura estável Passos J Determinar linha base da arquitetura cobrindo funcionalidades significantes J Identificar riscos críticos que podem derrubar planos, orçamentos, e prazos J Determinar níveis de qualidade (confiabilidade, tempos de resposta) J Definir use-cases que cobrem ca. de 80% da funcionalidade do sistema J Determinar limites de pessoal, custos, prazos.

As quatro Fases èFase de Construção u determina capacidades operacionais iniciais Passos J Estender o modelo de use-cases para toda a aplicação J Finalizar a análise, projeto, implementação e testes J Checar integridade da arquitetura (com possíveis alterações) J Monitorar ricos críticos

As quatro Fases èFase de transição u transforma versão beta em um sistema operacional Passos J Preparar atividades de transição J Avisar clientes sobre mudanças no ambiente (hardware, software, distribuição, . . ) J Preparar documentação final J Carregar o novo sistema J Corrigir possíveis defeitos detectados no beta-teste

Iterativo e incremental u 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 ITERAÇÃO planejamento requisitos análise consolidação projeto Implement. testes

Iterativo e incremental Planejando as FASES Planejando as ITERAÇÕES • 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 Gerenciar uma lista de riscos: Possíveis 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