Baixe o app para aproveitar ainda mais
Prévia do material em texto
1 RUP – Rational Unified Process Franklin Ramalho Universidade Federal de Campina Grande - UFCG SI2-UFCG 2 Agenda - Introdução - RUP - Características - Aspectos estruturais - Aspectos Comportamentais - RUP: Dirigido à Arquitetura - RUP: Dirigido por casos de uso SI2-UFCG 3 RUP • É um processo de engenharia de software • Provê uma técnica disciplinada assinalando tarefas e responsabilidades dentro da organização do desenvolvimento do software • Objetivo: Garantir a produção de software de alta qualidade e que atenda às necessidades do cliente dentro do prazo e custo estabelecidos SI2-UFCG 4 RUP • Trata-se de um processo produto! (by Rational Software) • Integrado com ferramentas de desenvolvimento de software • Trata-se também de um framework de processos – Pode ser estendido – Pode ser adaptado SI2-UFCG 5 RUP • RUP segue muitas das boas práticas de desenvolvimento de software: – Iteratividade – Gerência de requisitos – Arquitetura baseada em componentes – Adota modelos • Modelo para Use-Case; • Modelos de Negócios; • Modelo de Projeto; • Modelos de Análise; • Modelos de Teste. – Verificação da qualidade do software – Controle de mudanças SI2-UFCG 6 RUP • O RUP é um processo de desenvolvimento de software bem elaborado e estruturado, que permite aos gerentes um maior controle sobre o projeto durante toda a sua existência. • O RUP definiu um conjunto de atividades, com seus responsáveis, artefatos de entrada e saída, descrição sistemática e modelos ou templates. 2 SI2-UFCG 7 RUP • O RUP usa a abordagem da orientação a objetos em sua concepção; • É projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação; • Utiliza técnicas e práticas aprovadas comercialmente. SI2-UFCG 8 RUP • Processo iterativo e incremental – Planos de iterações que descrevem o “resultado” (conjunto de artefatos) após cada iteração • Guiado por caso de uso – Definidos de modo a agregar valor – Desde a captura dos requisitos até a realização dos testes do sistema • Baseado na arquitetura do sistema – Artefato para conceituação, construção, gerenciamento e evolução do sistema SI2-UFCG 9 RUP - Aspectos • Arquitetura do RUP: – Eixo horizontal: representa o tempo e mostra o ciclo de vida do processo – Eixo vertical: representa as atividades e workflows do processo • Aspectos estruturais x aspectos dinâmicos SI2-UFCG 10 RUP – Visão geral [Kruchten, 2000] SI2-UFCG 11 RUP – Aspectos estruturais Quem? Workers O quê? Artefatos Como? Atividades Quando? Workflows SI2-UFCG 12 Workers • Define o comportamento e responsabilidades de um indivíduo ou grupo de indivíduos trabalhando em um time • O comportamento é expresso em termos de atividades que o worker executa • As responsabilidades são usualmente expressas através de certos artefatos que o worker cria, modifica e controla • Workers são papéis desempenhados por um indivíduo ou grupo de indivíduos dentro do processo! – Analista, designer, designer de testes, etc. 3 SI2-UFCG 13 Workers [Kruchten, 2000] SI2-UFCG 14 Workers [Kruchten, 2000] SI2-UFCG 15 Atividades • Uma atividade é uma unidade de trabalho que um indivíduo naquele papel deve executar • Produz um resultado significativo no contexto do projeto – Criação ou atualização de artefatos: modelo, classe, plano, etc. • Toda atividade é atribuída para um worker específico • Granularidade: poucas horas a poucos dias • Usualmente envolve um worker e produz poucos artefatos SI2-UFCG 16 Atividades - Exemplos • Planejar uma iteração – Worker: Gerenciador de Projeto • Achar casos de uso e atores – Worker: Analista de sistemas • Revisar o projeto – Worker: Revisor de Projeto • Executar um teste de performance – Worker: Testador de performance SI2-UFCG 17 Artefatos • Trata-se de um pedaço de informação que é produzida, modificada ou usada por um processo • Servem de entrada e saída de atividades • São tangíveis • São usados como entrada pelos workers para executar uma atividade e são também os resultados ou saídas de tais atividades • Sinônimos: work product, work unit SI2-UFCG 18 Artefatos - exemplos • Modelo – Diagrama de casos de uso, diagrama de classes, etc. • Elemento do modelo – Classe, caso de uso, etc. • Documento – Casos de negócio • Código fonte • Executáveis 4 SI2-UFCG 19 Artefatos [Kruchten, 2000] SI2-UFCG 20 Workflows • Workflow é uma seqüência de atividades que produz algum resultado de valor observável • Em UML, um workflow pode ser visto através de: – Diagrama de seqüência – Diagrama de comunicação – Diagrama de atividades – Diagrama de overview de interação SI2-UFCG 21 Workflow [Kruchten, 2000] SI2-UFCG 22 Workflows • Core workflows – Existem 9 core workflows no RUP (6 de engenharia e 3 de suporte) – Particionamento de workers e atividades em grupos lógicos: áreas de interesse e disciplinas. • Workfows details – Quebra core workflows em workflows menores – Maiores detalhes – Atividades relacionadas • Iteration plans – Forma alternativa de representar o processo – Instanciações do processo para uma dada iteração – Pedagógica SI2-UFCG 23 Workflows Workflows de Engenharia de Software Workflows de Suporte [Kruchten, 2000] SI2-UFCG 24 Workflow de modelagem de negócios Entender a estrutura e dinâmica da organização, se certificar que os desenvolvedores, clientes e usuários tenham a mesma visão da organização alvo do desenvolvimento e elicitar os requisitos necessários para suportar o plano ou objetivos da organização. 5 SI2-UFCG 25 Workflow de modelagem de negócios – Worker e artefatos envolvidos [Kruchten, 2000] SI2-UFCG 26 Workflow de modelagem de negócios - Exemplo [Kruchten, 2000] SI2-UFCG 27 Workflow de requisitos Definição dos requisitos do sistema e de como gerenciar escopo e mudanças de requisitos. [Kruchten, 2000] SI2-UFCG 28 Workflow de requisitos - Exemplo [Kruchten, 2000] SI2-UFCG 29 Workflow de análise e projeto Tradução dos requisitos numa especificação que descreve como implementar o sistema (diretriz é usar UML). [Kruchten, 2000] SI2-UFCG 30 Workflow de análise e projeto - Exemplo [Kruchten, 2000] 6 SI2-UFCG 31 Workflow de implementação Desenvolvimento de código: classes, objetos, etc., teste de unidades e integração de subsistemas. [Kruchten, 2000] SI2-UFCG 32 Workflow de implementação - Exemplo [Kruchten, 2000] SI2-UFCG 33 Workflow de testes Verificação do sistema como um todo, com testes de integração e conformidade com os requisitos especificados. [Kruchten, 2000] SI2-UFCG 34 Workflow de testes - Exemplo [Kruchten, 2000] SI2-UFCG 35 Workflow de implantação Empacotamento, distribuição, instalação do produto e treinamento de usuários, assim como o planejamento e condução de testes betas. [Kruchten, 2000] SI2-UFCG 36 Workflow de implantação [Kruchten, 2000] 7 SI2-UFCG 37 RUP – Outros elementos • Diretrizes – Regras, recomendações ou heurísticas para provê suporte em atividades ou artefatos – Descrevem: • Como construir artefatos bem formados, como avaliá-los e como usá-los; • Como usar UML (técnicas de modelagem, como construir diagramas, etc.); • Como programar em linguagens de programação específicas, como C++; • Técnicas para transformações de artefatos, etc. • Templates – Modelos, protótipos ou artefatos– Associados a artefatos para facilitar sua criação – Associados com ferramentas SI2-UFCG 38 RUP – Outros elementos • Tool mentors – Diretrizes sobre como executar os passos a partir de uma ferramenta específica • Conceitos – Conceitos-chaves são introduzidos: iteração, artefato, risco, teste de performance, etc. SI2-UFCG 39 Estrutura dinâmica: Desenvolvimento iterativo • Processo seqüencial apresenta alguns problemas: – Requisitos mudam: • usuários mudam; • o problema muda; • tecnologias mudam; • o mercado muda, etc. – Difícil encontrar o correto projeto de software: corretude, eficiência, usabilidade, etc. • Projetos complexos e a longo prazo. SI2-UFCG 40 Estrutura dinâmica: Desenvolvimento iterativo • Levante alguns requisitos e alguns riscos, projete um pouco, implemente um pouco, valide-os, e então levante mais requisitos, projete mais um pouco, implemente mais, valide, até que você tenha terminado o software. SI2-UFCG 41 RUP – Visão geral [Kruchten, 2000] SI2-UFCG 42 Estrutura dinâmica: Desenvolvimento iterativo [Kruchten, 2000] 8 SI2-UFCG 43 Estrutura dinâmica: Desenvolvimento iterativo • Processo iterativo não é simples de se implantar: – Como fazer o trabalho convergir para um produto? – Como determinar o que fazer em cada iteração? – Quais requisitos e riscos considerar em cada iteração? – Como resolver os problemas do processos seqüenciais? • RUP responde estas questões SI2-UFCG 44 RUP • Milestones : Provê pontos a partir dos quais deve-se decidir como proceder, abortar ou mudar o rumo das tarefas • O processo iterativo é organizado em fases – Cada fase é concluída através de um milestone [Kruchten, 2000] SI2-UFCG 45 RUP – Ciclo de vida do processo • Fases do ciclo de vida do processo : – Concepção: entendimento da necessidade e visão do projeto (ênfase no escopo do sistema) – Elaboração: especificação e abordagem dos pontos de maior risco (ênfase na arquitetura) – Construção: desenvolvimento principal do sistema (ênfase no desenvolvimento) – Transição: ajustes, implantação e transferência de propriedade do sistema (ênfase na implantação) • Sistema beta disponível SI2-UFCG 46 RUP – Ciclo de vida do processo • As quatros fases constituem um ciclo de desenvolvimento e produz uma geração de software • Um produto de software é criado a partir do ciclo de desenvolvimento inicial • O produto evolui através das próximas gerações de software através da repetição da seqüência das quatros fases: Concepção, elaboração, construção e transição – Formam os ciclos de evolução SI2-UFCG 47 RUP – Ciclo de vida do processo [Kruchten, 2000] SI2-UFCG 48 RUP – Ciclo de vida do processo • Diferentes ênfases das várias atividades através do tempo • Fase de concepção: foco no entendimento geral dos requisitos • Fase de elaboração: foco ainda nos requisitos, mas já com atividades de projeto, e implementação de protótipos (para validar a arquitetura) – Aprender algumas técnicas e ferramentas, levantar riscos • Fase de construção: Foco no projeto e implementação – Protótipo inicial evolui para primeiro produto operacional • Fase de transição: garantir o nível de qualidade – Corrigir bugs, treinar usuários, ajustar características e adicionar elementos ausentes. – Produz e libera o produto final. 9 SI2-UFCG 49 RUP – Ciclo de vida do processo [Kruchten, 2000] SI2-UFCG 50 RUP – Fase de Concepção • Atividades essenciais: – Definir o escopo do projeto (contexto, requisitos, restrições, etc.); – Planejar e preparar casos de negócio e alternativas de avaliação para gerenciamento de riscos; – Produzir uma arquitetura candidata. • Artefatos produzidos: – Survey do modelo de casos de uso; – Glossário inicial do projeto; – Caso de negócio inicial (contexto, critérios de sucesso, reconhecimento do mercado, etc); – Estabelecimento de riscos iniciais; – Plano de projeto (fases, iterações). SI2-UFCG 51 RUP – Fase de Elaboração • Atividades essenciais: – Entender solidamente os casos de uso mais críticos; – Elaborar o processo, a infra-estrutura e o ambiente de desenvolvimento; – Elaborar a arquitetura; – Selecionar/avaliar os componentes. • Artefatos produzidos: – Modelo de casos de uso (80% completo); – Requisitos complementares (não funcionais, não associados com os casos de uso, etc.); – Descrição da arquitetura de software; – Protótipo arquitetural executável; – Listas de riscos e de casos de negócios revisadas; – Plano de desenvolvimento (incluindo iterações e critérios de avaliação para cada iteração); – Manual do usuário preliminar. SI2-UFCG 52 RUP – Fase de Construção • Atividades essenciais: – Desenvolver todos os componentes; – Testar componentes; – Verificar e atestar releases do produto. • Artefatos produzidos: – Produto de software adequado às plataformas de execução; – Manuais do usuário; – Descrição da release corrente. SI2-UFCG 53 RUP – Fase de Transição • Atividades essenciais – Empacotar produto comercialmente; – Lançar produto no mercado; – Treinar pessoal; – Corrigir bugs; – Realizar testes beta; – Melhorar performance e usabilidade; – Verificar critérios de aceitação do produto. • Aqui, se decide se um novo ciclo de desenvolvimento deve ser iniciado. SI2-UFCG 54 Time aprende ao longo das iterações Produto com mais qualidade Mudanças mais fáceis de serem gerenciadas Maior grau de reuso Identificação de riscos mais cedo Processo Iterativo Benefícios da técnica iterativa 10 SI2-UFCG 55 RUP • É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala. SI2-UFCG 56 Exercícios • Como integrar UML com RUP? Quem? Workers O quê? Artefatos Como? Atividades Quando? Workflows SI2-UFCG 57 Exercícios • Como integrar UML com RUP? [Kruchten, 2000] SI2-UFCG 58 RUP SI2-UFCG 59 RUP SI2-UFCG 60 RUP – Visão geral [Kruchten, 2000] 11 SI2-UFCG 61 RUP – Ciclo de vida do processo • Fases do ciclo de vida do processo : – Concepção: entendimento da necessidade e visão do projeto (ênfase no escopo do sistema) – Elaboração: especificação e abordagem dos pontos de maior risco (ênfase na arquitetura) – Construção: desenvolvimento principal do sistema (ênfase no desenvolvimento) – Transição: ajustes, implantação e transferência de propriedade do sistema (ênfase na implantação) • Sistema beta disponível SI2-UFCG 62 RUP – Fase de Elaboração • Atividades essenciais: – Entender solidamente os casos de uso mais críticos; – Elaborar o processo, a infra-estrutura e o ambiente de desenvolvimento; – Elaborar a arquitetura; – Selecionar/avaliar os componentes. • Artefatos produzidos: – Modelo de casos de uso (80% completo); – Requisitos complementares (não funcionais, não associados com os casos de uso, etc); – Descrição da arquitetura de software; – Protótipo arquitetural executável; – Listas de riscos e de casos de negócios revisadas; – Plano de desenvolvimento (incluindo iterações e critérios de avaliação para cada iteração); – Manual do usuário preliminar. SI2-UFCG 63 RUP – Processo dirigido à Arquitetura • RUP foca em modelos • Nenhum modelo específico cobre todos os aspectos do sistema • Precisa-se de múltiplos modelos – Sincronização é essencial • Muitos modelos dificultam o entendimento geral do sistema – Abstração necessária SI2-UFCG 64 RUP – Processo dirigido à Arquitetura• Foco na arquitetura: – Entendimento da proposta – Representação arquitetural – Processo arquitetural • RUP é focado na arquitetura do sistema SI2-UFCG 65 RUP – Processo dirigido à Arquitetura • Arquitetura deve cobrir importantes decisões sobre: – Organização do sistema; – Elementos estruturais e suas interfaces; – Decomposição destes elementos em subsistemas; – Colaboração com outros subsistemas. • Arquitetura foca na estrutura, comportamento e contexto. SI2-UFCG 66 RUP – Processo dirigido à Arquitetura • Partes interessadas na arquitetura: – Analista de sistemas; – Usuários e clientes; – Gerente de projeto; – Projetistas de software; – Outras organizações de desenvolvimento (interfaces); – Arquitetos. • Representação da arquitetura é necessária – Com diferentes visões! 12 SI2-UFCG 67 RUP – Arquitetura de 5 visões [Kruchten, 2000] SI2-UFCG 68 RUP – Arquitetura de 5 visões • Modelos versus Visões • Visões arquiteturais são como fatias sobre os vários modelos capturando os elementos significativos para cada visão • Elementos importantes na arquitetura: – Classes principais; – Mecanismos de persistência e comunicação para estas classes; – Padrões e frameworks; – Camadas e subsistemas; – Interfaces; – Processos principais, threads e controle. SI2-UFCG 69 RUP – Processo dirigido à Arquitetura • RUP define dois artefatos relacionados com a arquitetura: – Software Architecture Description (SAD); – Protótipo da arquitetura. • Estes artefatos servem de base para 3 outros: – Diretrizes de projeto; – Estrutura do produto no ambiente de desenvolvimento; – Estrutura do time. • RUP define o Worker: Arquiteto – Outros membros do time também são responsáveis pela elaboração da arquitetura: projetistas, integradores, testadores, etc. SI2-UFCG 70 RUP SI2-UFCG 71 RUP – Processo dirigido à Casos de uso • RUP foca em modelos • Modelos do problema x Modelos da solução • Primeiro precisa-se entender o problema • Como entender e modelar o problema? • RUP determina a adoção de casos de uso! SI2-UFCG 72 RUP – Processo dirigido à Casos de uso • Para se construir um modelo de caso de uso deve-se entender: – Casos de uso – Atores • Um caso de uso define o que o sistema deve fazer quando um caso de uso for executado • Uma funcionalidade do sistema é definida por um conjunto de casos de uso, cada um representando um fluxo de eventos específico 13 SI2-UFCG 73 Casos de Uso • Um caso de uso especifica o comportamento de um sistema ou parte do sistema – Descreve um conjunto de seqüência de ações • Servem para captar comportamento pretendido do sistema – Sem implementá-lo! – Facilita comunicação • Você deve pensar nas várias formas como o sistema será usado – Orientam a arquitetura SI2-UFCG 74 Casos de Uso • Um caso de uso representa um requisito funcional de todo o sistema – Serviços, tarefas ou funções oferecidas pelo sistema – Ex: Emitir um relatório, realizar cadastro, realizar consultas, etc. • São muito úteis para tarefas de V&V • Definição: um caso de uso descreve um conjunto de seqüência de ações cada um representando a interação de itens externos ao sistema (seus atores) com o próprio sistema (e suas principais abstrações). SI2-UFCG 75 Diagrama de caso de uso ReceberChamada Usuário ReceberMensagem Jogar TelefoneCelular SI2-UFCG 76 Casos de Uso pedirEmpréstimo Cliente do banco Ator Caso de Uso SI2-UFCG 77 Fluxo de Eventos • Um caso de uso descreve o que um sistema (subsistema, classe ou interface) faz, não como ele é feito • O Comportamento de um caso de uso pode ser especificado através de fluxo de eventos – Como e quando o caso de uso inicia e termina – Quando o caso de uso interage com atores – Quais objetos são transferidos – Fluxo básico de comportamento – Fluxo alternativo de comportamento • Ajuda a entender o sistema SI2-UFCG 78 Fluxo de Eventos • São descritos através: – Linguagem natural – Pré e pós-condições – Máquinas de estados – Diagrama de atividades – Diagramas de seqüência – Pseudo-código 14 SI2-UFCG 79 RUP – Processo dirigido à Casos de uso • RUP determina a elaboração de modelos de casos de uso: conjunto de todos os casos de uso para o sistema juntamente com todos os atores que interagem com o sistema, descrevendo assim, a completa funcionalidade do sistema. • RUP prescreve UML para especificar modelos de casos de uso – Diagramas de casos de uso • Mais informações ver aula sobre diagramas de casos de uso! SI2-UFCG 80 Fluxo de Eventos • Em geral, cada processo de software prescreve um conjunto de seções que deverão aparecer no fluxo de eventos. Por exemplo: – Nome – Identificador – Descrição – Objetivo – Pré-condições – Pós-condições – Fluxo principal de ações – Fluxo alternativo de ações SI2-UFCG 81 Fluxo de Eventos - Exemplo – Nome: Matricular aluno em disciplina – Identificador: UC 15 – Pré-condições: O aluno estar logado no sistema como aluno do curso de Ciência da Computação da UFCG – Pós-condições: O aluno estar matriculado na(s) disciplina(s) selecionad(a)s. – Fluxo Principal: 1. O aluno seleciona no menu a opção de matricular-se em disciplina(s). 2. O sistema fornece a lista de disciplina(s) para o aluno matricular-se. 3. O aluno escolhe em qual(is) disciplina(s) deseja matricular-se. 4. O sistema verifica que o aluno cumpriu os pré-requisitos de todas as disciplinas escolhidas. [FAA] 5. O sistema indica que o aluno está apto para matricular-se na(s) disciplina(s) selecionada(s). 6. O sistema pergunta se o aluno deseja um comprovante impresso da matrícula. 7. O aluno indica que deseja uma cópia impressa de matrícula. 8. O sistema imprime o comprovante de matrícula do aluno. SI2-UFCG 82 Fluxo de Eventos - Exemplo – Fluxo Alternativo A [FAA]: O aluno não cumpriu os pré-requisitos da disciplina B.4 O sistema verifica que o aluno não cumpriu os pré-requisitos de alguma disciplina escolhida. B.5 O sistema informa ao aluno que ele não cumpriu os pré-requisitos de alguma(s) disciplina(s) escolhida(s) e, portanto, não está apto a matricular-se nesta(s) disciplina(s). B.6 O sistema volta ao passo 2 do fluxo principal. SI2-UFCG 83 RUP – Processo dirigido à Casos de uso • Em RUP: – Casos de uso definidos para o sistema são a base para todo o processo de desenvolvimento – Casos de uso surgem como linguagem para comunicação entre o cliente ou usuário e o time de desenvolvimento – O modelo de casos de uso é o resultado do workflow de requisitos SI2-UFCG 84 RUP – Visão geral [Kruchten, 2000] 15 SI2-UFCG 85 Workflow de requisitos Definição dos requisitos do sistema e de como gerenciar escopo e mudanças de requisitos. [Kruchten, 2000] SI2-UFCG 86 Workflow de requisitos - Exemplo [Kruchten, 2000] SI2-UFCG 87 RUP – Processo dirigido à Casos de uso [Kruchten, 2000] Casos de uso ajudam a sincronizar o conteúdo de vários modelos ao longo dos workflows core de RUP SI2-UFCG 88 Referência • [Kruchten, 2000] Kruchten, Philippe. The Rational Unified Process – An Introduction. Second Edition, 2000. Addison, Wesley.
Compartilhar