RUP Unified Process ( Rational Unified Process ( Processo Unificado de Desenvolvimento da Rational)
RUP - Rational Unified Process Rômulo César FACULDADE DOS GUARARAPES.
Transcript of RUP - Rational Unified Process Rômulo César FACULDADE DOS GUARARAPES.
RUP - Rational Unified RUP - Rational Unified ProcessProcess
Rômulo César
FACULDADE DOS
GUARARAPES
ObjetivosObjetivos
Introdução◦Características Principais do RUP
Fases & Ciclo de VidaDisciplinas Básicas e de ApoioFramework
◦Descrição de Atividades ◦Artefatos◦Guias
Introdução ao RUPIntrodução ao RUP
Tendências...Tendências...Necessidade de sistemas cada vez
maiores e mais complexos.Necessidade por Sofisticação
◦ Sistemas cada vez mais adaptados às necessidades dos usuários
◦ Inclusão de melhoramento substanciais a cada versão
Exigência de rapidez no desenvolvimento◦ Competitividade de mercado.
Necessidades Necessidades Um processo integrado que:
◦Provenha guias◦Direcione as tarefas ◦Especifique os artefatos ◦Ofereça ferramentas e métodos◦Apresente critérios para monitorar e
medir o produto e processo
“A presença de um bem definido e bem gerenciado processo é o elemento que diferencia os projetos produtivos dos projetos mal sucedidos” (Booch et al, 1999)
Processo UnificadoProcesso UnificadoFramework genérico e adaptável à
uma grande classe de sistemasBaseado em componentes
◦ interconectados por interfaces bem definidas.
Integrado a linguagem UMLAspectos Diferenciais:
◦Direcionado por Casos de Uso◦Centrado em Arquitetura◦Iterativo e Incremental
Histórico do RUPHistórico do RUP
Abordagem da Ericsson
Objectory Process 1.0 - 3.81987-1995
UML
Abordagem da Rational
IBM - Rational Unified Process
Rational Objectory Process 4.11996-1997
Rational Unified Process 5.0
Outras fontes
Práticas e Conceitos ChavesPráticas e Conceitos Chaves
Modelagem VisualModelagem VisualIterativo e IncrementalIterativo e Incremental
Dirigido do Casos de UsoDirigido do Casos de UsoCentrado em ArquiteturaCentrado em Arquitetura
Modelagem VisualModelagem VisualPorque Modelar ?Porque Modelar ?
Um modelo é uma visão simplificada do sistema. Mostra a essência do sistema sobre uma perspectiva particular e esconde detalhes não essenciais.
Serve para◦ Aumentar o entendimento de sistemas
complexos◦ Explorar e comparar diferentes projetos ◦ Formar uma base para implementação◦ Capturar os requisitos precisamente◦ Comunicar as decisões de forma não-ambígua.
Modelagem VisualModelagem VisualUMLUMLUso de notações gráficas e textuais
semanticamente ricas para capturar elementos do projeto de software
Permite o nível de abstração ser aumentado, preservando uma sintaxe e semântica rigorosa
Iterativo-IncrementalIterativo-Incremental
11
R1
R2
R5
R3R
4R7
R6
R1
R2
R5
R3R
4R7
R6
It.1
It.2It.3
Definição inicial de requisitos
Planejamento de iterações
Desenvolvimento de iteração N
Validação com usuário da it. N
Plano iteração N
O desenvolvimento ocorre em várias iterações, cada uma resultando em incrementos de funcionalidades do sistema.
Iterativo e IncrementalIterativo e IncrementalBenefíciosBenefícios
Análise antecipada de riscos com a integração progressiva do sistema
Melhor acomodação de solicitações de mudanças
Maior qualidade devido ao refinamento contínuo do produto
Melhor facilidade de aprendizagem e amadurecimento do processo
Aumento da reusabilidade
Iterativo x cascataIterativo x cascata
Disciplinas das IteraçõesDisciplinas das IteraçõesBásicasBásicas
Requisitos (requirements)
Análise & Projeto (analysis &
design)
Implementação (implementation)
Teste (tests)
Implantação (deployment)
Disciplinas das IteraçõesDisciplinas das IteraçõesDe ApoioDe Apoio
Ger. Projeto (Project management)
Ger. de Ambiente (Environment)
Ger. de Configuração e Mudança
(Configuration and change
management)
Integração entre as Disciplinas
Fonte: Rational
Iterações no RUP
Fonte: Rational
Processo Processo Dirigido por Casos de UsoDirigido por Casos de Uso
Casos de Uso são utilizados para conduzir todo o processo de software.
Serve de base para a geração e integração dos diversos modelos e artefatos produzidos em todas as etapas do processo
Diagrama de Casos de Uso Diagrama de Casos de Uso
Casos de Uso Casos de Uso Especificação (Pro.Net) Especificação (Pro.Net)
Nome do requisito [RFXX001] Prioridade: (Essencial, Importante, Desejável)Ator(es)Requisitos associadosDescrição:
◦ Explicação do propósito do caso de uso◦ Desenhos ou rascunhos das telas da aplicação, ou
captura das telas dos protótiposPré-condições:
◦ Estado em que a aplicação deve estar ou um fator externo necessário para que o caso de uso possa ser realizado
Pós-condições: ◦ Lista de possíveis estados em que a aplicação pode ficar
imediatamente após o término da execução do caso de uso, ou alteração de um fator externo à aplicação.
Casos de UsoCasos de UsoEspecificação (Pro.Net) Especificação (Pro.Net)
Fluxo principal◦ Descreve passo a passo o que os atores e a aplicação
fazem.◦ Especifica se este Caso de Uso inclui ou estende outro.◦ Faz referência a um fluxo alternativo ou de erro caso
haja necessidade devido a alguma condição.Fluxos alternativos
◦ [FA 001] <Descreve uma seqüência que foge ao fluxo principal descrito, mas que não é um erro.>
Fluxos de erro◦ [FE 001] <Descreve os passos a serem seguidos para
cada situação de erro identificada (ex: consulta a dados que deveriam estar no banco, falha na comunicação via rede etc.)>
Casos de Uso Casos de Uso são usados para ...são usados para ...
Modelar o processo do negócioEspecificar requisitosPlanejar iteraçõesRealizar os modelo de projetoImplementar os componentes e seus
casos de testeDescrição dos manuais e/ou
procedimentos de uso e instalação
Arquitetura de Arquitetura de SoftwareSoftware
Proporciona uma perspectiva mais clara do sistema.◦ Melhor compreensão e organização do
sistema◦ Base sólida para o desenvolvimento
Descreve a estrutura de como os requisitos devem ser implementados
“Uma arquitetura de software (em algum ponto no tempo) é uma organização ou estrutura de componentes que interagem entre si através de interfaces”.
IEEE
Estrutura de Estrutura de CamadasCamadas
ComponentesComponentesParte encapsulada do sistema.
◦não trivial, com certa independência e passível de substitução que satisfaz uma clara funcionalidade
Oferecem interfaces bem-definidas que permitem prover e esconder serviços e informações.
Diferentes Visões Diferentes Visões de uma de uma ArquiteturaArquitetura
Visão da estrutura do sistema sobre o ângulo de stakeholders específicos ◦usuários, analistas, desenvolvedores,
etc.Visões Típicas
◦Visão de Casos de Uso◦Visão Lógica◦Visão de Implementação◦Visão de Processo◦Visão de Implantação
Visão de Casos de Visão de Casos de UsoUso
Conjunto de Casos de Uso que englobam comportamentos e riscos que devem ser levados em consideração pela arquitetura.
Visão LógicaVisão Lógica Classes de projeto mais importantes e
sua organização em pacotes e subsistemas, que por sua vez são estruturados em camadas.
Demais Visões Demais Visões Típicas Típicas
Visão de Implementação: ◦ organização dos módulos em pacotes e
camadas.Visão de Processos:
◦ descrição das threads (linhas de execução) e suas interações e configurações.
◦ Necessária quando existe alto grau de concorrência.
Visão de Implantação: ◦ descrição dos nós físicos (hardwares) para as
configurações de plataforma
RUP: Um Processo RUP: Um Processo Centrado em Arquitetura Centrado em Arquitetura de Softwarede Software“ RUP oferece uma forma metodológica de
projetar, desenvolver e validar uma arquitetura”Arquitetura é construída através de refinamentos
sucessivos◦ Inicia-se com um protótipo de arquitetura
executável e gradualmente se torna um sistema.
Serve para demonstrar funções específicas ◦ Em particular aquelas que satisfazem
requisitos não funcionais.Serve para analisar riscos
◦ Relacionados a desempenho, capacidade, confiabilidade, entre outros.
Importância de uma Importância de uma Arquitetura Arquitetura
Auxilia no gerenciamento da complexidade do projeto e na manutenção de sua integridade
Garante manutenabilidade e aderência a requisitos não funcionais
Base efetiva para o reuso em larga-escala
Guia para a gerência de projeto