A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "© Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML."— Transcrição da apresentação:

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

2 © Nabor C. Mendonça 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 © Nabor C. Mendonça I. A Motivação para o Modelo Iterativo e a Tecnologia de Objetos Baseado em uma apresentação de Craig Larman

4 © Nabor C. Mendonça Software Um Investimento de Risco n Resultado de projetos de software realizados nos EUA no início da década de 90 Inacabados 30% Concluídos 70% Fonte: Standish Report, 1994 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

5 © Nabor C. Mendonça O Que Deu Errado? n O modelo cascata é fortemente baseado em suposições oriundas dos processos de engenharia convencionais n 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 © Nabor C. Mendonça Imprecisão dos Requisitos n Estudo publicado por Capers Jones em 1987, baseado em sistemas Tamanho do Sistema de Software em Pontos por Função % de Req's Problemáticos

7 © Nabor C. Mendonça Instabilidade dos Requisitos n O mercado muda constantemente – Instabilidade dos requisitos funcionais e não- funcionais n As tecnologias mudam inevitavelmente – Instabilidade dos requisitos não-funcionais n A vontade e objetivos dos usuários mudam imprevisivelmente – Instabilidade dos requisitos funcionais

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

9 © Nabor C. Mendonça A Voz da Experiência e da Pesquisa n 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 n 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 © Nabor C. Mendonça Portanto...

11 © Nabor C. Mendonça Usem o Modelo Iterativo! n 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 n 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 © Nabor C. Mendonça O Conceito Chave de Iteração Iteração 1 Design Codificação, Teste, Integração Análise... Iteração 2 ProjetoAnálise Codificação, Teste, Integração 2 a 4 semanas Forte interação entre as atividades

13 © Nabor C. Mendonça Um Processo Iterativo Popular RUP n Atenção: as fases não são iterações!

14 © Nabor C. Mendonça Documentação Projeto Teste Código Outros Revisão & Manutenção Fonte: DP Budget, Vol. 7, No. 12, Dez O Custo da Mudança n Planos estratégicos e racionais de desenvolvimento baseiam-se no custo total do sistema, não apenas nos custos de desenvolvimento

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

16 © Nabor C. Mendonça O Custo da Mudança n Um estudo da AT&T indicou que, na média,

17 © Nabor C. Mendonça Por que a Tecnologia de Objeto? n Os principais problemas do software hoje são – Diminuir o custo da manutenção – Aumentar a capacidade e facilidade de adaptação n 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 n Em suma:

18 © Nabor C. Mendonça n 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 baixa prioridade Notem a alta prioridade Por Que a Tecnologia de Objeto? (2)

19 © Nabor C. Mendonça n Ataca complexidade elegantemente e gera fácil adaptabilidade n... n Produtividade n Reuso 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. 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 Por que a Tecnologia de Objeto? (3)

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

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

22 © Nabor C. Mendonça Diagramas UML Use Case Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams State Diagrams State Diagrams Class Diagrams Activity Diagrams A model is a complete description of a system from a particular perspective Models

23 © Nabor C. Mendonça Diagramas UML n 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 n 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 © Nabor C. Mendonça III. A Metodologia UP / UML em Detalhes

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

26 © Nabor C. Mendonça O Conceito de Iteração n Um mini projeto com duração pequena (por exemplo, 1 mês), com resultados testados e integrados n Cada iteração inclui seus próprios requisitos de análise, design, implementação e teste n O final de uma iteração é uma peça correta release de software (passou por análise, design, implementação e testes, interativamente)

27 © Nabor C. Mendonça O Conceito de Iteração (2) -- Desenvolvimento Iterativo ou Incremental --

28 © Nabor C. Mendonça O Conceito de Iteração (3) n As iterações de maior risco são resolvidas primeiro – Diretamente relacionadas com o negócio – Riscos potencialmente altos no início do desenvolvimento n 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 © Nabor C. Mendonça O Conceito de Iteração (4) -- Risco Potencial Pequeno, no Final --

30 © Nabor C. Mendonça O Conceito de Iteração (5) n Feedback (interatividade) e adaptação iterativos conduzem ao sistema desejado n A instabilidade da análise e do design diminuem com as últimas iterações

31 © Nabor C. Mendonça O Conceito de Iteração (6)

32 © Nabor C. Mendonça Características Gerais da Metodologia n 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 n A maioria dos artefatos de análise e design é formalmente descrita usando a linguagem UML

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

34 © Nabor C. Mendonça Características Gerais da Metodologia (3)

35 © Nabor C. Mendonça Fase Início (Inception), ou de Planejamento n Sumário Executivo n 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 © Nabor C. Mendonça Fase Início (2) n Organização dos Requisitos em – Casos de Uso – Manutenção de Entidades – Consultas / Relatórios n Modelagem Conceitual Preliminar – A partir dos Casos de Uso e das Entidades – Validação, por meio das consultas / relatórios n Planejamento das Iterações n Cronograma das Iterações

37 © Nabor C. Mendonça Fase de Elaboração Iteração 1 Sinc. Artefatos AnáliseDesignTeste Refin. Plano Impl. Iteração 2... Elaboração Planeja- mento Construção

38 © Nabor C. Mendonça Fase de Elaboração (2) n Iterações – Construção progressiva do sistema até atingir uma versão que satisfaça corretamente os requisitos funcionais parciais n 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 © Nabor C. Mendonça Fase de Elaboração (3) n 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 n Ciclos com tempo fixo de duas a quatro semanas n Vantagens: – Evita complexidade excessiva – Antecipa feedback dos usuários (sistema funcionando parcialmente)

40 © Nabor C. Mendonça Fase de Elaboração (4) n 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 © Nabor C. Mendonça Fase de Elaboração (5) n 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 © Nabor C. Mendonça Fase de Elaboração (6) n Historicamente, a média de iterações da fase é 3 n O tournant : todos os requisitos funcionais implementados

43 © Nabor C. Mendonça Fase de Construção n 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 © Nabor C. Mendonça Artefatos n 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 © Nabor C. Mendonça Artefatos (2) i = início r = refinamento AtividadesArtefato UML Iteração InícioElab. E1.E3 AnáliseDiagrama de Casos de Uso Diagramas de Seqüência de Operações Diagrama de Classe, em Alto Nível Contrato iiii r i / r « Design »Diagrama de Colaboração entre Objetos Diagrama de Classe i / r

46 © Nabor C. Mendonça Um Pequeno Exemplo Ilustrativo (Parcial) n 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 © Nabor C. Mendonça Exemplo... (2) -- Modelo Conceitual Preliminar -- Observe que os verbos ganha e perde não caracterizam relacionamentos entre entidades, mas comportamento

48 © Nabor C. Mendonça Exemplo... (3) -- Modelo Conceitual Refinado -- JogoDeDadosDado 21 Lança Não estamos interessados na entidade Jogador Jogador é uma entidade externa, ou ator valorDaFacedado1 dado2

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

50 © Nabor C. Mendonça Exemplo... (5) -- Diagrama de Classe -- Modifique o diagrama, para que o jogador saiba o resultado do jogo


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

Apresentações semelhantes


Anúncios Google