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  funcionais e não-funcionais  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 Instabilidade dos requisitos funcionais e não- funcionais As tecnologias mudam — inevitavelmente Instabilidade dos requisitos não-funcionais A vontade e objetivos dos usuários mudam — imprevisivelmente Instabilidade dos requisitos funcionais

8 Análise + “Design” Completos antes da Implementação?
Uma especificação completa tem que ser tão detalhada quanto o próprio código Pergunte a qualquer programador: uma especificação completa é possível? Ele provavelmente duvidará Requisitos, em um certo momento, são normalmente incompletos e instáveis Desenvolver software é uma atividade intrinsecamente difícil Discover Magazine, 1999: Software caracterizado como a mais complexa ‘máquina’ que a humanidade já construiu A situação tende a se complicar enormemente, na medida da complexidade do software, e do número de pessoas envolvidas

9 A Voz da Experiência e da Pesquisa
Em 1994, o “Department of Defense” (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 10 anos defendem a substituição do modelo cascata por um modelo iterativo ou incremental The Unified Software Development Process Applying UML and Patterns Software Project Management Succeeding with Objects Object Solutions Surviving Object-oriented Projects …

10 Portanto...

11 Usem o Modelo Iterativo!
Em oposição ao modelo em cascata, interação (feedback) entre as atividades, e refinamento contínuo dos artefatos, são as novas palavras de ordem Devagar com o andor, ou passos curtos Iteração ou desenvolvimento por pequenos incrementos Intervalos de tempo (ciclos) pré-estabelecidos Em geral, de 2 a 4 semanas

12 O Conceito Chave de Iteração
... 1 2 2 a 4 semanas 2 a 4 semanas Codificação, Teste, Codificação, Teste, Análise “Design” Análise Projeto Integração Integração Forte interação entre as atividades

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

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

15 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

16 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!

17 Por que a Tecnologia de Objeto?
Os principais problemas do software hoje são Diminuir o custo da manutenção 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

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

19 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.

20 II. UML Grady Booch © Nabor C. Mendonça 2001

21 A Importância da UML É uma linguagem orientada a objeto
É um padrão, de fato Cobre todas as atividades de um processo de desenvolvimento, como (R)UP (R)UP / UML: metodologia orientada a objeto É baseada na experiência e necessidades das quatro atividades Oferecida por muitas ferramentas “Case”

22 Diagramas UML 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

23 Diagramas UML Um diagrama é uma visão parcial de um sistema, segundo um modelo Adequada 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: caso de uso (“use case”), classe, objeto, componente, “deployment” Visões dinâmicas: seqüência, colaboração, diagrama de estado, diagrama de atividade

24 III. A Metodologia UP / UML em Detalhes
© Nabor C. Mendonça 2001

25 Por Que UP / UML? Metodologia Padrão, de fato, na indústria de software Você, quando se tornar egresso do nosso Curso, terá uma chance muito grande de vir a trabalhar segundo a metodologia UP/ UML

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, interativamente)

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

28 O Conceito de Iteração (3)
As iterações de maior risco são resolvidas 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 da análise e do “design” diminuem com as últimas iterações

31 O Conceito de Iteração (6)

32 Características Gerais da Metodologia
Processo iterativo ou incremental Grandes atividades (“disciplines”, Larman) de uma iteração Análise Projeto (“Design”) Implementação Validação: Teste & Integração  Testes de Regressão A maioria dos artefatos de análise e “design” é formalmente descrita usando a linguagem UML

33 Características Gerais da Metodologia (2)
Fases do Processo Início (”Inception”), ou Planejamento, ou Concepção Elaboração Construção Transição Uma fase (exceto a primeira) é composta de diversas iterações

34 Características Gerais da Metodologia (3)

35 Fase Início (“Inception”), ou de Planejamento
Sumário Executivo Levantamento Parcial dos Requisitos Funcionais e Requisitos Não-Funcionais Associados Requisitos Funcionais Diretamente relacionados com o negócio Requisitos Não-funcionais Questões de desempenho Emprego de certas tecnologias . . .

36 Fase Início (2) Organização dos Requisitos em
Casos de Uso Manutenção de Entidades Consultas / Relatórios Modelagem Conceitual Preliminar A partir dos Casos de Uso e das Entidades Validação, por meio das consultas / relatórios Planejamento das Iterações Cronograma das Iterações

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

38 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 parciais Atividades típicas de cada iteração: 1. Refinar o planejamento 2. Sincronizar artefatos 3. Análise (foco da disciplina) 4. “Design” (foco da disciplina) 5. Implementação 6. Teste

39 Fase de Elaboração (3) Cada ciclo de desenvolvimento implementa um conjunto reduzido de requisitos funcionais, isto é, adiciona novas funções ao sistema Crescimento incremental, através de expansões e refinamentos sucessivos Ciclos com tempo fixo de duas a quatro semanas Vantagens: Evita complexidade excessiva Antecipa feedback dos usuários (sistema funcionando parcialmente)

40 Fase de Elaboração (4) Refinamento da Análise
Refinamento dos Requisitos Funcionais Refinamento dos Requisitos Não-Funcionais associados a Requisitos Funcionais Casos de Uso Expandidos Refinamentos sucessivos do Modelo Conceitual Diagramas de Seqüência de Operações Contratos de Operação Validação do Modelo Conceitual também através dos Contratos

41 Fase de Elaboração (5) “Design” em Refinamentos Sucessivos
Para cada operação de um Contrato Diagrama de Colaboração entre os Objetos da Operação Diagrama de Classe do Sistema Transformação de Entidades / Conceitos do Modelo Conceitual em Classes de Software

42 Fase de Elaboração (6) Historicamente, a média de iterações da fase é 3 O ”tournant” : todos os requisitos funcionais implementados

43 Fase de Construção Como a fase de Elaboração, mas cuidando apenas de requisitos não-funcionais O « tournant »: todos os requisitos não- funcionais implementados Consequentemente, as atividades de análise e « design » são pequenas Obs: A fase de construção não é foco da disciplina

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

45 Artefatos (2) Atividades Artefato UML Início Elab. E1.E3 Análise
Iteração Início Elab. E1.E3 Análise Diagrama de Casos de Uso Diagramas de Seqüência de Operações Diagrama de Classe, em Alto Nível Contrato i r i / r « Design » Diagrama de Colaboração entre Objetos Diagrama de Classe i = início r = refinamento

46 Um Pequeno Exemplo Ilustrativo (Parcial)
Caso de Uso (extremamente simples, e apresentado de maneira informal)  Jogo de Dados : em um 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 Nomes (sublinhados) e expressões nominais (sublinhadas) sugerem entidades ou conceitos do sistema, ou então atributos de entidades ou conceitos Verbos (sublinhados) e expressões verbais (sublinhadas) Está implícito que: um jogador joga jogo o jogo inclui dois valores de face

47 -- Modelo Conceitual Preliminar --
Exemplo ... (2) -- Modelo Conceitual Preliminar -- Observe que os verbos ganha e perde não caracterizam relacionamentos entre entidades, mas comportamento

48 -- Modelo Conceitual Refinado --
Exemplo ... (3) JogoDeDados Lança Dado 1 2 dado1 dado2 valorDaFace -- Modelo Conceitual Refinado -- Não estamos interessados na entidade Jogador Jogador é uma entidade externa, ou ator

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

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