Índice
1 O Processo Unificado da Rational_______________________________________ 4 2 Os Três Principais Aspectos do RUP _____________________________________ 6
2.1 Processo Guiado pelos Casos de Uso________________________________________ 6 2.2 Processo Centrado na Arquitetura _________________________________________ 7 2.3 Processo Iterativo e Incremental___________________________________________ 8
3 O Ciclo de Vida do RUP _______________________________________________ 9
3.1 A Dimensão do Tempo __________________________________________________ 10 3.2 A Dimensão Estática____________________________________________________ 12
Lista de Figuras
FIGURA 1: O MODELO DE CASOS DE USO É SUPORTADO POR TODOS OUTROS MODELOS NO RUP. ...7
FIGURA 2: ATIVIDADES DE UMA ITERAÇÃO NO DESENVOLVIMENTO ITERATIVO E INCREMENTAL...9
FIGURA 3: O CICLO DE VIDA DO RUP...10
FIGURA 4: A DIMENSÃO DO TEMPO DO RUP...13
FIGURA 5: MAPEAMENTO ENTRE CORE WORKFLOWS E MODELOS...16
1 O Processo Unificado da Rational
O Processo Unificado da Rational (RUP – Rational Unified Process) é o produto final de três décadas de desenvolvimento e usos práticos de técnicas bem sucedidas. Seu desenvolvimento tem sido influenciado por várias fontes, como principal exemplo, tem-se a técnica de detem-senvolvimento utilizada pela Ericsson em 1967.
A equipe de desenvolvimento da Ericsson modelou um grande sistema como um conjunto de blocos interconectados (denominados agora, na UML – Unified Modeling
Language, de subsistemas e implementados como componentes). Eles combinaram
blocos de nível mais baixo em subsistemas, de forma a tornar o sistema mais administrável. Os blocos foram encontrados através de estudos realizados em situações de usos dos sistemas, agora chamados de casos de uso na UML. Conhecendo as responsabilidades de cada bloco, especificações para eles foram definidas. Nesta atividade de projeto, diagramas estáticos dos blocos com usas interfaces e o agrupamento dos mesmos em subsistemas foram realizados. Estes diagramas estáticos de blocos são relativos aos diagramas de classes e pacotes na UML. Um dos primeiros trabalhos realizados foi a descrição da arquitetura do sistema atendendo aos requisitos mais críticos. Em essência, a técnica usada é a que hoje chama-se de Desenvolvimento Baseado em Componentes.
O caminho do desenvolvimento da RUP iniciou-se com a primeira versão do processo Objectory em 1987, seguiu como o Processo Objectory da Rational (ROP – Rational Objectory Process) em 1997, onde passou a se chamar Processo Unificado da Rational em 1998.
O processo Objectory surgiu em 1987 quando Ivar Jacobson deixou a Ericsson e
fundou a Objectory AB em Estocolmo na Suécia. Ele definiu formalmente a técnica utilizada pela Ericsson para levantamento e agrupamento dos requisitos em funcionalidades e chamou este conceito de funcionalidades de Casos de Uso. Ele definiu um série de fluxos de trabalhos (workflows): casos de uso dos requisitos, análise, projeto, implementação e teste; e observou que todas as outras etapas eram guiadas pela primeira, Casos de Uso, pois, é onde se define os requisitos de todo o sistema.
Em 1995, a Rational Software Corporation comprou a Objectory AB e passou a unificar os princípios básicos e a melhores práticas envolvidas nos dois processos de desenvolvimento. Como exemplos, têm-se os conceitos de projeto orientado a objetos, abstração, encapsulamento, reutilizabilidade e a prototipagem. Em 1996, Grady Booch publicou dois princípios sobre arquiteturas e iterações nos desenvolvimentos de sistemas: o desenvolvimento de grandes sistemas deveria ser guiado também pela arquitetura e um processo orientado a objetos de sucesso deveria aplicar um processo iterativo e incremental. O Processo Objectory da Rational (ROP – Rational Objectory
Process) surgiu como resultado da melhoria do processo Objectory. Este novo processo procurava melhorar aspectos do desenvolvimento que o antigo processo falhava, como exemplo: a definição das atividades para gerência de requisitos e configuração, implantação do sistema e preparação do ambiente de desenvolvimento; a inclusão da técnica de desenvolvimento iterativo e incremental que permite a repetição de todas as atividades do desenvolvimento e o ataque programado e controlado dos risco do projeto; e a inclusão do desenvolvimento da arquitetura do sistema como parte integrante e fundamental para o sucesso de um processo de desenvolvimento baseado na composição de partes menores e reutilizáveis. Paralelamente, a UML (Unified Modeling
Language) foi desenvolvida pela própria Rational e usada como linguagem de
modelagem do ROP.
Durante os anos de desenvolvimento do processo da Rational, ela comprou ou associou-se a outras empresas que trouxeram experiências e ferramentas em áreas que eram deficitárias no seu processo. Desta forma, o processo foi expandido com uma nova atividade para modelagem de negócio que é usada para derivar os requisitos do mundo real, aqui houve a introdução da técnica de cenários elaborada por James Rumbaugh. O processo também foi expandido para permitir o projeto de interfaces do usuário guiadas pelos casos de uso. Assim, em 1998, o ROP tornou-se um processo capaz de suportar todo o ciclo de vida de software e teve o seu nome alterado para Processo Unificado da Rational dando ênfase a unificação de várias tecnologias.
Em 2002, a empresa Rational foi comprada pela IBM, incorporando também o Rational Unified Process.
2 Os Três Principais Aspectos do RUP
O RUP é mais que um processo, ele é um framework genérico de processo que pode ser especializado para uma grande classe de sistemas de software, para diferentes áreas, diferentes tipos de organizações, diferentes níveis de competência e diferentes tamanhos de projeto [USDP].
Este processo permite a construção de sistemas a partir da combinação de componentes pre-existentes interconectados através de interfaces bem definidas. Ele utiliza a UML como linguagem para modelagem e documentação dos artefatos gerados nas diversas atividades. Em [USDP], a UML é apontada como parte integrante do RUP.
O RUP define e segue três aspectos importantes do processo de desenvolvimento de software e são: o processo deve ser guiado pelos Casos de Uso, deve ser centrado na Arquitetura e, Iterativo e Incremental. Estes aspectos serão melhores definidos a seguir.
2.1 Processo Guiado pelos Casos de Uso
Um software é construído para servir aos usuários. Desta forma, para se construir um software de sucesso, os analistas devem descobrir e atender aos requisitos dos usuários através das funcionalidades do sistema. Na UML, os papéis que os usuários desempenham nas interações com o sistema são chamados de atores. Um caso de uso é uma porção da funcionalidade solicitada, que permite aos atores desenvolverem uma tarefa de valor. Resumindo, os casos de uso capturam os requisitos funcionais e todos eles juntos descrevem a completa funcionalidade do sistema.
Desta forma, os casos de uso contêm as principais informações necessárias para todo o restante do desenvolvimento. Logo, eles guiam a construção de todos os outros artefatos ou, simplesmente, todos os outros artefatos são desenvolvidos para suportá-los, como pode ser observado no Figura 1. Outros documentos importantes podem ser o documento de visão, que dá a visão geral do sistema requerido pelos clientes, e a especificação suplementar, que indica os requisitos não funcionais da aplicação.
Figura 1: O Modelo de Casos de Uso é suportado por todos outros modelos no RUP.
2.2 Processo Centrado na Arquitetura
O papel da arquitetura é fornecer uma visão geral do sistema antes da construção propriamente dita. A arquitetura envolve os aspectos dinâmicos e estáticos mais importantes. A arquitetura se desenvolve principalmente a partir de requisitos definidos pelos usuários nos casos de uso, mas sofrem fortes influências de vários outros fatores, como: plataforma (arquitetura dos computadores, sistemas operacionais, protocolos de comunicação etc), componentes reusáveis, sistemas legados, requisitos não funcionais, etc.
A arquitetura é descrita através das diferentes visões do sistema: uma visão do modelo de casos de uso, uma visão do modelo de projeto, uma visão do modelo de distribuição (física), uma visão do modelo de componentes e uma visão do modelo de processos. Porém, estas visões apresentam somente os elementos que são importantes para a descrição da arquitetura, os outros detalhes são simplesmente omitidos.
Todo produto de software possui o modelo de casos de uso e a arquitetura. O primeiro representa a parte funcional e o segundo a forma do sistema. Assim, os casos de uso são restringidos ou suportados pela arquitetura, enquanto a arquitetura é construída ou alterada para permitir a construção dos casos de uso. Logo, o modelo de casos de uso e a arquitetura estão altamente relacionados e devem ser desenvolvidos paralelamente, de forma, que todos os requisitos sejam atendidos satisfatoriamente.
2.3 Processo Iterativo e Incremental
Desenvolver um software é uma grande empreitada que pode demorar meses ou anos. Segundo [USDP], é prático dividir o trabalho em partes menores ou mini-projetos. Cada mini-projeto é uma iteração que resulta num incremento, ou seja, é a repetição de um conjunto de atividades que gera um acréscimo de funcionalidade ao sistema. Entretanto, nem todo incremento é aditivo em termos de funcionalidade, ele pode simplesmente substituir um projeto superficial por um mais detalhado e isto acontece normalmente nas fases iniciais do sistema.
Numa definição mais formal para iteração, pode-se dizer que é uma seqüência de atividades com um plano estabelecido e um critério de avaliação, resultando numa versão executável. Logo, para serem efetivas, as iterações devem ser controladas, isto é, selecionadas cuidadosamente e realizadas de forma bem planejada. E, por isso, são chamadas de mini-projetos. A decisão do que deve ser implementado em cada iteração baseia-se em dois fatores: a escolha de um grupo de casos de uso que juntos devem estender a funcionalidade do sistema e quais riscos, normalmente os mais comprometedores, devem ser tratados em primeiro lugar. Iterações sucessivas devem desenvolver os artefatos a partir do estado onde foram deixados por iterações anteriores. Na figura 2, a representação genérica para iteração é apresentada. Primeiro, o levantamento dos riscos deve ser realizado e o escopo do sistema delimitado. Uma iteração deve sempre atacar os riscos mais altos existentes, definindo cenários para tratá-los. Em seguida, um planejamento sobre as atividades a serem realizadas e os recursos disponíveis é elaborado. Este plano é desenvolvido e avaliado. Se não
existirem mais riscos o desenvolvimento está concluído. Caso ainda existam riscos, estes são analisados e um novo plano para o projeto é realizado.
Figura 2: Atividades de uma Iteração no Desenvolvimento Iterativo e Incremental.
Como vantagens do desenvolvimento iterativo e incremental, têm-se que os riscos mais comprometedores são atacados primeiro e que, em casos de falhas, o sistema pode ser interrompido nas fases iniciais sem uma grande perda de tempo e investimento; e que uma porção do sistema pode ser desenvolvida e entregue enquanto uma outra parte do mesmo ainda está em desenvolvimento.
3 O Ciclo de Vida do RUP
O RUP foi idealizado em duas dimensões:• eixo horizontal representa o tempo e mostra os aspectos dinâmicos: ciclos,
fases, iterações e marcos;
• eixo vertical representa o aspecto estático: atividades, artefatos, papeis e
Na figura 3, o clico de vida do RUP é apresentado graficamente e será detalhado a seguir.
Figura 3: O ciclo de vida do RUP.
3.1 A Dimensão do Tempo
O eixo horizontal representa o tempo por que uma vez finalizada uma etapa, ela não mais é mais retornada. Ele é constituído de ciclos, fases, iterações e marcos.
Um ciclo representa todo o desenvolvimento de uma versão de um produto. Por exemplo, para o Microsoft Word, existiria todo um ciclo de desenvolvimento para a versão 95, outro para a versão 97 e outro para a versão 2000. Cada ciclo é dividido em quatro fases consecutivas.
As fases são momentos dentro de um ciclo de desenvolvimento do produto. As quatro fases são Concepção, Elaboração, Construção e Transição.
A fase Concepção visa delimitar o escopo do projeto e estudar a viabilidade do
• contexto do sistema solicitado é compreendido; • escopo do projeto é delimitado;
• uma arquitetura inicial é descrita;
• os riscos críticos são identificados e atacados; e
• uma solução inicial para o problema (protótipos) é apresentada.
A fase Elaboração consiste em planejar o projeto, especificar a características e
construir a arquitetura base. As tarefas que se destacam são:
• uma arquitetura estável é criada;
• os riscos sobre os planos e os custos são identificados;
• cronograma de execução de tarefas, os níveis de qualidade e de segurança, e
os tempos de respostas são definidos;
• os casos de uso que representam 80% dos requisitos são identificados, isto por
que outros casos de uso podem surgir nas fases seguintes; e
• os recursos humanos necessários são alocados.
Já a fase Construção consiste na construção propriamente dita ou implementação
do produto. As principais tarefas são:
• a identificação, descrição e realização dos casos de uso são finalizadas; • análise e projeto são finalizados;
• implementação e 90% dos testes são realizados;
• a integridade da arquitetura é mantida, modificando-a quando necessário; e • os riscos críticos são monitorados.
A fase Transição consiste na entrega do produto. As atividades mais importantes
são:
• as versões beta são preparadas; • ambiente de operação é configurado; • os manuais são preparados;
• os treinamentos dos usuários são realizados; e • os defeitos encontrados são corrigidos.
Todas estas fases podem ainda serem quebradas em iterações. Iterações foram definidas no Item 2.3 e podem ser vistas como um laço repetitivo de atividades. Estas atividades são os core workflows vistos na Figura 3 e explicados mais abaixo.
Os Marcos são pontos no tempo no quais certas decisões críticas devem ser tomadas e que os objetivos-chave planejados devem ter sido alcançados. Como exemplo de marcos, têm-se:
• para o fim da fase Concepção, tem-se a construção do documento de visão do
sistema;
• para o fim da fase Elaboração, tem-se a definição da arquitetura base;
• para o fim da fase Construção, tem-se a primeira versão operacional completa
do produto;
• para o fim da fase Transição, tem-se o produto concluído; e • para o fim de cada iteração, tem-se um protótipo.
Veja na Figura 4, o resumo da dimensão do tempo.
3.2 A Dimensão Estática
O eixo vertical do processo RUP é chamado de estático por que sempre é repetido no tempo, isto é, em qualquer momento do desenvolvimento.
Segundo [USDP], um processo deve descrever “quem” está fazendo “o que”, “como” e “quando”. No RUP, o “quem” é representado pelos papéis que as pessoas assumem no processo. Estes papeis definem o comportamento e as responsabilidades de um indivíduo ou de um grupo de indivíduos. O “como” é representado pelas atividades. As atividades são unidades de trabalho que um indivíduo em um papel deve realizar. O “o que” é representado pelos artefatos e estes são os produtos tangíveis do projeto, por exemplo: modelos, diagramas e documentos. O “quando” é representado pelos
algum resultado de valor. Os Core Workflows são fluxos de trabalho básicos definidos no framework da Rational e servem de guia para criação de um processo de desenvolvimento adaptado a cada empresa. Pode-se observar, na figura 3, a existência de nove core workflows divididos em 6 para processos de desenvolvimento e 3 para suporte do processo. Cada core workflow recebe mais ou menos ênfase dependendo da fase em que o processo de desenvolvimento está. A seguir, cada core workflow é definido.
Figura 4: A Dimensão do Tempo do RUP.
Os core workflows de processo são Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste e Distribuição e os de suporte são Gerência de Mudanças e Configuração, Gerência de Projeto e Gerência de Ambiente.
O core workflow de Modelagem do Negócio tem como objetivo a modelagem
dos processos de trabalho dos usuários independentemente de automação, provê um entendimento do negócio do usuários, cria um linguagem e conhecimentos comuns entre os usuários e os desenvolvedores. Porém, nem sempre é desenvolvida.
No core workflow de Requisitos, deve-se descrever “o que” o sistema deve fazer,
entender, organizar e documentar as funcionalidades e restrições do sistema, identificar os atores e os casos de uso e criar as descrições dos casos de uso, descrever a especificação suplementar contendo os requisitos não funcionais e suas prioridades, e documentar as reuniões e decisões. Como resultado, o Modelo de Casos de Uso é o principal artefato deste workflow.
O objetivo do core workflow Análise e Projeto é mostrar “como” o sistema será
construído no workflow de implementação. O Modelo de Análise, que é opcional e raramente é desenvolvido, é utilizado para garantir a Robustez. O Modelo de Projeto é gerado. Ele define uma abstração do código fonte e descreve a colaboração das classes para realizarem os casos de uso. As classes são estruturadas em pacotes e subsistemas com interfaces bem definidas e estes representam os componentes no workflow de Implementação.
No core workflow de Implementação, define-se a organização do código em
termos de subsistemas organizados em camadas, implementam-se classes e objetos em termos de componentes, testam-se os componentes em termos de unidades e integram-se os resultados produzidos por implementadores individuais em um sistema executável.
No core workflow de Testes, deve-se verificar a interação entre os objetos, a
integração de todos os componentes de software e se todos os requisitos têm sido corretamente implementados. Tenta-se assegurar que os defeitos foram encontrados e corrigidos antes da distribuição do sistema.
O core workflow de Distribuição tem como objetivo a produção de versões do
software para os usuários, transformando-o num produto, distribuindo e instalando no cliente. Versões beta podem ser distribuídas, porém, devem ser acompanhadas de um plano de testes e conseqüentes manutenções. Assistência aos usuários e testes de aceitação devem ser realizados.
No core workflow de Gerência do Projeto tenta balancear os objetivos do
sistema gerenciando riscos e restrições de tempo e recursos. A Rational provê um
framework para gerência de projetos, um guia para planejamento, alocação de pessoas,
execução e monitoramento de projetos. Este framework recebe o mesmo nome do processo, RUP.
No core workflow de Gerência de Configuração e Mudanças, o objetivo é
controlar os numerosos artefatos produzidos em um projeto, controlar atualizações simultâneas e notificações de alterações sobre os artefatos, controlar múltiplas versões e as composições dos sistemas (que versão de cada componente está alocada a cada sistema), gerenciar as solicitações de mudanças no sistema por mudanças no negócio ou por defeitos encontrados.
Já no core workflow de Ambiente, o objetivo é controlar a organização do
ambiente de desenvolvimento de software definindo passo a passo o processo de desenvolvimento, controlar o processo e as versões das ferramentas e gerenciar guias,
templates, padrões e dicas.
O RUP e UML definem alguns artefatos que são produzidos. Alguns artefatos são os modelos e os diagramas. Os modelos são abstrações de um sistema e especificam o sistema a partir de um ponte de vista e num certo nível de abstração [USDP]. Um modelo é uma abstração semanticamente completa do sistema, completa do ponto de vista dos usuários (clientes e desenvolvedores) não necessitarem de outras informações ou de outros modelos para entender o sistema [USDP]. Veja, na figura 5, o mapeamento entre os core workflows de processo e os modelos [USDP].
Inicialmente, os desenvolvedores começam capturando os requisitos dos usuários através dos casos de uso e criando o modelo de casos de uso no core workflow de Requisitos. Então, eles analisam e projetam o sistema para encontrar os casos de uso, assim eles primeiro criam um modelo de análise e, em seguida, um modelo de projeto e outro de distribuição, isto nos core workflows de análise e projeto respectivamente. Eles implementam o sistema em um modelo de implementação, o qual inclui todo o código, isto é, componentes. Este modelo de implementação é construído no core workflow de Implementação. Por fim, eles preparam um modelo de testes, no core workflow de Teste, que os permite verificar se o sistema provê as funcionalidades descritas nos casos de uso.
Outros artefatos são os diagramas que são definidos na UML. Eles são representações textuais e gráficas das informações dos sistemas. A UML define nove diagramas: diagrama de casos de uso, diagrama de classes, diagrama de objetos,
diagrama de seqüência, diagrama de colaboração, diagrama de estado, diagrama de atividades, diagrama de componentes e diagrama de distribuição.
Figura 5: Mapeamento entre Core Workflows e Modelos.
O diagrama de casos de uso especifica o escopo do sistema e define as funcionalidades do sistema. O diagrama de classes apresenta os relacionamentos estáticos entre as entidades ou informações manipuladas no sistema, ele também agrupa as classes em pacotes e subsistemas que posteriormente dão origem ao componentes. O diagrama de objetos são simplesmente instâncias do diagrama de classe. Os diagramas de seqüência e de colaboração apresentam o relacionamento dinâmico das classes na realização dos casos de uso. O diagrama de seqüência enfatiza a questão temporal dos relacionamentos enquanto o diagrama de colaboração enfatiza a cooperação entre os objetos ou classes. O diagrama de estado modela os estados e eventos que afetam os estados para as classes que possuem estados definidos. O diagrama de atividades modela o fluxo de atividades, esta modelagem pode ser a nível processos humanos, a nível de casos de uso ou a nível de métodos. O diagrama de componentes representa a visão a nível de código e modela o sistema a partir de componentes e de dependências
entre eles. O diagrama de distribuição apresenta a alocação do sistema sobre dispositivos físicos, hardware.
Na figura 6, os relacionamentos entre os modelos e os diagramas são apresentados. Um diagrama pode ser utilizado em vários modelos, porém com níveis de detalhes e ênfases dispensadas a eles diferentes. A linha contínua associa os diagramas que têm grande ênfase ou é o foco principal no modelo, e a linha pontilhada indica os que têm pouca ênfase, mas também podem ser realizados no modelo.
Figura 6: Relacionamentos entre Modelos e Diagramas.
