Metodologia (R)UP + UML

Apresentação em tema: "Metodologia (R)UP + UML"— Transcrição da apresentação:

1 Metodologia (R)UP + UML
© Nabor C. Mendonça 2001

2 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

3 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

4 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 53% custaram até 200% acima da estimativa inicial Estimou-se que $81 bilhões foram gastos em projetos fracassados só no ano de 1995 Inacabados 30% Concluídos 70% Fonte: Standish Report, 1994

5 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

6 Imprecisão dos Requisitos
Estudo publicado por Capers Jones em 1987, baseado em sistemas 60 50 40 % de Req's Problemáticos 30 20 10 10 100 1000 10000 100000 Tamanho do Sistema de Software em Pontos por Função

7 Instabilidade dos Requisitos
O mercado muda — constantemente As tecnologias mudam — inevitavelmente A vontade e objetivos dos usuários mudam — imprevisivelmente

8 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

9 Esforço — O Perigo dos Passos Largos
1 20 267 4362 66690 10000 20000 30000 40000 50000 60000 70000 80000 10 100 1000 100000 Tamanho do Sistema em Pontos por Função Pessoas / Mês Fonte: Applied Software Measurement, Capers Jones, 1997

10 Produtividade — O Perigo dos Passos Largos
4500 4000 3500 3000 2500 LOC/Pessoa por Mês 2000 1500 1000 500 1 10 100 1000 Tamanho do Sistema em KLOC Fonte: Measures For Excellence, Putnam, Baseado em sistemas

11 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 …

12 Portanto...

13 Usem o Modelo Iterativo!
Passos curtos, interação (feedback) e refinamento Iterativo, incremental, com intervalos de tempo (ciclos) pré-estabelecidos Iteração Iteração ... 1 2 2 a 4 semanas 2 a 4 semanas Codificação, Teste, Codificação, Teste, Análise Projeto Análise Projeto Integração Integração

14 Um Processo Iterativo Popular — RUP
Atenção: as fases não são iterações!

15 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

16 O Custo da Mudança Estudo com projetos de software do governo Americano Usado depois de alterações 3% Usado tal como entregue 2% Usado mas bastante alterado ou em seguida abandonado 19% Entregue mas nunca usado satisfatoriamente 47% Pago mas não entregue 29% Fonte: US Government Accounting Office, Report FGMSD-80-4

17 Regras de Negócio mudam na taxa de 8% ao mês! O Custo da Mudança
Um estudo da AT&T indicou que, na média, Regras de Negócio mudam na taxa de 8% ao mês!

18 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: Flexibilidade

19 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 Notem a alta prioridade Notem a baixa prioridade

20 Por que a Tecnologia de Objeto? (3)
Ataca complexidade elegantemente e gera fácil adaptabilidade . . . Produtividade Reuso “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 A produtividade se sobressai nas fases de manutenção ou modificação do sistema — freqüentemente com mudanças profundamente mais rápidas, se o sistema foi habilidosamente projetado.

21 II. UML: uma Visão Geral Grady Booch © Nabor C. Mendonça 2001

22 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

23 Modelos, Visões e Diagramas
A model is a complete description of a system from a particular perspective State Diagrams Class Use Case Diagrams State Diagrams Object Use Case Diagrams Sequence Scenario Diagrams Collaboration State Diagrams Component Models Scenario Diagrams Statechart Component Diagrams Deployment Activity Diagrams

24 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

25 III. A Metodologia em Detalhes
© Nabor C. Mendonça 2001

26 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)

27 O Conceito de Iteração (2)
-- Desenvolvimento Iterativo e Incremental --

28 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

29 O Conceito de Iteração (4)
-- Risco Potencial Pequeno, no Final --

30 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

31 O Conceito de Iteração (6)

32 Características Gerais do Processo
Iterativo e incremental Grandes atividades (disciplines) de uma iteração Análise Projeto Implementação Validação: Teste & Integração Todos os artefatos de análise e design são formalmente descritos usando a linguagem UML

33 Características Gerais do Processo (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

34 Características Gerais do Processo (3)

35 Fase de Planejamento 2. Criar Rel. Prel. de Investigação
3. Definir Requisitos 9. Det. das Demais Fases 7. Definir Mod. Conc. Inicial c 4. Reg. Termos no Glossário a 6. Definir Casos de Uso 1. Definir Plano Inicial 5. Implementar Protótipo b, d a. contínua b. opcional c. adiável d. ordem variada 8. Definir Arquit. a, c, d Notas Elaboração Planeja- mento Construção

36 Fase de Planejamento (2)
1. Plano Inicial (Business Case)

37 Fase de Planejamento (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

38 Fase de Planejamento (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

39 Fase de Planejamento (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 . . .

40 Fase de Planejamento (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

41 Fase de Elaboração Planeja- mento Elaboração Construção Iteração 1
... Refin. Plano Sinc. Artefatos Análise Design Impl. Teste

42 Fase de Elaboração (2) Iterações Atividades típicas de cada iteração:
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

43 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

44 Fase de Construção Como a fase de Elaboração, mas cuidando apenas de requisitos não-funcionais Obs: A fase de construção não é foco da disciplina

45 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

46 Artefatos (2) Atividades Artefato UML Iníc. Elab. E1.E3 Análise
Iteração Iníc. Elab. E1.E3 Análise Use Case Diagrama de Seqüência do Sistema (System Sequence Diagram) Modelo Conceitual Contrato i r Design Diagrama de Interação entre Objetos (Object Sequence Diagram; Object Collaboration Diagram) Diagrama de Classe Detalhado i-r i = início r = refinamento

47 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

48 -- Modelo Conceitual (Versão #1) --
Exemplo (2) -- Modelo Conceitual (Versão #1) --

49 -- Modelo Conceitual (Versão #2) --
Exemplo (3) Lança JogoDeDados Dado 1 2 Não estamos interessados na entidade Jogador Jogador é apenas um usuário, ou ator -- Modelo Conceitual (Versão #2) --

50 -- Diagrama de Interação entre Objetos --
Exemplo (4) Jogador Do jeito em que está, o jogador não sabe o resultado do jogo. Como sabê-lo? -- Diagrama de Interação entre Objetos --

51 Modifique o diagrama, para que o jogador saiba o resultado do jogo
Exemplo (5) Modifique o diagrama, para que o jogador saiba o resultado do jogo -- Diagrama de Classe --