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 2001 1 Metodologia (R)UP + UML

2 © 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 © Nabor C. Mendonça 2001 3 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 2001 4 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 2001 5 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 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 2001 6 Imprecisão dos Requisitos n Estudo publicado por Capers Jones em 1987, baseado em 6.700 sistemas 0 10 20 30 40 50 60 10100100010000100000 Tamanho do Sistema de Software em Pontos por Função % de Req's Problemáticos

7 © Nabor C. Mendonça 2001 7 Instabilidade dos Requisitos n O mercado muda — constantemente n As tecnologias mudam — inevitavelmente n A vontade e objetivos dos usuários mudam — imprevisivelmente

8 © Nabor C. Mendonça 2001 8 Análise + Design Completos antes da Implementação? n Pergunte a qualquer programador n Requisitos são incompletos e instáveis n Uma especificação completa tem que ser tão detalhada quanto o próprio código n Desenvolver software é uma atividade intrinsecamente “difícil” – Discover Magazine, 1999: Software caracterizado como a mais complexa “máquina” que a humanidade já construiu

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

10 © Nabor C. Mendonça 2001 10 Produtividade — O Perigo dos Passos Largos 0 500 1000 1500 2000 2500 3000 3500 4000 4500 1101001000 Tamanho do Sistema em KLOC LOC/Pessoa por Mês Fonte: Measures For Excellence, Putnam, 1992. Baseado em 1.600 sistemas

11 © Nabor C. Mendonça 2001 11 A Voz da Experiência e da Pesquisa n Em 1994, o DoD (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 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 © Nabor C. Mendonça 2001 12 Portanto...

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

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

15 © Nabor C. Mendonça 2001 15 Documentação Projeto Teste Código Outros Revisão & Manutenção Fonte: DP Budget, Vol. 7, No. 12, Dez. 1988 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

16 © Nabor C. Mendonça 2001 16 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

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

18 © Nabor C. Mendonça 2001 18 Por que a Tecnologia de Objetos? n 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 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:

19 © Nabor C. Mendonça 2001 19 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 Objetos? (2)

20 © Nabor C. Mendonça 2001 20 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 Objetos? (3)

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

22 © Nabor C. Mendonça 2001 22 As Diferentes Visões de um Sistema de Software Logical View End-user Functionality Implementation View Programmers Software management Process View Performance Scalability Throughput System integrators Deployment View System topology Delivery, installation Communication System engineering ConceptualPhysical Use Case View

23 © Nabor C. Mendonça 2001 23 A Importância da UML n É um padrão, de fato n Cobre as atividades de análise e design de um processo de desenvolvimento orientado a objeto de software n É baseada na experiência e necessidades dos usuários de todos os tipos n Implementada em muitas ferramentas

24 © Nabor C. Mendonça 2001 24 Elementos de Modelagem n Elementos estruturais – classe, interface, colaboração, “use case”, classe ativa, componente, … n Elementos comportamentais – interação, máquina de estado n Elementos de agrupamento – “package”, subsistema n Outros elementos – …

25 © Nabor C. Mendonça 2001 25 Relacionamentos n Dependência n Associação n Generalização n Realização

26 © Nabor C. Mendonça 2001 26 Outros Mecanismos n Estereótipo n “Tagged value” n Restrição (“Constraint”)

27 © Nabor C. Mendonça 2001 27 Modelos, Visões e Diagramas 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

28 © Nabor C. Mendonça 2001 28 Diagramas n 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 n 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

29 © Nabor C. Mendonça 2001 29 Diagrama de Use Case n Capta a funcionalidade do sistema como vista pelos atores

30 © Nabor C. Mendonça 2001 30 Diagrama de Use Case (2) n Artefato de análise n Propósitos – Especificar o contexto do sistema – Captar os requisitos do sistema – Validar uma arquitetura do sistema – Dirigir a implementação e os testes de aceitação n Desenvolvido por analistas e por especialistas do domínio da aplicação

31 © Nabor C. Mendonça 2001 31 Diagrama de Classe n Capta o vocabulário de um sistema

32 © Nabor C. Mendonça 2001 32 Diagrama de Classe (2) n Construído e refinado ao longo do desenvolvimento n Propósitos – Especificar as classes de software – Especificar colaborações entre classes – Especificar esquemas lógicos de banco de dados n Desenvolvido por analistas, designers e implementadores

33 © Nabor C. Mendonça 2001 33 Diagrama de Objeto n Capta instâncias de classes e associações entre instâncias

34 © Nabor C. Mendonça 2001 34 Diagrama de Objeto (2) n Construído durante a análise e o design n Propósitos – Ilustrar estruturas de dados / objetos – Especificar instantâneos de classes (snapshots) n Desenvolvido por analistas, designers, e implementadores

35 © Nabor C. Mendonça 2001 35 Diagrama de Componentes n Capta a estrutura física da implementação

36 © Nabor C. Mendonça 2001 36 Diagrama de Componentes (2) n Construído como parte da especificação arquitetural n Propósitos – Organizar códigos fontes – Construir e executar releases – Specificar fisicamente um banco de dados n Desenvolvido por programadores

37 © Nabor C. Mendonça 2001 37 Diagrama de Deployment n Capta a topologia do hardware do sistema

38 © Nabor C. Mendonça 2001 38 Diagrama de Deployment (2) n Construído como parte da especificação arquitetural n Propósitos – Especificar a distribuição dos componentes – Identificar gargalos de desempenho n Desenvolvido por engenheiros de redes, e por engenheiros de sistema

39 © Nabor C. Mendonça 2001 39 Diagrama de Seqüência n Capta o comportamento dinâmico (“time-oriented”) do sistema

40 © Nabor C. Mendonça 2001 40 Diagrama de Seqüência (2) n Propósitos – Modelar o fluxo de controle das ações do sistema – Ilustrar cenários típicos

41 © Nabor C. Mendonça 2001 41 Diagrama de Colaboração n Capta o comportamento dinâmico (“message- oriented”) do sistema

42 © Nabor C. Mendonça 2001 42 Diagrama de Colaboração (2) n Propósitos – Modelar o fluxo de controle das ações do sistema – Ilustrar a coordenação de objetos e controle

43 © Nabor C. Mendonça 2001 43 Diagrama de Estado n Capta o comportamento dinâmico (“event- oriented”) do sistema

44 © Nabor C. Mendonça 2001 44 Diagrama de Estado (2) n Propósitos – Modelar o ciclo de vida dos objetos – Modelar objectos reativos (interfaces, devices, etc.)

45 © Nabor C. Mendonça 2001 45 Diagrama de Atividades n Capta o comportamento dinâmico (“activity- oriented”) do sistema

46 © Nabor C. Mendonça 2001 46 Diagrama de Atividades (2) n Propósito – Modelar business workflows – Modelar operações

47 © Nabor C. Mendonça 2001 47 Arquitetura e UML Organization Package, subsystem Dynamics Interaction State machine Design ViewImplementation View Process View Components Classes, interfaces, collaborations Active classes Deployment View Nodes Use Case View Use cases

48 © Nabor C. Mendonça 2001 48 III. (R)UP + UML em Detalhes

49 © Nabor C. Mendonça 2001 49 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)

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

51 © Nabor C. Mendonça 2001 51 O Conceito de Iteração (3) n As iterações de maior risco são atacadas 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

52 © Nabor C. Mendonça 2001 52 O Conceito de Iteração (4) -- Risco Potencial Pequeno, no Final --

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

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

55 © Nabor C. Mendonça 2001 55 Características Gerais do Processo n Iterativo e incremental – Grandes atividades (disciplines) de uma iteração Análise Design Implementação Validação: Teste & Integração n Todos os artefatos de análise e design são formalmente descritos usando a linguagem UML

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

57 © Nabor C. Mendonça 2001 57 Características Gerais do Processo (3)

58 © Nabor C. Mendonça 2001 58 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. Inicial a, c, d Notas Elaboração Planeja- mento Construção

59 © Nabor C. Mendonça 2001 59 Fase de Planejamento (2) 1. Plano Inicial (Business Case)

60 © Nabor C. Mendonça 2001 60 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

61 © Nabor C. Mendonça 2001 61 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

62 © Nabor C. Mendonça 2001 62 Fase de Planejamento (5) n Detalhamento das Fases – Iterações (ou definição dos incrementos) n 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...

63 © Nabor C. Mendonça 2001 63 Fase de Planejamento (6) n Modelo do Negócio (ou do Domínio), ou Modelo Conceitual – Principais Entidades ou Conceitos – Relacionamentos entre as Entidades – Um Diagrama de Classe Simplificado

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

65 © Nabor C. Mendonça 2001 65 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 n Atividades típicas de cada iteração: 1. Refinar plano das fases 2. Sincronizar artefatos 3. Análise 4. Design 5. Implementação 6. Teste

66 © Nabor C. Mendonça 2001 66 Fase de Elaboração (3) n 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 n Ciclos com tempo fixo de duas a oito semanas n Vantagens: – Evita complexidade excessiva – Antecipa feedback dos usuários

67 © Nabor C. Mendonça 2001 67 Fase de Construção n 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

68 © Nabor C. Mendonça 2001 68 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

69 © Nabor C. Mendonça 2001 69 Artefatos (2) i = início r = refinamento AtividadesArtefato UML Iteração  Iníc.Elab. E1.E3 AnáliseUse Case ------------------------ Diagrama de Seqüência do Sistema (System Sequence Diagram) ------------------------ Modelo Conceitual ------------------------ Contrato iiiiiiii rrrrrrrr DesignDiagrama de Interação entre Objetos (Object Sequence Diagram; Object Collaboration Diagram) ------------------------ Diagrama de Classe Detalhado i-r

70 © Nabor C. Mendonça 2001 70 Um Pequeno Exemplo Ilustrativo (Parcial) n 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.

71 © Nabor C. Mendonça 2001 71 Exemplo (2) -- Modelo Conceitual..

72 © Nabor C. Mendonça 2001 72 Exemplo (3) -- Diagrama de Interação entre Objetos --

73 © Nabor C. Mendonça 2001 73 Exemplo (4).. Diagrama de Classe --


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

Apresentações semelhantes


Anúncios Google