Arquitetura do RUP

O RUP é dividido, primariamente, em fases, sendo que essas fases podem conter várias iterações, que são ciclos onde cada etapa acontece. As 4 (quatro) fa- ses do RUP são [KRUCHTEN 00]:

• Concepção: neste momento define-se o escopo total do projeto, defi-

nindo se este seria, ou não, viável economicamente e se o mesmo re- solveria os problemas para qual será desenvolvido;

• Elaboração: visa eliminar principais riscos e, principalmente, definir a arquitetura que o sistema será desenvolvido. Sendo que esta deverá ser a mais estável e a que permita o sistema evoluir;

• Construção:Nesta fase o sistema começa a ser desenvolvido (codifi-

cado), sendo que este desenvolvimento, assim como todo o projeto, ocorre de maneira iterativa. Ao final de cada ciclo, pode ser gerada uma versão utilizável que crescerá a cada iteração;

• Transição: Esta fase implanta é responsável pela implantação do sis-

tema. O Software é passado aos usuários para que estes possam fazer suas considerações.

Outro conceito encontrado do RUP são as disciplinas, também chamada de workflows. As disciplinas servem para organizar logicamente atividades de engenha- ria de software de acordo com sua natureza. Elas descrevem o que deve ser feito em cada iteração a respeito de atividades, responsáveis e documentos. Existem 9 (nove) disciplinas básicas, sendo que 6 (seis) são de engenharia de software e as outras 3 (três) são de suporte. São elas:

• Modelagem de Negócios: visa entender a estrutura e a dinâmica da

organização para qual se vai desenvolver o projeto, deixando uma úni- ca visão para cliente, usuários e desenvolvedores, além de derivar re- querimentos que suportam a organização;

• Requisitos: Definir, documentar e organizar as funcionalidades do sis-

tema, bem como gerenciar o escopo e as mudanças destas funcionali- dades;

• Análise e Projeto: Traduz os requisitos em uma linguagem que des-

creve como o sistema deve ser implementado. A linguagem utilizada é a UML (Unified Modeling Language);

• Implementação: Fluxo muito importante. Nele o sistema é codificado

na linguagem de programação especificada. Também são feitos testes e a integração com módulos desenvolvidos em outros ciclos;

• Testes: Testa todo o sistema, verificando se este está de acordo com o

que foi especificado. Valida também a integração entre objetos já im- plementados. Tem como meta, encontrar defeitos antes da implemen- tação do software;

• Implantação: Implanta o sistema para o usuário final, dando ênfase no

• Gerência de Projeto: Engloba o gerenciamento de riscos, planejamen- to e o acompanhamento do projeto;

• Gerência de Configuração e Mudanças: Gerencia documentos gera-

dos no decorrer do projeto, para que estes sempre estejam em con- formidade ao que já foi desenvolvido;

• Ambiente: Define como o RUP foi configurado para ser utilizado no projeto, além da organização do ambiente de trabalho para toda a e- quipe de desenvolvimento.

A figura 3.1 mostra a relação entre as fases, mostradas na horizontal, e as disciplinas, ou workflows, mostradas na vertical.

Para encontrar não-conformidades e falhas no sistema, de acordo com o que foi especificado no início do projeto, é gerado ao final de cada fase e de cada itera- ção um documento (marco), que neste processo é chamado de milestone. Este do-

cumento é responsável por verificar se todos os objetivos da determinada fase foram alcançados.

Existem dois tipos de milestone, os minor milestones, gerados ao final de ca- da iteração, independentes de que fase de desenvolvimento. Com este documento são analisados os resultados obtidos durante a iteração, revisando o planejamento caso seja necessário [KRUCHTEN 00].

E ao final de cada fase, é gerado um major milestone, sendo que este analisa os resultados obtidos durante a fase. A cada major milestone gerado, é feito uma verificação total no projeto, onde é determinado se este continua sendo desenvolvi- do, ou é abortado ou replanejado.

Após a conclusão da última fase, o ciclo pode recomeçar, o que representa uma evolução do sistema, passando por todas as fases novamente, gerando novos documentos e novas versões do sistema, caso haja algum desenvolvimento.

O RUP também se utiliza de Artefatos, que são produtos utilizados durante o desenvolvimento do projeto. Usualmente os artefatos são documentos (relatórios de riscos), modelos (Casos de uso) e modelo de elementos (Diagrama de Classes). Esses artefatos são agrupados em disciplinas (workflows), já que cada uma produz um conjunto de artefatos diferentes.

O conceito central mais importante de todo o processo é o de Workers, ato- res, em português. Um Worker (ator) define o comportamento e as responsabilida- des de um indivíduo, ou de um grupo deles trabalhando como uma equipe, dentro do contexto de uma empresa de engenharia de software.

Workers são os papéis desempenhados por indivíduos dentro do projeto, que definem como estes devem trabalhar. Esses papéis irão definir as principais ativida-

des e responsabilidades do indivíduo, ou grupo de indivíduos, mostrando como es- tes devem se comportar.

As Atividades são as ações realizadas por um ator que geram algum resulta- do significativo para o projeto. As atividades são usadas para medir o rendimento de um determinado indivíduo desempenhando determinado papel.

As Atividades têm um propósito claro, que geralmente é criar ou atualizar al- gum artefato, seja ele um diagrama ou modelo.

Essas atividades usualmente variam de poucas horas a poucos dias, e são designadas especificamente a um determinado worker. Servem também como ele- mento de decisão de planejamento.

Como o RUP é um processo iterativo, as atividades repetidas podem voltar a ocorrer, principalmente se tratando de alterações em artefatos de diagramas e mo- delagem, pois estes devem ser alterados a cada mudança na especificação de re- quisitos.

As atividades são divididas em passos e esses passos podem se encaixar em 3 (três) categorias:

• Pensar: os workers entendem a natureza da tarefa, juntam e exami-

nam os artefatos de entrada, formulando a saída;

• Agir: aonde ocorre efetivamente à criação ou alteração dos artefatos;

• Revisar: os workers analisam o que foi desenvolvido, baseando-se em

algum critério.

Por fim pode-se dizer que o Ciclo de vida do RUP é baseado e suas 4 (qua- tro) fases. O ciclo é, em sua visão menor, analisando as cada fase, iterativo, já que implementa perfeitamente o conceito de iteração, porém numa visão total do proces- so, quando leva-se em consideração todos os passos e a seqüência exata do pro-

cesso, é considerado em série. Novas versões e releases (artefatos) podem ser de- senvolvidos e agregados ao projeto original, encaixando-se no modelo incremental.