Prof. Toacy C. de Oliveira – PESC/COPPE/URFRJ 1 PESC/COPPE/UFRJ - Toacy C. de Oliveira.

Apresentação em tema: "Prof. Toacy C. de Oliveira – PESC/COPPE/URFRJ 1 PESC/COPPE/UFRJ - Toacy C. de Oliveira."— Transcrição da apresentação:

1

2 Prof. Toacy C. de Oliveira – toacy@cos.ufrj.br PESC/COPPE/URFRJ 1 PESC/COPPE/UFRJ - Toacy C. de Oliveira

3  Professor Toacy Cavalcante de Oliveira, DSc. toacy@cos.ufrj.br www.cos.ufrj.br/~toacy Área de Interesse  Engenharia de Software,  Reutilização de Software  Processo de Software 2 PESC/COPPE/UFRJ - Toacy C. de Oliveira

4 Agenda  Engenharia de Software Conceitos Básicos Processo de Software  Modelagem Conceitos Básicos UML Exemplos 3 PESC/COPPE/UFRJ - Toacy C. de Oliveira

5 Objetivos do Curso  Objetivo Desenvolver uma visão conceitual sobre Engenharia de Software; Compreender as atividades do ciclo de vida de um software; Aplicar técnicas de modelagem para as atividades do ciclo de vida de um software; Dentro de uma metodologia de desenvolvimento de software, relacionar as principais técnicas de modelagem às atividades do ciclo de vida de um software; Compreender as novas tendências em Engenharia de Software 4 PESC/COPPE/UFRJ - Toacy C. de Oliveira

6 Pré requisitos  Linguagem de Programação  Programação estruturada  Programação Orientada a Objetos  Banco de Dados Relacionais 5 PESC/COPPE/UFRJ - Toacy C. de Oliveira

7 Método  Altamente interativo!!!!  Por favor perguntem!!!!  Tratamos com conceitos extremamente abstratos e portanto teremos um pouco de “hands-on”. 6 PESC/COPPE/UFRJ - Toacy C. de Oliveira

8 Bibliografia e Avaliação  Bibliografia SOMMERVILLE, Ian. Engenharia de software. São Paulo: Prentice Hall Brasil, 2003. 606 p. LARMAN, Craig. Utilizando UML e padrões: uma introdução à análise e projeto orientados a objetos. São Paulo: Bookman, 2003. 608 p.  Avaliação Trabalho Prático 7 PESC/COPPE/UFRJ - Toacy C. de Oliveira

9 Introdução 8

10 Motivação "The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task." -- Tom Clancy, The Sum of All Fears [ http://www.standishgroup.com/sample_research/chaos_1994_1.php ] 9 PESC/COPPE/UFRJ - Toacy C. de Oliveira

11 Dados interessantes  Standish Group Report 1995  Objeto de Estudo : 3682 projetos em 365 companhias.  Em 1995....  US$ 250 bilhões de gastos com IT.  31,1 % dos projetos são cancelados antes de começar a um custo de US$ 81 bilhões.  52,7 % custam 189% a mais que o previsto a um custo de US$ 59 bilhões. Fonte => http://www.projectsmart.co.uk/docs/chaos_report.pdf 10 PESC/COPPE/UFRJ - Toacy C. de Oliveira

12 Problemas Compreensão incompleta ou imprecisa das necessidades do usuário Inabilidade de lidar com requisitos que evoluem Módulos incompatíveis Dificuldades de estender ou manter software Descoberta de defeitos graves no projeto em etapas avançadas de desenvolvimento ou mesmo em época de implantação ou uso Desempenho inaceitável do software Falta de coordenação na equipe 11 PESC/COPPE/UFRJ - Toacy C. de Oliveira

13 Por que tanto problema?  Mundo Real Informal Impreciso Volátil  Mundo Computacional  Formal  Preciso  Estável Construção de Software O Nosso Ambiente de Trabalho  12 PESC/COPPE/UFRJ - Toacy C. de Oliveira

14 Engenharia de Software – A Solução!  O que é Engenharia de Software ? “A utilização de uma abordagem sistemática, disciplinada e mensurável, para o desenvolvimento, operação e manutenção de software, ou seja, é a utilização de engenharia para software” [IEEE Standard 610.12] IEEE => Institute of Electrical and Electronics Engineers. Associação que dita padrões para a indústria de computadores e eletrônicos. 13 PESC/COPPE/UFRJ - Toacy C. de Oliveira

15 Programação versus Eng. De Software 14 PESC/COPPE/UFRJ - Toacy C. de Oliveira

16 Programação  Ad-hoc  Sem planejamento  Sistemas pequenos Pouco tempo Baixo custo  Poucas pessoas envolvidas (tipicamente 1 líder decide tudo)  Não se preocupa com padronização.... ...tampouco documentação  Pouco impacto em seu entorno. 15 PESC/COPPE/UFRJ - Toacy C. de Oliveira

17 Eng. De Software  Planejamento meticuloso  Sistemas grandes Alto custo Muito tempo  Desenvolvido por um time Pode ser composto por profissionais com vários perfis. Decisão é colegiada.  Tem que levar em consideração a padronização existente ...e tem que ser muito documentado.  Muito impacto em seu entorno. 16 PESC/COPPE/UFRJ - Toacy C. de Oliveira

18 Eng. de Software  É muito maior (mais abrangente) que programação. Entretanto, como o produto final contém um software, sua programação deve seguir critérios que estabeleçam boas práticas. Coesão  Deve ser a mais alta possível. Acoplamento  Deve ver o mais baixo possível Flexibilidade  Tolerante a modificações Modularidade  Permite alterar apenas uma parte do sistema. 17 PESC/COPPE/UFRJ - Toacy C. de Oliveira

19 Atributos de Qualidade  Manutenibilidade – nenhum produto de software consegue permanecer inalterado por muito tempo. A estrutura de um software influencia diretamente a sua capacidade de manutenção.  Robustez – confiabilidade e segurança. Qualquer falha não pode causar danos físicos ou econômicos.  Eficiência – uso responsável dos recursos de sistema (memória, processamento, disco, etc) Tempo de resposta do sistema é uma medida de eficiência  Usabilidade – os usuários do sistema devem ter condições de operá-lo com mínimo esforço  etc 18 PESC/COPPE/UFRJ - Toacy C. de Oliveira

20 Eng. De Software  Deve estar apoiada em um processo que : Especifique os documentos a serem produzidos. Indique o que fazer, quando fazer e se possível, como fazer. Especifique o ciclo de vida de um sistema.  Da concepção à entrega e manutenção. 19 PESC/COPPE/UFRJ - Toacy C. de Oliveira

21 Processo de Desenvolvimento Especificaç ão Desenvolvime nto ValidaçãoEntrega Construção de Sistemas Informaçõ es Pessoas Mundo Real Mundo Computacio nal 20 PESC/COPPE/UFRJ - Toacy C. de Oliveira

22 Especificação / Desenvolvimento  Especificação  Captura informações do mundo real, relevantes para o sistema a ser desenvolvido.  Organiza e representa esta informação utilizando uma notação mais próxima do mundo computacional.  Desenvolvimento  Utiliza as informações obtidas na fase de especificação para a implementação do código a ser executado por uma plataforma computacional. 21 PESC/COPPE/UFRJ - Toacy C. de Oliveira

23 Validação / Entrega  Validação  Verifica se as informações e produtos (artefatos de software) criados durante o processo são “coerentes” estão de acordo com o que o cliente quer, estão de acordo com boas práticas de desenvolvimento  Entrega  Prepara o produto de software para executar no ambiente do cliente Migração de dados, manuais, treinamento, acompanhamento.... 22 PESC/COPPE/UFRJ - Toacy C. de Oliveira

24 Modelagem 23 PESC/COPPE/UFRJ - Toacy C. de Oliveira

25 Sistema de Computação Processos de Negócios Pedido Item envio “A Modelagem captura as partes essenciais do sistema.” Dr. James Rumbaugh Modelagem Visual significa modelar com a utilização de notações padrão. O Que é Modelagem Visual? 24

26 Análise de Caso de Uso é uma técnica utilizada para capturar processos de negócios do ponto de vista do usuário Modelagem Visual Captura os Processos de Negócios 25 PESC/COPPE/UFRJ - Toacy C. de Oliveira

27 A Modelagem Visual é uma Ferramenta de Comunicação Use a Modelagem Visual para capturar objetos e lógica de negócios Use a Modelagem Visual para analisar e projetar sua aplicação 26 PESC/COPPE/UFRJ - Toacy C. de Oliveira

28 A Modelagem Visual Controla a Complexidade 27 PESC/COPPE/UFRJ - Toacy C. de Oliveira

29 Interface de Usuário (Visual Basic, Java) Lógica de Negócios (C++, Java) Servidor de Banco de Dados (C++ & SQL) Modele seu sistema independentemente da linguagem de implementação A Modelagem Visual Define A Arquitetura de Software 28

30 PESC/COPPE/UFRJ - Toacy C. de Oliveira Múltiplos Sistemas A Modelagem Visual Promove Reutilização Componentes Reutilizáveis 29

31 Vantagens  Padronização impulso no desenvolvimento e adoção de ferramentas para desenvolvimento OO de software intercambialidade, interoperabilidade  Bom compromisso entre conceituação e flexibilidade: ampla variedade notacional facilidade de extensão/personalização facilidade de evolução (conceitual, tecnológica) 30 PESC/COPPE/UFRJ - Toacy C. de Oliveira

32 Unified Modeling Language UML 31 PESC/COPPE/UFRJ - Toacy C. de Oliveira

33 Contexto  Mercado de modelagem fragmentado  Falta de padronização  Resistência da indústria e usuários em investir em OO Alguns projetos bem sucedidos  Ericson, HP, Telecoms.... 32 PESC/COPPE/UFRJ - Toacy C. de Oliveira

34 Histórico  1989-1994: 50+ métodos OO  Métodos em evidência OOSE (Object-Oriented Software Engineering) Ivar Jacobson : Suporte a captura de requisitos através de UseCases Grady Booch: Permite a especificação de classes, objetos e interações. OMT (Object Modeling Technique) Jim Rumbaugh: Focado na análise  1994: Rumbaugh se uniu ao Booch na Rational  1995: Jacobson se uniu à Rational  1996: UML version 0.9 33 PESC/COPPE/UFRJ - Toacy C. de Oliveira

35 Histórico 1996: OMG Request For Proposal (RFP)  Consórcio : UML 1.0 (Jan. 1997) DEC, HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI, Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys  Consórcio : UML 1.1 (Set. 1997) + IBM & ObjecTime; Platinum Technology; Ptech; Taskon & Reich Technologies; and Softeam  revisões UML 1.2 (Junho/1998) UML 1.3 (Final de 1998) UML 2.0 (2007). 34 PESC/COPPE/UFRJ - Toacy C. de Oliveira

36 Histórico 1994 Método de BoochOMT (Rumbaugh)OOSE (Jacobson) Outros métodos Unified Method 0.8 OOPSLA - 1995 UML 1.0 Primeira submissão à OMG – Jan/1997 Consórcio ”Parceiros UML” Outras empresas se juntam ao Consórcio - 1997 UML 1.1 Setembro/2001 = UML 1.3 UML 1.5 UML 1.3 Junho/1999 (UML User Guide) Junho/1996 UML 0.9 UML 2.1.1 Março/2003 = UML 1.5 Early/2007 = UML 2.1.1 35 PESC/COPPE/UFRJ - Toacy C. de Oliveira

37 Meyer Before and after conditions Harel Statecharts Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Embley Singleton classes and high-level view Wirfs-Brock Responsibilities Odell Classification Shlaer - Mellor Object lifecycles Rumbaugh OMT Booch Booch method Jacobson OOSE Contribuições para a UML 36 PESC/COPPE/UFRJ - Toacy C. de Oliveira

38 Parceiros UML  Rational Software Corporation  Hewlett-Packard  I-Logix  IBM  ICON Computing  Intellicorp  MCI Systemhouse  Microsoft  ObjecTime  Oracle  Platinum Technology  Taskon  Texas Instruments/Sterling Software  Unisys 37 PESC/COPPE/UFRJ - Toacy C. de Oliveira

39 Visão Geral da UML  A UML é uma linguagem destinada a: visualizar especificar construir documentar os artefatos de um sistema complexo de software. Artefatos: diagramas e documentos. 38 PESC/COPPE/UFRJ - Toacy C. de Oliveira

40 Objetivos  Descrever modelos de sistema - do mundo real e de software - baseado em conceitos de objetos. Fornecer uma linguagem de modelagem OO visual fácil, pronta para uso, permitindo amplas facilidades de modelagem Fornecer mecanismos de extensibilidade e especialização de conceitos de base Independência de processos e linguagens de programação  abranger todo o ciclo de vida  diferentes tecnologias de implementação Integrar melhores práticas em desenvolvimento OO de sistemas 39 PESC/COPPE/UFRJ - Toacy C. de Oliveira

41 Termos e Conceitos  Sistema: coleção de subsistemas organizados para a realização de um objetivo e descritos por um conjunto de modelos.  Subsistema: representa uma partição dos elementos de um sistema maior em partes independentes.  Modelo: são abstrações semanticamente fechadas de um sistema, representando uma simplificação consistente e completa da realidade.  Visão: abrange um subconjunto de itens que pertencem a um modelo, cujo foco esta voltado para um único aspecto do sistema. 40 PESC/COPPE/UFRJ - Toacy C. de Oliveira

42 OOOpssss. Abstração!!  Sim.... Modelos em Engenharia de Software são abstrações que escondem (as vezes muitos) detalhes da infra-estrutura de execução. ....isto é bom...e ruim..simultaneamente!! PESC/COPPE/UFRJ - Toacy C. de Oliveira 41

43 Notação definida pelos vários tipos de diagramas. Um diagrama é uma apresentação gráfica de uma coleção de elementos do modelo, conectado por arcos (relacionamentos) e nós (outros elementos do modelo). Modelagem com a UML 42 PESC/COPPE/UFRJ - Toacy C. de Oliveira

44 Diagramas (UML 1.4)  Estruturais – Definem os elementos do sistema e seus relacionamentos Classes Objetos Implantação Componentes  Comportamentais – Definem a funcionalidade do sistema, ou seja a interação entre seus elementos Caso de Uso Estado Sequência Colaboração Atividade 43 PESC/COPPE/UFRJ - Toacy C. de Oliveira

45 Diagramas Estruturais  Diagrama de Classes mostra um conjunto de classes, interfaces, e seus relacionamentos visões: projeto e processo  Diagrama de Objetos mostra um conjunto de objetos e seus relacionamentos visões: projeto e processo 44 PESC/COPPE/UFRJ - Toacy C. de Oliveira

46 Diagrama de Classe 45 PESC/COPPE/UFRJ - Toacy C. de Oliveira

47 Diagramas Estruturais  Diagrama de Implantação mostra a modelagem dos aspectos físicos de um sistema (configuração em tempo de execução) visão de implantação  Diagrama de Componentes mostra um conjunto de componentes e seus relacionamentos visão de implementação 46 PESC/COPPE/UFRJ - Toacy C. de Oliveira

48 Diagrama de Componente 47 PESC/COPPE/UFRJ - Toacy C. de Oliveira

49 Diagrama de Implantação 48 PESC/COPPE/UFRJ - Toacy C. de Oliveira

50 Diagramas Comportamentais  Diagrama de Casos de Uso  mostra um conjunto de atores e casos de uso  organiza e modela o comportamento do sistema  visão de caso de uso  Diagrama de Sequência  diagrama de interação que enfatiza o ordenamento das mensagens trocadas entre os objetos  visões: projeto e processo  Diagrama de Colaboração  diagrama de interação que enfatiza a organização estrutural dos objetos que trocam mensagens  visões: projeto e processo 49 PESC/COPPE/UFRJ - Toacy C. de Oliveira

51 Diagrama de Caso de Uso 50 PESC/COPPE/UFRJ - Toacy C. de Oliveira

52 Diagrama de Sequência 51 PESC/COPPE/UFRJ - Toacy C. de Oliveira

53 Diagrama de Colaboração 52 PESC/COPPE/UFRJ - Toacy C. de Oliveira

54 Diagramas Comportamentais  Diagrama de Atividade enfatiza o fluxo de uma atividade a outra no sistema visões: caso de uso e projeto  Diagrama de Estados enfatizam o comportamento de um objeto de acordo com um conjunto de eventos particularmente útil na construção de sistemas reativos visões: caso de uso e projeto 53 PESC/COPPE/UFRJ - Toacy C. de Oliveira

55 Diagrama de Atividades 54 PESC/COPPE/UFRJ - Toacy C. de Oliveira

56 Diagrama de Estados 55 PESC/COPPE/UFRJ - Toacy C. de Oliveira

57 Modelando com UML  Representar as relações do sistema com o mundo real e suas maiores funções usando Casos de Uso e Atores.  Ilustrar realizações de Casos de Uso com Diagramas de Interação e Diagramas de Atividade.  Representar a estrutura estática de um sistema usando Diagramas de Classes.  Modelar o comportamento de objetos com Diagramas de Estado.  Revelar a arquitetura de implementação física com Diagramas de Componentes e Implantação. 56 PESC/COPPE/UFRJ - Toacy C. de Oliveira

58 UML Conceitos Adicionais 57 PESC/COPPE/UFRJ - Toacy C. de Oliveira

59 Adornos  Elementos gráficos ou textuais que são adicionados à notação básica de elementos UML: usados para visualizar detalhes a respeito da especificação de um elemento adornos são adicionadas através da colocação de texto ou símbolo gráfico perto do elemento a ser detalhado exemplos:  papéis e cardinalidades de uma associação  compartimentos de uma classe (nomeados ou anônimos)  notas  etc 58 PESC/COPPE/UFRJ - Toacy C. de Oliveira

60  Nota: símbolo gráfico para representação de restrições ou de comentários anexados a um elemento ou a uma coleção de elementos. usos freqüentes: requisitos, observações, explicações, comentários, código para operações,... Notas 59 PESC/COPPE/UFRJ - Toacy C. de Oliveira

61 Extensibilidade  Trata-se de uma das características mais desejáveis em modelagem em geral, e em OO em particular.  Usado para estender a linguagem UML de “forma controlada”  Adaptação fácil a novos contextos (e.g. modelagem de aplicações de um determinado domínio), reaproveitando um núcleo de primitivas e construtores consolidados: modelagem na WEB workflow sistemas geográficos 60 PESC/COPPE/UFRJ - Toacy C. de Oliveira

62 Leitora de Cartão Extensibilidade – Estereótipo  Estereótipo: é uma extensão do vocabulário de UML, permitindo a criação de novos tipos de blocos de construção semelhante aos existentes, mas específicos a determinado problema. Exemplos  um tipo particular de associação  um tipo particular de classe (atributos próprios implícitos, restrições sobre tipos de associações aos quais pode estar ligado, etc.) > FatorForaLimite 61 PESC/COPPE/UFRJ - Toacy C. de Oliveira

63 Extensibilidade – Valor Rotulado  Valor Rotulado: é uma extensão da propriedade de um elemento da UML, permitindo a criação de novas informações na especificação deste elemento.  usado para definir propriedades do elemento, e não de suas instâncias (espécie de “metapropriedade”)  uso comum: especificação de propriedades relevantes para geração de código ou gerência de configuração Valor Rotulado 62

64 PESC/COPPE/UFRJ - Toacy C. de Oliveira Extensibilidade - Restrição  Restrição: é uma extensão da semântica de um elemento da UML, permitindo adicionar novas regras ou modificar as existentes.  Representação gráfica: { } ContaCorrente numero nomeCliente tipo : {pessoaFisica,pessoaJuridica} endereço sexo : {masculino,feminino} LançamentosContaCorrente data valor tipo : {débito,crédito} histórico {criptografada} 0..* lançamento restrição 63

65 Extensibilidade - Restrição OCL  Permite descrever restrições complexas textualmente  OCL – Object Constraint Language /* * The academic grade of a students supervisor must be greater than the academic grade of the supervised person. */ context Student inv inv1: self.supervisor.grade.value > self.grade.value 64 PESC/COPPE/UFRJ - Toacy C. de Oliveira

66 CUIDADO pois UML.....  Permite a representação da abstração.  Não é executável.  Não tem compilador. 65 PESC/COPPE/UFRJ - Toacy C. de Oliveira

67 Se restassem apenas 5 min. de curso....... 66 PESC/COPPE/UFRJ - Toacy C. de Oliveira

68 UP como pano de fundo Iteração(ões) Preliminar(es) Iter. #1 Fases Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Gerenciamento de Projeto Ambiente Modelagem do Negócio Implementação Teste Análise e Projeto Disciplinas do Processo Disciplinas do Suporte Entrega Gerenciamento de Alterações e Configuração Requisitos ElaboraçãoTransição Concepção Construção 67 PESC/COPPE/UFRJ - Toacy C. de Oliveira

69 O Problema (Documento de Visão)  Este projeto tem como objetivo implementar um sistema que simula um jogo de dados. O jogo começa quando o jogador arremessa dois dados. Caso a soma das faces dos dados seja 7, o jogador é vencedor, caso contrário é perdedor.  Os dados possuem 6 lados e em cada lado há um número de 1 a 6 (sem repetições)  REQ01: O Jogador pode iniciar um jogo novo  REQ02: O Jogador arremessa os dados.  REQ Não Funcionais: O sistema deverá ser desenvolvido utilizando linha de comando, ou seja, não há interface gráfica. 68 PESC/COPPE/UFRJ - Toacy C. de Oliveira

70 Modelos de Análise  Modelo de Casos de Uso (Funcional) Diagrama de Caso de Uso Especificação de Casos de Uso  Modelo de Classes (Estrutural) Classes de Análise 69 PESC/COPPE/UFRJ - Toacy C. de Oliveira

71 Diagrama de Caso de Uso  Especifica os atores que interagem com o sistema  Especifica quais funções cada ator tem “acesso” 70 PESC/COPPE/UFRJ - Toacy C. de Oliveira

72 Especificação de Caso de Uso  Texto estruturado que detalha um Caso de Uso em específico.  Contém Nome do Caso de Uso Atores Envolvidos Lista com pré e pós condições para a execução do Caso de Uso Fluxos básicos e alternativos, com os passos executados pelo ator e pelo sistema. 71 PESC/COPPE/UFRJ - Toacy C. de Oliveira

73 Exemplo  UC: Arremessar Dados  Atores : Jogador  Pré-condição : jogo inicializado  Pós-condição : vencedor é conhecido AtorSistema Solicita Arremesso de dadosSimula Arremesso Apresenta resultados 72 PESC/COPPE/UFRJ - Toacy C. de Oliveira

74 Importante!!!!!  Como o Caso de Uso é um modelo da fase de análise não é desejável atrelá- lo a uma plataforma de execução.  Quem disse que o sistema tem menu??? Será que não dá para fazer a mesma função via comando de voz? AtorSistema Seleciona Menu Arremesso de dadosSimula Arremesso Apresenta resultados 73 PESC/COPPE/UFRJ - Toacy C. de Oliveira

75 Como achar Casos de Uso/Atores  Analisar Requisitos Funcionais  Dica: Analisar os verbos e sujeitos presentes na especificação.  Procurar ações que o sistema faz e que são perceptíveis para um elemento externo(atores).  Imprimir Texto, Pagar com Cartão de Crédito, Fazer Empréstimo, etc  Procurar quem dispara as ações  Gerente Faz Empréstimo, Cliente Paga com Cartão, etc 74 PESC/COPPE/UFRJ - Toacy C. de Oliveira

76 Atividade – Iniciar Jogo 75 PESC/COPPE/UFRJ - Toacy C. de Oliveira

77 Atividade – Arremessar Dados 76 PESC/COPPE/UFRJ - Toacy C. de Oliveira

78 Diagrama de Classes  Estamos usando o Processo Unificado como referência, ou seja, a abstração utilizada na implementação será orientada a objetos.  Casos de Uso organizam funções, mas não ressaltam os conceitos e relacionamentos importantes para o sistema.  Classes expressam conceitos e seus relacionamentos. 77 PESC/COPPE/UFRJ - Toacy C. de Oliveira

79 Classes – Modelo Conceitual  Especifica conceitos, seus atributos e relacionamentos  É parte da fase de Análise 78 PESC/COPPE/UFRJ - Toacy C. de Oliveira

80 Importante!!!  Classes de Análise não especificam operações. Estas entram no início do projeto. Não há metodos  Classes de Análise também não especificam conceitos da plataforma de execução. Menu, Banco de Dados,...... 79 PESC/COPPE/UFRJ - Toacy C. de Oliveira

81 Descobrindo Classes  Destacando COISAS no texto de requisitos REQ01: O Jogador pode iniciar um jogo novo REQ02: O Jogador arremessa os dados  Cartões CRC Class – Responsability - Collaboration 80 PESC/COPPE/UFRJ - Toacy C. de Oliveira

82 Descobrindo Operações  CRC  Cenários de Execução 81 PESC/COPPE/UFRJ - Toacy C. de Oliveira

83 Cenário - Iniciar Jogo  Utiliza o Diagrama de Sequencia da UML para simular a execução de um Caso de Uso, distribuindo as funcionalidades pelas classes especificadas anteriormente (Classes de Análise) 82 PESC/COPPE/UFRJ - Toacy C. de Oliveira

84 Cenário – ArremessarDados 83 PESC/COPPE/UFRJ - Toacy C. de Oliveira

85 Classes – Modelo de Projeto  As classes de projeto refinam as classes descobertas na análise.  Adicionam operações  Verificam Boas Práticas de Modelagem Coesão, Acoplamento, Reuso  Se conectam com a plataforma de execução Hibernate, J2EE,.NET 84 PESC/COPPE/UFRJ - Toacy C. de Oliveira

86 Classes de Projeto  A Classe jogador foi eliminada -> Não há necessidade durante execução  Os relacionamentos foram direcionados -> Assim o acoplamento é diminuído.  As operações apareceram (por enquanto por milagre) 85 PESC/COPPE/UFRJ - Toacy C. de Oliveira

87 Código public class Dado { private int resultado; protected void Randomize() { // your code here } public void Arremessa() { // your code here } public class Jogo { public Dado dado; public Dado dado_1; public void ApresentaResultado() { // your code here } public void ZerarSoma() { // your code here } 86 PESC/COPPE/UFRJ - Toacy C. de Oliveira

88 Processo de Desenvolvimento 87 Casos de Uso Classes de Análise Classes de Projeto Cenários de Execução Especificaç ão Desenvolvime nto ValidaçãoEntrega Construção de Sistemas Informaçõ es Pessoas PESC/COPPE/UFRJ - Toacy C. de Oliveira

89 Processo de Desenvolvimento de Software 88 PESC/COPPE/UFRJ - Toacy C. de Oliveira

90 Processo  É necessário adotar um processo de desenvolvimento para manter a execução das atividades em um fluxo coerente. People are more important than any process. Good people with a good process will outperform good people with no process every time. —Grady Booch 89 PESC/COPPE/UFRJ - Toacy C. de Oliveira

91 O Processo Unificado Iteração(ões) Preliminar(es) Iter. #1 Fases Iterações Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Gerenciamento de Projeto Ambiente Modelagem do Negócio Implementação Teste Análise e Projeto Disciplinas do Processo Disciplinas do Suporte Entrega Gerenciamento de Alterações e Configuração Requisitos ElaboraçãoTransição Concepção Construção 90 PESC/COPPE/UFRJ - Toacy C. de Oliveira

92 Fases  Representam o ciclo de vida do software segundo o Processo Unificado Concepção Elaboração Construção Transição 91 PESC/COPPE/UFRJ - Toacy C. de Oliveira

93 Fases  Concepção: estabelece o caso de negócio para o sistema e delimita o escopo do projeto.  Elaboração: envolve a análise do domínio do problema e a especificação da arquitetura do sistema.  Construção: envolve a elaboração do software a partir de arquitetura em um produto completo para utilização pelos usuários.  Transição: viabiliza que o software possa ser utilizado pelos usuários. 92 PESC/COPPE/UFRJ - Toacy C. de Oliveira

94 UP & Cronograma From Larman 93 PESC/COPPE/UFRJ - Toacy C. de Oliveira

95 Disciplinas  Organizam o trabalho em função de artefatos e atividades afins. Modelagem de Negócio Requisitos Análise e Projeto Implementação Teste Entrega Gerencia de Projeto Ambiente Gerencia de Configuração 94 PESC/COPPE/UFRJ - Toacy C. de Oliveira

96 Mais informações...  Openup http://epf.eclipse.org/wikis/openup/  UpEDU http://www.upedu.org/ 95 PESC/COPPE/UFRJ - Toacy C. de Oliveira