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