processo unificado de desenvolvimento de software

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

Author: elliando-dias

Post on 19-May-2015

3.289 views

Category:

Technology


2 download

Embed Size (px)

TRANSCRIPT

  • 1. Processo Unificado de Desenvolvimento de Software G. Booch, Ivar Jacobson, James Rumbaugh Rational Software Corporation UNIVERSIDADE FEDERAL DA PARABA DEPARTAMENTO DE SISTEMAS E COMPUTAO Ulrich Schiel

2. PRECURSORES Object Modeling Technique - OMTdeJ. Rumbaugh,M. Blaha, W. Premerlani, F. Eddy e W. Lorensen (TMO - Tcnica de Modelagem de Objetos),1991 Objectology - A Use-Case Driven ApproachdeI. Jacobson, M. Ericsson e A. Jacobson,1992 Object Oriented Analysis and Design - OOA & OODdeG. Booch,1994 3. CARACTERSTICAS

  • baseado emcomponentesque realizaminterfaces
  • usaUML
  • aspectos: * dirigido porUse-Cases *centrado emarquitetura * iterativoeincremental
  • os 4 Ps: pessoal, projeto, produtoeprocesso

4. P4 = Pessoa, Projeto, Produto, Processo PESSOASfinanciam, escolhem, desenvolvem, gerenciam,testam, usam e so beneficiadas por produtos PROJETOS sofrem alteraes. Determinam os tipos depessoas que iro trabalhar no projeto e osartefatosque sero usados Sistema-i Sistema-i+1 ciclo fase iterao 5. P4 = Pessoa, Projeto, Produto, Processo PRODUTOcdigo fonte, cdigo de mquina, subsistemas, classes, diagramas: interao, de estados e outrosartefatos ARTEFATO qualquer tipo de informao criada por uma pessoa (diagramas UML, textos, modelos de interfaces) PROCESSOdefinequemfazo que, quandoecomo PU um processo. Considera fatoresorganizacionais ,dodomnio ,ciclo de vidaetcnicos 6. Modelos REQUISITOS -funcionais e no-funcionais descrevem o sistema a ser desenvolvido,sob um certoponto-de-vista,eseuambiente,ou seja, osatores ANLISEclasses e responsabilidades PROJETOclasses de projeto, subsistemas, interfaces IMPLEMENTAOcdigo fonte (DLLs, JavaBeams, ActiveX) TESTEcasos de teste (baseado nosuse-cases ) DISTRIBUIOns fsicos e os componentes em cada n 7. Dirigido aUse-Cases Umator uma pessoa ou outro sistema Cadause-case um requisito funcional do sistema ModeloUse-Case = use-cases= funcionalidade do sistema OsUse-Casesacompanham todo o processo de desenvolvimento: Especificao de Requisitos, Anlise, Projeto, Implementao e Testes Cadause-caserepresenta uma sequncia deaesque produzemumresultadode utilidade para umator 8. Dirigido aUse-Cases Porque USE-CASES??

  • Capturar os requisitos : oDiagrama Use-Case mostraquaisatoresusam quaisuse-cases

Use-Cases Arquitetura do sistema dirige influi

  • Dirigir o processo : para realizar osuse-casesso definidosclassificadores(classes, subsistemas, interfaces) e relacionamentos (colaboraes) entre estes
  • Elaborar a arquitetura, determinar iteraes, determinao dos manuais de usurio

9. Dirigido aUse-Cases Classe de fronteira Classe de controle Classe de entidades Modelo USE-CASE Modelo ANLISE ModeloPROJETO Classe ModeloIMPLEMENT relacionamento 10. Dirigido aUse-Cases

  • Dirigir o processo :

ANLISE : definir asCLASSES DE ANLISE para realizar umuse-case(classes limite, classes de controle e classes de entidades) PROJETO : ENTRADA: modelo de anlise, pacote de construo deinterfaces, SGBD, sistemas existentes. SAIDA:classificadores(classes, subsistemas, interfaces),relacionamentosecolaboraes IMPLEMENTAO :criao deprogramas executveisearquivos que realizam osuse-cases TESTE :casos de testeeprocedimentos de teste.Testar entradas, resultadose condies 11. Centradona arquitetura

  • DECISES SOBRE:
  • a organizao do sistema como um todo
  • os elementos estruturais, interfaces e seu comportamento
  • composio de elementos estruturais e comportamentais em subsistemas

A ARQUITETURA descreve aspartes essenciaisdo sistema,importantes para todos desenvolvedores Menos de 10% das classes so relevantes para a arquitetura Descrio de REQUISITOS ADICIONAIS: segurana, distribuio, concorrncia, plataformas, etc. 12. Centradona arquitetura Use-Cases Plataforma de software Disponibilidade de blocos reusveis Sistemas existentes Hardware existente Requisitos no-funcionais (performance, segurana) Arquitetura influem 13. Centrado na arquitetura PRODUTO Use-Case Arquitetura Sequncia para oarquiteto:

  • Criar uma viso preliminar da arquitetura
  • Analisar osuse-caseschave(5-10%) e especificar umsubsistema para cada um
  • Pela especificao dos subsistemas aparecem mais detalhes daarquitetura e novosuse-cases
  • Repetir o passo acima, at terminar o sistema

funo forma 14. 4 FASES CONCEPO CONSTRUO ELABORAO TRANSIO 15. Iterativo e incremental Projetos grandes so divididos emmini-projetos Cada mini-projeto umaiterao

  • Um grupo deuse-casesque estendem usabilidade

Fatores de risco maisimportantes MINI- PROJETO Cada iterao gera umincremento

  • PORQUE ITERATIVO E INCREMENTAL
  • atenuar riscos
  • obter arquitetura robusta
  • facilitar alteraes tticas ou contnuas
  • conseguir aprendizado mais cedo

16. Iterativo e incremental Fases 17. Iterativo e incremental Cadafasetermina com um MARCO (milestone): INICIO :o que o sistema far? Como poderia ser a arquitetura? Prazos e custos? UmCICLO uma sequncia das 4 fases.Um projeto pode necessitar de vrios ciclos.

  • identificar osriscos
  • fixar subconjunto chave -> arquitetura candidata
  • estimativas iniciais (custos, esforos, alocaes e qualidadedo produto)
  • iniciar caso gerencial ( business case )

18. Iterativo e incremental ELABORAO :use-casesespecificados e esqueleto da arquitetura definido CONSTRUO : software feito TRANSIO : beta-teste feito por poucos usurios. Treinamento, documentao

  • identificar e reduzirriscosde construo
  • especificar maioria dosuse-cases
  • fixar a arquitetura em propores executveis
  • preparar oplano de projeto(para a prxima fase)
  • estimar e justificar o oramento
  • finalizar obusiness case
  • iteraes garantindo viabilidade em forma executvel ->incrementos
  • eliminar problemas e erros no identificados previamente

19. OP ROCESSOU NIFICADO 20. EXEMPLO Desenvolver um sistema de controle de vendedores ambulantes de um empresa. A empresa dividiu cada cidade em que atua em regies. Cada regio controladapor um supervisor ao qual est subordinado um certo nmero de vendedores.A empresa possui diversos pontos distribudos na cidade. Todo dia os vendedorespassam pela empresa, de manh, e registram, em umboletim de controle, a hora da partida, o roteiro de visitas planejado e o nmero decontratos de vendas que levaram. Ao final da tarde, cada vendedor passa por umpontos, 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 produes do dia. Cada ponto da empresa, processa a esta hora, um resumo das atividadesregistradas e o remete para a central da empresa.No outro dia o supervisor analisa os boletins recebidos e passa-os, com algunscomentrios, ao controle geral de vendas da empresa. O supervisor, alm de controlar a produo dos vendedores, registra orecebimento de novos vendedores e a liberao deles para o departamento pessoalque, por sua vez, controla a contratao, alocao, relocao e demisso devendedores e supervisores. 21. Modelos Requisitos ARTEFATOS Anlise Projeto Implementao Testes ARTFICES PASSOS eATIVIDADES produz produzido-por composto-por 22. Obteno dos Requisitos ARTEFATOS

  • ModeloUse-Case
  • ator
  • Use-Case
  • descrio da arquitetura

23. Obteno dos Requisitos ARTFICES

  • Analista de sistemas
  • arquiteto
  • Especificador deUse-Case
  • projetista de interfaces

24. Obteno dos Requisitos PASSOS

  • listar potenciais requisitos
  • entender o contexto do sistema
  • capturar requisitos funcionais
  • capturar requisitos no-funcionais

25. Obteno dos Requisitos - Passos

  • listar potenciais requisitos

Desenvolver umalista de caractersticasobtidas de clientes, usurios, analistas e desenvolvedores

  • CARACTERSTICA:
  • nome
  • breve descrio ou definio
  • conjunto de valores
    • Estado (proposto, aprovado, incorporado, validado)
    • estimativa de custos
    • prioridade (crtica, importante ou secundria)
    • riscos (crtico, significante, ordinrio)

26. Obteno dos Requisitos - Passos

  • entender o contexto do sistema
  • criar ummodelo do domnio
    • objetos de negcio (pedidos, contas, contratos,..)
    • objetos do mundo real (veculos, mquinas, trajetos,..)
    • eventos bsicos (chegada de um pedido, partida de umtransporte, ..)
  • usar diagramas UML, em particular diagramas de classe

27. Obteno dos Requisitos - Passos

  • capturar requisitos funcionais

ARTFICE ARTEFATO Analista de Sistemas Especificador deUse-Cases Projetista de Interfaces Arquiteto

  • Modelouse-case
  • atores
  • glossrios

Prottipos de interfaces Use-cases Arquitetura responsvel 28. Obteno dos Requisitos - Passos

  • capturar requisitos funcionais
  • ATIVIDADES E SUBPASSOS
  • A1) encontrar os atores euse-cases
    • encontrar os atores
    • encontrar e descrever cadause-case
    • descrever o ModeloUse-Casecomo um todo
  • A2) PriorizarUse-Cases(viso arquitetural)

29. Obteno dos Requisitos - Passos

  • capturar requisitos funcionais
  • ATIVIDADES E SUBPASSOS
  • A3) Detalhar cadaUse-Case
    • estruturar a descrio douse-case (construir um diagrama de estados e analisar cada caminho)
    • formalizar a descrio douse-case (usar diagramas de estado, diagramas de atividade ou diagramasde interao)
    • descrever o ModeloUse-Casecomo um todo

30. Obteno dos Requisitos - Passos

  • capturar requisitos funcionais
  • ATIVIDADES E SUBPASSOS
  • A4) Prototipar as interfaces com o usurio
    • projeto lgico da interface do usurio
    • projeto fsico da interface do usurio e prottipo

31. Obteno dos Requisitos PROJETO LGICO : para cada ator, ver todosuse-casesnosquais est envolvido e especificar oselementos de interao (cones, listas, campos, figuras, etc.) N.B. a mesma interface (formulrio) pode aparecer em diversos use-casespara diversos atores!

  • QUESTES para determinar os elementos de interao :
  • quais informaes o ator fornece ao sistema?
  • quais informaes o ator necessita do sistema?
  • com quais elementos de interao o ator trabalha?
  • quais aes o ator pode acionar e quais decises tomar?
  • Quais classes de domnio ou entidades de negcio esto envolvidos com elementos de interao?

32. Obteno dos Requisitos PROJETO FSICO :

  • combinar elementos de interao para formar interfaces que atendam a atores
  • determinar elementos adicionais (folders, janelas, controles, etc.)
  • desenvolver um prottipo para cada interface

33. Obteno dos Requisitos

  • capturar requisitos funcionais
  • ATIVIDADES E SUBPASSOS
  • A5) Estruturar o modeloUse-Case
    • identificar funcionalidades comuns (generalizaes,)
    • identificar funcionalidades adicionais ou opcionais
    • identificar outros relacionamentos entreuse-cases (, inverso de )

34. Obteno dos Requisitos

  • capturar requisitos no-funcionais
  • ATIVIDADES
  • usabilidade
    • requisitos de interfaces metfora, frequncia de uso, ..
    • documentao
  • confiabilidade
    • tolerncia a falhas.

35. Obteno dos Requisitos

  • capturar requisitos no-funcionais
  • ATIVIDADES
  • performance
    • tempos de resposta
    • volumes de transaes
  • requisitos fsicos
    • equipamentos, material, espaos, configuraes de rede,
    • software

36. Anlise 37. Anlise Osrequisitos externosso transformados em ummodelo interno preciso e completo para desenvolver o projeto do sistema Deve ser preciso e inambguo Pode conter redundncias, inconsistncias, etc. Usado para o desenvolvedor entender o sistema Usado para o contrato com o cliente Descreve como realizar a funcionalidade Captura a funcionalidade do sistema Estruturado por classes Estruturado poruse-cases Viso interna do sistema Viso externa do sistemaLinguagem do desenvolvedor linguagem do usurio MODELO DA ANLISE MODELOUSE-CASE 38. Anlise - artefatos 2. CLASSE DE ANLISE Classe de fronteira Classe de controle Classe de entidades EXEMPLO Interface de registro processar resumo do dia Boletim de controle 1. MODELO DA ANLISE 39. Anlise - artefatos 3. REALIZAO DE UMUSE-CASE

  • Diagramas de classe
  • Diagramas de colaborao

Resultado do dia Processar resumo boletimde 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. comentrios 7. mostra resumo 10. resumo comentado RELOGIO 4. 8 horas 40. Anlise - artefatos 3. REALIZAO DE UMUSE-CASE(cont.)

  • requisitos especiais
  • fluxo de eventos

Descrio textual de requisitos no-funcionais Descrio textual do diagrama de colaborao 4. PACOTES DE ANLISE PACOTE DE SERVIOS Devem tercoesoefraco acoplamento

  • Candidatos a subsistemas do projeto

um conjunto de aes coerentes, indivisveis para uso em vriosuse-cases 5. DESCRIO DA ARQUITETURA 41. Anlise

  • arquiteto
  • Especificador deUse-Case
  • Especificador de componentes

ARTFICES

  • responsvel pela integridade global do modelo de anlise (corretude, consistncia e legibilidade),tanto pela sua funcionalidade quanto pela arquitetura
  • responsvel que a realizao de umuse-casecorresponde a sua especificao
  • responsvel pelas classe de anlise e pelos pacotes

42. Anlise PASSOS

  • Anlise arquitetural
  • Anlise de cadaUse-Case
  • Anlise de cada classe
  • Anlise de cada pacote

43. Anlise - passos

  • Anlise arquitetural

Anlisearquitetural MODELO USE-CASE REQUISITOSADICIONAIS MODELO DO DOMNIO DESCRIO ARQUITETURA (mod. Requisitos) ARQUITETO DESCRIO ARQUITETURA (mod. Anlise) CLASSEDE ANLISE (esboo) PACOTE ANLISE (esboo) 44. Anlise - passos

  • Anlise arquitetural
  • ATIVIDADES E SUBPASSOS
  • A1) Identificar pacotes de anlise
    • Encontrarpacotes coesos e fracamente acoplados
    • Identificar funcionalidades comuns entre pacotes (pacotes genricos)
    • Identificar pacotes de servio (servios opcionais, classes relacionadas funcionalmente)
    • Dependncias entre pacotes

45. Anlise - passos

  • Anlise arquitetural (cont.)

A2) Identificar classes de entidades bvias Obtidas a partir das classe do domnio

  • A3) Identificar requisitos especiais comuns
    • Persistncia
    • Distribuio e concorrncia
    • aspectos de segurana
    • tolerncia a falhas
    • gerncia de transaes

46. Anlise - passos

  • Anlise de cadaUse-Case
  • encontrar as classe de anlise para realizar ouse-case
  • distribuir o comportamento douse-caseentre as classes
  • identificar requisitos especiais

Anlise de umUse-Case MODELO USE-CASE REQUISITOSADICIONAIS MODELO DO DOMNIO DESCRIO ARQUITETURA (mod Anlise) ESPECIFICADOR DEUSE-CASES CLASSEDE ANLISE (esboo) REALIZAO DE UMUSE-CASE (diagramas de classes e de colaborao) 47. Anlise - passos

  • Anlise de cadaUse-Case
  • A1) Identificar classes de anlise
    • encontrar classes de entidades para armazenar as informaesdouse-case
    • para cada ator humano, determinar uma classe de fronteiracentral (representa a janela principal)
    • determinar as classe de fronteira que interagem com as classesde entidade
    • determinar, pelo menos, uma classe de controle que coordena ouse-case

CONSTRUIR UM DIAGRAMA DE CLASSES 48. Anlise - passos

  • Anlise de cadaUse-Case(cont.)
  • A2) Descrever interaes entre objetos
    • construir umdiagrama de colaborao
    • toda classe de anlise deve participar de algum diagrama decolaborao
    • dar maior nfase s conexes e condies do que sequncia
    • s conexes de mensagens podem corresponder associaes do diagrama de objetos ouno
    • considerar as relaes entreuse-casesno diagrama
  • A3) Determinar requisitos especiais

49. Anlise - passos Resultado do dia Processar resumo boletimde 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 . comentrios 8 . mostra resumo 11 . resumo comentado 5 . 8 horas RELGIO SUPERVISOR

  • Anlise de cadaUse-Case(cont.)

50. Anlise - passos

  • Anlise de cada classe
  • identificar as responsabilidades de cada classe, baseado em sua funona realizao deuse-cases
  • definir os atributos e relacionamentos
  • capturar requisitos especiais para cada classe

Anlisede uma classe REALIZAO DE UMUSE-CASE (diagramas de classes e de colaborao) ESPECIFICADOR DE COMPONENTES CLASSEDE ANLISE (completa) CLASSEDE ANLISE (esboo) 51. Anlise - passos

  • Anlise de cada classe
  • A3) Identificar associaes e agregaes
  • A2) Definir os atributos
    • tipos de atributos so conceituais
    • classes com muitos atributos podem ser divididas
    • atributos de classes de fronteira so campos em interfaces
    • classes de controle geralmente no tem atributos
  • A1) Identificar responsabilidades
    • Determinar os papis de cada classe nos diferentesuse-cases
  • A4) Identificar generalizaes
  • A5) Determinar requisitos especiais

52. Anlise - passos

  • Anlise de cada pacote
    • Rever as dependncias entre pacotes de acordo com associaes estticas ou dinmicas entre as classes, criadas nos passosanteriores
    • Garantir que cada pacote preenche sua funo
    • Rever as questes deacoplamento fracoecoeso

53. Projeto

  • adquirir uma compreenso de aspectos de requisitos no funcionais e restries sobrelinguagens de programao, sistemas operacionais, SGBDs, aspectos de distribuio , etc. .
  • Criar informaes suficientes para a implementao, descre- vendosubsistemas, interfaces e classes.
  • Estar apto a dividir a tarefa de implementaoem equipes
  • Determinar mais cedo as interfaces entre os subsistemas
  • Criar um modelo que possibilite uma implementao que preencha as estruturas definidas sem altera-las

OBJETIVOS 54. Projeto 55. Projeto - artefatos 1. MODELO DEPROJETO uma hierarquia desubsistemascontendo classe de projeto ,projetos deuse-caseseinterfaces 2. CLASSE DEPROJETO

  • na linguagem de programao da implementao
  • visibilidade dos atributos(ex. publico, protegido, privado)
  • generalizaesherana;
  • associaes e agregaesatributos
  • mtodos em pseudo-cdigo

56. Projeto - artefatos 3. REALIZAO DOUSE-CASE

  • Diagrama de classes
  • Diagrama de interaes (diagramas de sequncia)
  • Fluxo de eventos (textual)
  • Requisitos de implementao

57. Projeto - artefatos 7. MODELO DE DISTRIBUIO (Diagrama de ns e conexes) 5. INTERFACE ( separa funcionalidade de implementao) 6. ARQUITETURA (VISO DO PROJETO) (1. Subsistemas, interfaces e dependncias 2. Classes chave, classes ativas 3. Realizao deuse-casescentrais ao sistema 4. SUBSISTEMA DE PROJETO (pacotes de anlise, componentes, produtos de software,sistemas existentes) - SUBSISTEMAS DE SERVIO 8. ARQUITETURA (VISO DO MODELO DE DISTRIBUIO) 58. Projeto - artfices

  • Arquiteto
  • Especificador deuse-cases
  • Especificador de componentes

MODELO DO PROJETO ARQUITETURA MODELO DE DISTRIBUIO REALIZAO DEUSE CASE CLASSE DEPROJETO SUBSISTEMA INTERFACE 59. Projeto - passos Projeto de umuse-case Projeto deuma classe Projeto de um subsistema Projeto da arquitetura ARQUITETO ESPECIFICADOR DE COMPONENTES ESPECIFICADOR DEUSE-CASES 60. Projeto - passos

  • Projeto da arquitetura
  • A1) Identificar ns e configuraes de rede
    • determinar os ns envolvidos e suas caractersticas
    • determinar os tipos de conexes entre os ns
    • verificar necessidades de processamentos redundantes,backups , etc.

61. Projeto - passos

  • Projeto da arquitetura (cont.)
  • A2) Identificar subsistemas e suas interfaces
    • subsistemas da aplicao
    • identificarmiddleware( SO, SGBD, software de comunicao, pacotes GUI, distribuio, etc.)
    • definir dependncias entre os subsistemas
    • identificar as interfaces entre os subsistemas

Pacote (anlise) Subsistema novo Software existente No serve como subsistema integrado com sistemas existentes 62. Projeto - passos

  • Projeto da arquitetura (cont.)
  • A3) Identificar classes de projeto significativas
    • a partir das classes de anlise
    • classes ativas ( requisitos de concorrncia, performance, inicializao, distribuio, preveno de deadlocks)
  • A4) outros requisitos de projeto ( persistncia, transparncia de distribuio, segurana, recuperao de erros, gerncia de transaes)

63. Projeto - passos

  • Projeto de umuse-case
  • A1) Identificar classes de projeto participantes
    • estudar as classes de anlise
    • identificar classes que realizam os requisitos especiais da anlise
    • 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 operaes
  • requisitos de implementao douse-case

64. Projeto - passos

  • Projeto de umuse-case(cont.)
  • A2) Descrever a interao entre objetos
    • ouse-case acionado por uma mensagem de um ator a um objeto
    • traar um ou vriosdiagramas de sequncia
    • utilize nomes e textos (fluxo de eventos) para descrever as sequncias
    • considere as associaes entreuse-casesno diagrama de sequncia

65. Projeto - passos

  • Projeto de umuse-case(cont.)
  • A3) Identificar subsistemas e interfaces
    • identificar os subsistemas obtidos a partir de pacotes desteuse-case
    • verifique se h classes de projeto especiais e seus subsistemas
  • A4) Descrever a interao entre subsistemas
    • a partir doscaminhosno diagrama se sequncia determinar a interao
    • determinar qual interfaces utilizada por qual mensagem

66. 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 vrias classes de projeto (distribuio) ou serem encapsuladas em classes de entidades

ASPECTOS:

  • atributos
  • operaes e sua realizao
  • relacionamentos
  • estados
  • dependncias
  • interfaces
  • requisitos de implementao

67. Projeto - passos

  • Projeto de uma classe (cont.)
  • A2) Definir operaes
    • 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 anlise
    • os tipos dos atributos so determinados pela linguagem de programao
    • valores de atributos usados por vrios objetos devem ser transformados em objetos

68. Projeto - passos

  • Projeto de uma classe (cont.)
  • A4) Identificar associaes e agregaes
    • dependendo da linguagem, transform-los em relacionamentos
    • tentar transformar cardinalidades, papis, etc. em atributos ouem novas classes para realizar a associao
    • analise a navegabilidade pelas associaes

A5) Identificar generalizaes

  • A6) Descrever mtodos
    • realizao de operaes por pseudo-cdigo, diagramas de atividades, linguagem natural,..
  • A7) Descrever estados
    • diagrama de estados

69. Projeto - passos

  • Projeto de um subsistema
  • A1) Rever as dependncias entre subsistemas
  • A2) Rever as interfaces

A3) Rever o contedo 70. Implementao - artefatos 1. MODELO DA IMPLEMENTAO 2. COMPONENTE 3. SUBSISTEMA DE IMPLEMENTAO 4. INTERFACE 5. ARQUITETURA (viso da implementao) 6. PLANO DE INTEGRAO 71. Implementao - artefatos 1. MODELO DA IMPLEMENTAO uma hierarquia desubsistemas de implementao contendo componenteseinterfaces 2. COMPONENTE

  • (programa executvel)
  • (arquivo contendo cdigo fonte ou dados)
  • (biblioteca esttica ou dinmica)
  • (tabela do banco de dados)
    • (um documento)
    UM PACOTE CONTENDO ELEMENTOS DO PROJETO Esteretipos: 72. Implementao - artefatos 2. COMPONENTE - exemplos ProcessaBoletim.java Resumo BOLETIM __________ __________ RESUMO __________ __________ Contrato realiza realiza gera gera 73. Implementao - artefatos 3. SUBSISTEMAS DE IMPLEMENTAO
    • umpackageem Java
    • umprojectem Visual Basic
    • umdiretriode C++
    CORRESPONDNCIA 1-1 COM SUBSISTEMAS DE PROJETO 4. INTERFACES Implementam as interfaces do projeto 74. Implementao - artefatos 5. ARQUITETURA (viso da implementao) 6. PLANO DE INTEGRAO
    • Decomposio em subsistemas, compostos de interfaces e componentes
    • Componentes chave
    • Primeira verso executvel
    • testes localizados de integrao para facilitar a deteco deerros
    • verso final
    75. Implementao - artfices
    • Arquiteto
    • Integrador do sistema
    • Engenheiro de componentes
    MODELO DA IMPLEMENTAO DESCRIO DA ARQUITETURA MODELO DE DISTRIBUIO PLANO DE INTEGRAO COMPONENTE SUBSISTEMA DEIMPLEMENTAO INTERFACE 76. Implementao - artfices 77. Implementao PASSOS
    • Implementao arquitetural
    • Integrar sistemas
    • Implementar subsistema
    • Testar componentes
    • Implementar uma classe
    78. Projeto - passos Integrar sistemas Implementar uma classe Implementar um subsistema Implementao arquitetural ARQUITETO ENGENHEIRO DECOMPONENTES INTEGRADORDE SISTEMAS Teste de unidade 79. Implementao - passos
    • Implementao arquitetural
    • identificar componentes significativos
    • Integrar sistemas
    • determinar sequncia de construo
    • integrar construes (compilar e linkar novos componentes)
    80. Implementao - passos
    • Implementar subsistema
    • garantir contedo do subsistema
    • Implementar uma classe
    • implementar mtodos
    • determinar operaes/mtodos auxiliares
    81. Teste OBJETIVOS
    • Planejar os testes em cada iterao, tanto ostestes de integraoquanto ostestes de sistema
    • preparar casos de teste, criar procedimentos de teste e procedimentos executveis
    • Realizar os testes e analisar os resultados
    82. Teste - artefatos 1. MODELO DE TESTE
    • Planejar os testes em cada iterao, tanto osostestes de integraoquanto ostestes de sistema
    • preparar casos de teste, criar procedimentos de teste e procedimentos executveis
    • Realizar os testes e analisar os resultados
    2. CASO DE TESTE 83. Fases X EtapasFases 84. As quatro Fases
    • Fase de Concepo
    • estabelece obusiness case(prioridade de negcio)
    • Delimitar oescopo do sistema
    • Determinararquiteturacandidata (elementos novos, arriscados)
    • Identificarriscos crticos
    • Identificar potenciaisusuriosouclientesdo sistema
    Passos 85. As quatro Fases
    • Fase de Elaborao
    • determina uma arquitetura estvel
    • Determinar linha base daarquiteturacobrindo funcionalidadessignificantes
    • Identificarriscos crticosque podem derrubar planos, oramentos, e prazos
    • Determinar nveis dequalidade(confiabilidade, tempos de resposta)
    • Definir use-cases que cobrem ca. de 80% da funcionalidade dosistema
    • Determinar limites de pessoal, custos, prazos.
    Passos 86. As quatro Fases
    • Fase de Construo
    • determina capacidades operacionais iniciais
    • Estender o modelo deuse-cases para toda a aplicao
    • Finalizar aanlise, projeto, implementaoetestes
    • Checarintegridade da arquitetura(com possveis alteraes)
    • Monitorarricos crticos
    Passos 87. As quatro Fases
    • Fase de transio
    • transforma versobetaem um sistema operacional
    • Preparar atividades de transio
    • Avisar clientes sobre mudanas no ambiente (hardware, software, distribuio, ..)
    • Preparardocumentaofinal
    • Carregar o novo sistema
    • Corrigir possveisdefeitosdetectados no beta-teste
    Passos 88. Iterativo e incremental
    • Uma ITERAO genrica composta pelas 5 etapas: Requisitos, Anlise, Projeto, Implementao e Testes
    Aps cada iterao ou cada fase:
    • planejar a prxima iterao luz da experincia anterior
    • modificar o processo, adaptarferramentas, treinamento, etc.
    89. Iterativo e incremental requisitos anlise projeto Implement. testes planejamento consolidao ITERAO 90. Iterativo e incremental Planejando as ITERAES Planejando as FASES
    • tempos por fase
    • milestones
    • iteraes por fase
    • plano do projeto
    • cronograma
    • contedo: -quais use-cases sero realizados -iteraes anteriores e posteriores
    91. Riscos Possveis riscos: Gerenciar uma lista de riscos:
    • descrio
    • prioridade(crtico, signifcante, rotineiro)
    • impacto
    • responsabilidades
    • contingncia(o que fazer?)
    • relacionados a um produto
    • no conseguir a arquitetura
    • no realizar os requisitos