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

 Professor Toacy Cavalcante de Oliveira, DSc. Área de Interesse  Engenharia de Software,  Reutilização de Software  Processo de Software 2 PESC/COPPE/UFRJ - Toacy C. de Oliveira

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

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

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

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

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

Introdução 8

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 [ ] 9 PESC/COPPE/UFRJ - Toacy C. de Oliveira

Dados interessantes  Standish Group Report 1995  Objeto de Estudo : 3682 projetos em 365 companhias.  Em  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 => 10 PESC/COPPE/UFRJ - Toacy C. de Oliveira

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

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

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 ] 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

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

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

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

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

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

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

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

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

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 PESC/COPPE/UFRJ - Toacy C. de Oliveira

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

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

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

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

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

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

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

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

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

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 PESC/COPPE/UFRJ - Toacy C. de Oliveira

Histórico  : 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 PESC/COPPE/UFRJ - Toacy C. de Oliveira

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

Histórico 1994 Método de BoochOMT (Rumbaugh)OOSE (Jacobson) Outros métodos Unified Method 0.8 OOPSLA UML 1.0 Primeira submissão à OMG – Jan/1997 Consórcio ”Parceiros UML” Outras empresas se juntam ao Consórcio 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 Março/2003 = UML 1.5 Early/2007 = UML PESC/COPPE/UFRJ - Toacy C. de Oliveira

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, PESC/COPPE/UFRJ - Toacy C. de Oliveira

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mais informações...  Openup  UpEDU 95 PESC/COPPE/UFRJ - Toacy C. de Oliveira