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

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

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

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

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

Imprecisão dos Requisitos Estudo publicado por Capers Jones em 1987, baseado em 6.700 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

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

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

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 …

Portanto...

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

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

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

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

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

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!

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

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

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.

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

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”

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

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

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

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

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)

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

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

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

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

O Conceito de Iteração (6)

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

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

Características Gerais da Metodologia (3)

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

-- 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?

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