No Slide Title - Computação UFCG
Propaganda
Metodologia (R)UP + UML © Nabor C. Mendonça 2001 1 Roteiro I. A Motivação para o Modelo Iterativo e a Tecnologia de Objetos II. UML: Visão Geral III. (R)UP + UML em Detalhes © Nabor C. Mendonça 2001 2 I. A Motivação para o Modelo Iterativo e a Tecnologia de Objetos Baseado em uma apresentação de Craig Larman © Nabor C. Mendonça 2001 3 Software — Um Investimento de Risco Resultado de projetos de software realizados nos EUA no início da década de 90 •Todos baseados no modelo cascata Inacabados 30% •53% custaram até 200% acima da estimativa inicial •Estimou-se que $81 bilhões foram Concluídos gastos em projetos 70% fracassados só no ano de 1995 Fonte: Standish Report, 1994 © Nabor C. Mendonça 2001 4 O Que Deu Errado? O modelo cascata é fortemente baseado em suposições oriundas dos processos de engenharia convencionais Algumas dessas suposições não foram confirmadas na prática – Todos os requisitos podem ser precisamente identificados antes do desenvolvimento – Os requisitos são estáveis – O design pode ser feito totalmente antes da implementação © Nabor C. Mendonça 2001 5 Imprecisão dos Requisitos Estudo publicado por Capers Jones em 1987, baseado em 6.700 sistemas % de Req's Problemáticos 60 50 40 30 20 10 0 10 100 1000 10000 100000 Tamanho do Sistema de Software em Pontos por Função © Nabor C. Mendonça 2001 6 Instabilidade dos Requisitos O mercado muda — constantemente As tecnologias mudam — inevitavelmente A vontade e objetivos dos usuários mudam — imprevisivelmente © Nabor C. Mendonça 2001 7 Análise + Design Completos antes da Implementação? Pergunte a qualquer programador Requisitos são incompletos e instáveis Uma especificação completa tem que ser tão detalhada quanto o próprio código Desenvolver software é uma atividade intrinsecamente “difícil” – Discover Magazine, 1999: Software caracterizado como a mais complexa “máquina” que a humanidade já construiu © Nabor C. Mendonça 2001 8 Pessoas / Mês Esforço — O Perigo dos Passos Largos 80000 70000 60000 50000 40000 30000 20000 10000 0 66690 1 20 267 4362 Tamanho do Sistema em Pontos por Função Fonte: Applied Software Measurement, Capers Jones, 1997 © Nabor C. Mendonça 2001 9 LOC/Pessoa por Mês Produtividade — O Perigo dos Passos Largos 4500 4000 3500 3000 2500 2000 1500 1000 500 0 1 10 100 1000 Tamanho do Sistema em KLOC Fonte: Measures For Excellence, Putnam, 1992. Baseado em 1.600 sistemas © Nabor C. Mendonça 2001 10 A Voz da Experiência e da Pesquisa Em 1994, o DoD (EUA) parou de contratar projetos baseado no modelo cascata, por causa de fracassos abismais – Eles agora incentivam um modelo iterativo Virtualmente todos os trabalhos na área publicados nos últimos 5 anos defendem a substituição do modelo cascata por um modelo iterativo – The Unified Software Development Process – Applying UML and Patterns – Software Project Management – Succeeding with Objects – Object Solutions – Surviving Object-oriented Projects – … © Nabor C. Mendonça 2001 11 Portanto... © Nabor C. Mendonça 2001 12 Usem o Modelo Iterativo! Passos curtos, interação (feedback) e refinamento Iterativo, incremental, com intervalos de tempo (ciclos) pré-estabelecidos Iteração 1 Análise Projeto Codificação, Teste, Integração 2 a 4 semanas © Nabor C. Mendonça 2001 Iteração 2 Análise ... Projeto Codificação, Teste, Integração 2 a 4 semanas 13 Um Processo Iterativo Popular — RUP Atenção: as fases não são iterações! © Nabor C. Mendonça 2001 14 O Custo da Mudança Planos estratégicos e racionais de desenvolvimento baseiam-se no custo total do sistema, não apenas nos custos de desenvolvimento Outros Código Teste Projeto Revisão & Manutenção Documentação Fonte: DP Budget, Vol. 7, No. 12, Dez. 1988 © Nabor C. Mendonça 2001 15 O Custo da Mudança Estudo com projetos de software do governo Americano Usado depois de alterações 3% Usado mas bastante alterado ou em seguida abandonado 19% Usado tal como entregue 2% Entregue mas nunca usado satisfatoriamente 47% Pago mas não entregue 29% Fonte: US Government Accounting Office, Report FGMSD-80-4 © Nabor C. Mendonça 2001 16 O Custo da Mudança Um estudo da AT&T indicou que, na média, © Nabor C. Mendonça 2001 17 Por que a Tecnologia de Objeto? Os principais problemas do software hoje são – Diminuir o custo e o tempo da mudança – Aumentar a capacidade e facilidade de adaptação Fato: Objetos são especialmente bons para – Reduzir o tempo necessário para adaptar um sistema existente (reação mais rápida à mudanças no seu ambiente de negócio) – Reduzir o esforço, a complexidade e os custos associados à mudança Em suma: © Nabor C. Mendonça 2001 18 Por Que a Tecnologia de Objeto? (2) Segundo um estudo corporativo de 1997, as razões prioritárias para se adotar a tecnologia de objeto (TO) são: – 1. Capacidade de aproveitar novas plataformas e ferramentas – 2. Facilidade de manutenção – 3. Economia de custos – 4. Desenvolvimento de aplicações lucrativas – 5. Encapsulamento das aplicações existentes – 6. Melhores interfaces – 7. Maior produtividade – 8. Participação no "futuro da computação" – 9. Prova da capacidade de usar a tecnologia – 10. Rápido desenvolvimento de aplicações estratégicas – 11. Reuso de software © Nabor C. Mendonça 2001 Notem a alta prioridade Notem a baixa prioridade 19 Por que a Tecnologia de Objeto? (3) “O valor da TO (APOO, POO) está fundamentalmente na sua capacidade de lidar com problemas complexos e criar sistemas compreensíveis e gerenciáveis, que podem acompanhar uma complexidade crescente e ser facilmente adaptáveis—se habilidosamente projetados.” Craig Larman Ataca complexidade elegantemente e gera fácil adaptabilidade A produtividade se sobressai nas ... Produtividade Reuso © Nabor C. Mendonça 2001 fases de manutenção ou modificação do sistema — freqüentemente com mudanças profundamente mais rápidas, se o sistema foi habilidosamente projetado. 20 II. UML Grady Booch © Nabor C. Mendonça 2001 21 A Importância da UML É um padrão, de fato Cobre as atividades de análise e design de um processo de desenvolvimento orientado a objeto de software É baseada na experiência e necessidades dos usuários de todos os tipos Implementada em muitas ferramentas © Nabor C. Mendonça 2001 22 Diagramas UML A model is a complete description of a system from a particular perspective Use Case Use Case Diagrams Sequence Diagrams Diagrams Scenario Scenario Diagrams Collaboration Diagrams Diagrams Scenario Scenario Diagrams Statechart Diagrams Diagrams © Nabor C. Mendonça 2001 Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams State State Diagrams Object Diagrams Diagrams State State Diagrams Component Diagrams Diagrams Models Component Component Diagrams Deployment Diagrams Activity Diagrams Diagrams 23 Diagramas Um diagrama é uma visão segundo um modelo – Apresentado de modo conveniente a um tipo de usuário (“stakeholder”) – Dá uma visão parcial do sistema – É semanticamente consistente com outras visões Na UML, existem 9 diagramas – Visões estáticas: use case, classe, objeto, componente, deployment – Visões dinâmicas: seqüência, colaboração, diagrama de estado, diagrama de atividade © Nabor C. Mendonça 2001 24 III. A Metodologia em Detalhes © Nabor C. Mendonça 2001 25 O Conceito de Iteração Um mini projeto com duração pequena (por exemplo, 1 mês), com resultados testados e integrados Cada iteração inclui seus próprios requisitos de análise, design, implementação e teste O final de uma iteração é uma peça correta release de software (passou por análise, design, implementação e testes) © Nabor C. Mendonça 2001 26 O Conceito de Iteração (2) -- Desenvolvimento Iterativo e Incremental -© Nabor C. Mendonça 2001 27 O Conceito de Iteração (3) As iterações de maior risco são atacadas primeiro – Diretamente relacionadas com o negócio – Riscos potencialmente altos no início do desenvolvimento As iterações de menor risco são deixadas para o final – Iterações não diretamente relacionadas com o negócio – Riscos baixos à medida que se aproxima do final © Nabor C. Mendonça 2001 28 O Conceito de Iteração (4) -- Risco Potencial Pequeno, no Final -- © Nabor C. Mendonça 2001 29 O Conceito de Iteração (5) Feedback (interatividade) e adaptação iterativos conduzem ao sistema desejado A instabilidade dos requisitos e do design diminuem com as últimas iterações © Nabor C. Mendonça 2001 30 O Conceito de Iteração (6) © Nabor C. Mendonça 2001 31 Características Gerais da Metodologia Iterativo e incremental – Grandes atividades (disciplines) de uma iteração Análise Projeto Implementação Validação: Teste & Integração Testes de Regressão Todos os artefatos de análise e design são formalmente descritos usando a linguagem UML © Nabor C. Mendonça 2001 32 Características Gerais da Metodologia (2) Fases do processo – Início ou Planejamento (Inception) – Elaboração – Construção – Transição Uma fase (exceto a primeira) é composta de diversas iterações © Nabor C. Mendonça 2001 33 Características Gerais da Metodologia (3) © Nabor C. Mendonça 2001 34 Fase Início Planejamento Elaboração 2. Criar Rel. Prel. de Investigação 1. Definir Plano Inicial © Nabor C. Mendonça 2001 Construção 4. Reg. Termos no Glossário a 5. Implementar Protótipo 7. Definir Mod. Conc. Inicial 8. Definir Arquit. Inicial a, c, d c b, d 3. Definir Requisitos 6. Definir Casos de Uso Notas 9. Det. das Demais Fases a. contínua b. opcional c. adiável d. ordem variada 35 Fase Início (2) 1. Plano Inicial (Business Case) © Nabor C. Mendonça 2001 36 Fase Início (3) 2. Criar relatório preliminar de investigação Motivação, alternativas, necessidades de negócio 3. Definir requisitos iniciais Especificação declarativa dos requisitos 4. Registrar termos no glossário Dicionário de termos, regras, restrições 5. Implementar protótipo Protótipo do sistema para ajudar na definição dos requisitos © Nabor C. Mendonça 2001 37 Fase Início (4) 6. Definir use cases iniciais Descrição em prosa estruturada dos processos de negócio 7. Definir modelo conceitual inicial Objetos do domínio e seus relacionamentos 8. Definir arquitetura inicial Principais subsistemas e suas dependências 9. Detalhamento das Demais Fases Obs.: Atividades não seqüenciais © Nabor C. Mendonça 2001 38 Fase Início (5) Detalhamento das Fases – Iterações (ou definição dos incrementos) Requisitos: funções que o sistema deve oferecer – Requisitos Funcionais Diretamente relacionados com o negócio – Requisitos Não-funcionais Questões de desempenho Emprego de certas tecnologias ... © Nabor C. Mendonça 2001 39 Fase Início (6) Modelo do Negócio (ou do Domínio), ou Modelo Conceitual – Principais Entidades ou Conceitos – Relacionamentos entre as Entidades Um Diagrama de Classe Simplificado © Nabor C. Mendonça 2001 40 Fase de Elaboração Planejamento Iteração 1 Iteração 2 Refin. Plano © Nabor C. Mendonça 2001 Elaboração Construção ... Sinc. Artefatos Análise Design Impl. Teste 41 Fase de Elaboração (2) Iterações – Construção progressiva do sistema até atingir uma versão que satisfaça corretamente os requisitos funcionais Atividades típicas de cada iteração: 1. Refinar plano das fases 2. Sincronizar artefatos 3. Análise 4. Projeto 5. Implementação 6. Teste © Nabor C. Mendonça 2001 42 Fase de Elaboração (3) Cada ciclo de desenvolvimento implementa um conjunto reduzido de requisitos, adicionando novas funções ao sistema – Crescimento incremental, através de expansões e refinamentos sucessivos Ciclos com tempo fixo de duas a oito semanas Vantagens: – Evita complexidade excessiva – Antecipa feedback dos usuários © Nabor C. Mendonça 2001 43 Fase de Construção Como a fase de Elaboração, mas cuidando apenas de requisitos não-funcionais – O « tournant »: todos os requisitos funcionais implementados Obs: A fase de construção não é foco da disciplina © Nabor C. Mendonça 2001 44 Artefatos Toda iteração deve produzir artefatos – Artefato é uma peça de informação que é produzida, modificada ou utilizada por um processo – Artefato UML: um artefato formalmente definido segundo a sintaxe UML © Nabor C. Mendonça 2001 45 Artefatos (2) Atividades Artefato UML Iníc. Elab. E1.E3 Iteração Análise Design Use Case -----------------------Diagrama de Seqüência do Sistema (System Sequence Diagram) -----------------------Modelo Conceitual -----------------------Contrato Diagrama de Colaboração entre Objetos (Object Sequence Diagram; Object Collaboration Diagram) -----------------------Diagrama de Classe Detalhado i r i r i r i r i-r i-r i = início r = refinamento © Nabor C. Mendonça 2001 46 Um Pequeno Exemplo Ilustrativo (Parcial) Use Case (extremamente simples, e apresentado de maneira informal) – Jogo de Dados : no jogo de dados, um jogador lança dois dados; se a soma dos valores de face for 7, ele ganha; caso contrário, ele perde. Está implícito que: um jogador joga jogo o jogo inclui dois valores de face © Nabor C. Mendonça 2001 47 Exemplo (2) -- Modelo Conceitual (Versão #1) -- © Nabor C. Mendonça 2001 48 Exemplo (3) JogoDeDados Lança 1 2 Dado Não estamos interessados na entidade Jogador Jogador é apenas um usuário, ou ator -- Modelo Conceitual (Versão #2) -© Nabor C. Mendonça 2001 49 Exemplo (4) Jogador Do jeito em que está, o jogador não sabe o resultado do jogo. Como sabê-lo? -- Diagrama de Colaboração entre Objetos -© Nabor C. Mendonça 2001 50 Exemplo (5) Modifique o diagrama, para que o jogador saiba o resultado do jogo -- Diagrama de Classe -© Nabor C. Mendonça 2001 51
