processo unificado de desenvolvimento de software g. booch, ivar jacobson, james rumbaugh rational...
Post on 07-Apr-2016
216 Views
Preview:
TRANSCRIPT
Processo Unificado de Processo Unificado de Desenvolvimento de Desenvolvimento de
SoftwareSoftwareG. Booch, Ivar Jacobson, James Rumbaugh
Rational Software Corporation
UNIVERSIDADE FEDERAL DA PARAÍBADEPARTAMENTO 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
P4 = Pessoa, Projeto, Produto, Processo
PESSOASPESSOAS financiam, escolhem, desenvolvem, gerenciam, testam, usam e são beneficiadas por produtos
PROJETOSPROJETOS sofrem alterações. Determinam os tipos de pessoas que irão trabalhar no projeto e os artefatos que serão usados
Sistema-i Sistema-i+1
ciclofase
iteração
P4 = Pessoa, Projeto, Produto, Processo
PRODUTOPRODUTO 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)
PROCESSOPROCESSO define quem faz o que, quando e como
PUPU é um processo. Considera fatores organizacionais, do domínio, ciclo de vida e técnicos
Modelos
REQUISITOSREQUISITOS - funcionais e não-funcionais
descrevem o sistema a ser desenvolvido, sob um certo ponto-de-vista, e
seu ambiente, ou seja, os atores
ANÁLISEANÁLISE classes e responsabilidades
PROJETOPROJETO classes de projeto, subsistemas, interfaces
IMPLEMENTAÇÃOIMPLEMENTAÇÃO código fonte (DLLs, JavaBeams, ActiveX)
TESTETESTE casos de teste (baseado nos use-cases)
DISTRIBUIÇÃODISTRIBUIÇÃO nós físicos e os componentes em cada nó
Dirigido a Use-Cases
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
Cada use-case representa uma sequência de ações que produzem um resultado de utilidade para um ator
Dirigido a Use-Cases
Porque USE-CASES??
Capturar os requisitos: o Diagrama Use-Case mostra quais atores usam quais use-cases
Use-Cases Arquitetura do sistemadirige
influi
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
Dirigido a Use-Cases
Classe defronteira
Classe decontrole
Classe deentidades
ModeloUSE-CASE
ModeloANÁLISE
Modelo PROJETO
Classe
Modelo IMPLEMENT
<executável>
<arquivo>
<arquivo>
relacionamento
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 arquivosque 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
Plataforma de software
Disponibilidade de blocosreusáveis
Sistemas existentes
Hardware existente
Requisitos não-funcionais(performance, segurança)
Arquitetura
influem
Centrado na arquitetura
PRODUTOUse-Case
Arquitetura
Sequência para o arquiteto:Criar uma visão preliminar da arquiteturaAnalisar os use-cases chave (5-10%) e especificar um subsistemapara cada um
Pela especificação dos subsistemas aparecem mais detalhes da arquitetura e novos use-casesRepetir o passo acima, até terminar o sistema
função
forma
4 FASES
CONCEPÇÃO
CONSTRUÇÃO
ELABORAÇÃO
TRANSIÇÃO
Iterativo e incrementalProjetos grandes são divididos em mini-projetos
Cada mini-projeto é uma iteração
•Um grupo de use-cases que estendem usabilidade
Fatores de risco mais importantes
MINI-PROJETO
Cada iteração gera um incrementoPORQUE ITERATIVO E INCREMENTAL• atenuar riscos• obter arquitetura robusta• facilitar alterações táticas ou contínuas• conseguir aprendizado mais cedo
Iterativo e incremental
Concepção Elaboração Construção Transição
Requisitos
Análise
Projeto
ImplementaçãoTestes
Iter.#1
Iter.#2
_ _ _ _ _ Iter.#n-1
Iter.#n
Fases
Iterativo e incremental
Cada fase termina com um MARCO (milestone):
INICIOINICIO: o que o sistema fará? Como poderia ser a arquitetura?Prazos e custos?
Um CICLO é uma sequência das 4 fases. Um projeto pode necessitar de vários ciclos.
• 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ÇÃOELABORAÇÃO: use-cases especificados e esqueleto da arquitetura definido
CONSTRUÇÃOCONSTRUÇÃO: software feito
TRANSIÇÃOTRANSIÇÃO: beta-teste feito por poucos usuários. Treinamento, documentação
• 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
• iterações garantindo viabilidade em forma executável -> incrementos
• eliminar problemas e erros não identificados previamente
O O PPROCESSO ROCESSO UUNIFICADONIFICADO
EXEMPLODesenvolver 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çõesdo 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 ARTEFATOS
Análise
Projeto
Implementação
Testes
ARTÍFICES
PASSOS e ATIVIDADES
produz
produzido-por
composto-por
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 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
Obtenção dos Requisitos - Passos
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)
Obtenção dos Requisitos - Passos
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
Obtenção dos Requisitos - Passos
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
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
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>>)
Obtenção dos Requisitos
capturar requisitos não-funcionais
ATIVIDADES usabilidade
requisitos de interfaces metáfora, frequência de uso, .. documentação
confiabilidade tolerância a falhas.
Obtenção dos Requisitos
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
Análise
Análise
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
Os requisitos externos são transformados em um modelo interno preciso e completo para desenvolver o projeto do sistema
Análise - artefatos
2. CLASSE DE ANÁLISE
Classe defronteira
Classe decontrole
Classe deentidades
EXEMPLO
Interface deregistro
processarresumo do dia
Boletim decontrole
1. MODELO DA ANÁLISE
Análise - artefatos
3. REALIZAÇÃO DE UM USE-CASE
Diagramas de classeDiagramas de colaboração
Resultadodo dia
Processarresumo
boletim de controle
VENDEDOR
partida
Resumo do dia
SUPERVISORmostraresumos
1.registra partida
3. registra retorno2. abre boletim
3. completa boletim
5. dados boletim6. Registra resumo
8. analisa resumo
9. comentários
7. mostra resumo
10. resumocomentado
RELOGIO
4. 8 horas
Análise - artefatos
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 usoem vários use-cases
5. DESCRIÇÃO DA ARQUITETURA
Análise
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
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
Análise arquitetural
MODELOUSE-CASE
REQUISITOS ADICIONAIS
MODELODO DOMÍNIO
DESCRIÇÃOARQUITETURA(mod. Requisitos)
ARQUITETO
DESCRIÇÃOARQUITETURA
(mod. Análise)
CLASSE DE ANÁLISE
(esboço)
PACOTEANÁLISE
(esboço)
Análise - passos 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 - passos 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ênciaaspectos de segurança tolerância a falhas 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
Análise de um Use-Case
MODELOUSE-CASE
REQUISITOS ADICIONAIS
MODELODO DOMÍNIO
DESCRIÇÃOARQUITETURA
(mod Análise)
ESPECIFICADORDE USE-CASES
CLASSE DE ANÁLISE
(esboço)
REALIZAÇÃODE UM USE-CASE
(diagramas de classese de colaboração)
Análise - passos 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 - passos 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
Resultadodo dia
Processarresumo
boletim de controleVENDEDOR
partida
Resumo do dia
mostraresumos
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. resumocomentado
5. 8 horas
Análise - passos
RELÓGIO
SUPERVISOR
Análise de cada Use-Case (cont.)
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
Análise de uma classeREALIZAÇÃO
DE UM USE-CASE(diagramas de classes
e de colaboração)
ESPECIFICADORDE COMPONENTES
CLASSE DE ANÁLISE
(completa)
CLASSE DE ANÁLISE
(esboço)
Análise - passos 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 interfacesclasses 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 - passos
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
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, 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
Projeto
MODELO DE ANÁLISE MODELO DE PROJETOconceitual físicoGenérico (c.r. projeto) específico
3 tipos de classes Depende da implementação
Menos formal Mais formalMais rápido (1/5 do projeto Mais demorado (5 x análise)Poucos níveis Muitos níveisMenos dinamica Mais dinâmica, foco na
sequenciaNão se mantém no ciclo Se manté em todo ciclo
Projeto - artefatos1. 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
Diagrama de classes
Diagrama de interações (diagramas de sequência)
Fluxo de eventos (textual)
Requisitos de implementação
Projeto - artefatos
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)
Projeto - artífices
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 - passos
Projeto deum use-case
Projeto de uma classe
Projeto deum subsistema
Projeto daarquitetura
ARQUITETOESPECIFICADORDE COMPONENTES
ESPECIFICADORDE USE-CASES
Projeto - passos 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 - passos 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 novoSoftware existenteNão serve como subsistema
É integrado com sistemas existentes
Projeto - passos 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 - passos 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 - passos 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 - passos 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 - passos 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 - passos 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 - passos 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 - passos Projeto de um subsistema
A1) Rever as dependências entre subsistemas
A2) Rever as interfaces
A3) Rever o conteúdo
Implementação - artefatos1. 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 - artefatos1. 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:
Implementação - artefatos2. COMPONENTE - exemplos
<<executable>>ProcessaBoletim.java
<<table>>Resumo
BOLETIM____________________
RESUMO____________________ <<table>>
Contrato
realiza
realiza
geragera
Implementação - artefatos3. 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)
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
Implementação - artífices
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
Implementação - artífices
Implementação
PASSOS
Implementação arquitetural
Integrar sistemas
Implementar subsistema
Testar componentes
Implementar uma classe
Projeto - passos
Integrarsistemas
Implementaruma classe
Implementarum subsistemaImplementação
arquitetural
ARQUITETOENGENHEIRO DE COMPONENTES
INTEGRADOR DE SISTEMAS
Teste deunidade
Implementação - passos
Implementação arquitetural
identificar componentes significativos
Integrar sistemas
determinar sequência de construção integrar construções (compilar e linkar novos componentes)
Implementação - passos
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
Concepção Elaboração Construção Transição
Requisitos
Análise
Projeto
ImplementaçãoTestes
Iter.#1
Iter.#2
_ _ _ _ _ Iter.#n-1
Iter.#n
Fases
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 asITERAÇÕ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 umalista 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
top related