Análise de Impacto no Enterprise Architect

Quando estamos falando de mudanças em um projeto de desenvolvimento de
software, existe uma grande necessidade de saber no que essa mudança irá
impactar. Esse impacto pode ser encarado de várias formas.

Você
precisa saber o impacto da mudança em termos de requisitos, design e
até código. É importante ter esse conhecimento para poder dimensionar a
mudança e ver a forma certa de lidar com a mesma. Todas essas questões
têm impacto direto na gestão do projeto, porque dependendo da mudança
vai demandar mais recursos, tempo e complexidade.

Uma ferramenta
de requisitos deve tratar com essas questões. Muitas ferramentas
analisam o impacto somente a nível de requisitos, de fato isso não é o
suficiente, porque na prática vai demandar toda uma analise manual de
um projetista ou analista.

Neste artigo, vou mostrar como podemos fazer análise de impacto em dois níveis com a ferramenta Enterprise Architect,
ou o famoso EA. No primeiro nível, vou mostrar o impacto entre Requisitos
funcionais e casos de uso, e no segundo nível mostrarei o impacto dos
casos de uso para o código fonte.

Análise de Impacto sempre tem um custo

Esta
é uma verdade universal. Você sempre terá um custo com a análise de
impacto, ou seja, ela nunca vem de graça. Para poder consultar a
ferramenta (EA) e saber o impacto, você tem que manter o diagrama de
impacto atualizado, isso tem um custo e é mais uma coisa a se preocupar.

Se
você não realizar essa tarefa, na hora da mudança terá o custo de
atualizar a ferramenta. Isso pode ser tão custoso que não se pague
fazer essa tarefa e você pode acabar tendo que fazer a analise na mão.

Não
fazer analise de impacto é um risco, você pode se surpreender com a
mudança. Em projetos pequenos não é necessário o uso desta prática, mas
em projeto de médio e grande porte, onde a complexidade começa a
aumentar, essa prática mostra ter muito valor.

Exemplo prático no EA

Irei
mostrar isso de forma muito simples. Não liguem para a veracidade dos
dados. O objetivo aqui é mostrar na prática como usar este recurso,
então vamos à estrutura do projeto. No projeto de exemplo
EA-Matriz-Impacto, existem as seguintes visões top level:

• Requisitos
• Código
• Matriz Impacto

Requisitos é onde estão os requisitos funcionais bem como os casos de uso,
lembrando que casos de uso são requisitos, mais conhecidos como
requisitos do usuário.

Código
é onde estão os fontes de aplicação, não tive o trabalho de definir
métodos e atributos nas classes, vocês podem perceber que eu coloquei em
uma estrutura que é padrão do maven 2. Isso foi de propósito.

Neste
exemplo, apesar da estrutura do maven, poderia ser construído com
qualquer linguagem como por exemplo PHP, .NET, Python – essas são
linguagens que, assim como Java, o EA faz engenharia reversa e pode
sincronizar os fontes com os seus diagramas.

Matriz Impacto
é onde está a matriz que liga os requisitos aos fontes. Como esse é um
exemplo, usei um único diagrama para isto. Somente em projetos pequenos
isso é viável. Em projetos maiores você terá que ter diversos diagramas
para mapear a realização dos seus requisitos para o código.

Os Requisitos

Requisitos do sistema de Exemplo

Neste
exemplo criei um requisito funcional chamado “O Sistema deve
possibilitar o cadastro de novos clientes e bem como desativar
clientes” e dois requisitos da perspectiva do usuário – os casos de uso
“Manter Clientes” e “Manter Contratos”.

A Codificação

Ciente
destes requisitos, imagine que o desenvolvedor codifica a solução para
atender estes requisitos. Não cheguei a especificar os casos de uso,
porque o foco aqui é na matriz de impacto e não na qualidade dos
requisitos. Mas essa é uma questão que sempre deve estar em sua mente,
é essencial a qualidade de bons requisitos.

Dados esses requisitos, vamos à implementação, para isso confira o seguinte diagrama de classes que segue abaixo:

Diagrama de classes do exemplo

Este
é o diagrama de classes da solução. Como pode ver, empreguei um
ordinário exemplo de codificação usando MVC. Neste ponto, o EA não tem
como saber que classe serve a qual requisito e, logo, não poderá
estabelecer o impacto.

Mapeando a realização de requisitos

Agora
você precisa dizer ao EA como as classes da solução servem os
requisitos da mesma. Para isso vamos criar um diagrama “custom” na aba
“extended”. Com esse diagrama vamos mapear os requisitos para os fontes.

Criar
o diagrama é simples. Mantê-lo, nem sempre. Para criar o diagrama você tem
que arrastar os requisitos funcionais e os casos de uso da visão do
projeto para o diagrama, faça o mesmo com as classes e faça as ligações.

O
Diagrama pode parecer confuso, porque quando você puxa uma classe, o EA
também traz as suas dependências, você pode esconder isso clicando com
o botão direito do mouse sobre a dependência e depois em “Set
Visibility” e depois em “Hide Connector”.

Confira como fica o diagrama.

Diagrama que mapeia Requisitos com Fontes

Usei
um único diagrama pelo motivo que disse antes, este era um exemplo, em
um projeto de verdade você terá vários diagramas deste tipo. Agora que
fizemos esse mapeamento podemos criar a matriz de impacto no EA.

Criando a matriz de impacto

Para
criar a matriz de impacto clique no menu”View” e depois em
“Relationship Matrix” e agora irá abrir a visão de impacto do EA. Vamos
criar duas visões desta matriz, isso é possível graças à capacidade de
lidar com profiles do EA.

Vamos primeiro mostrar o impacto dos
Requisitos funcionais com os casos de uso. Para isso selecione os
seguintes valores, primeiro source, depois target.

Source:

• Source: Requisitos
• Type: Requirement
• Link Type: Realization

Target:

• Target: CasosDeUso
• Type: UseCase
• Direction: Target -> Source

Isso deve produzir o seguinte resultado.

Matriz de Impacto de RF com UC

Agora
vamos à segunda matriz, nesta vamos ver o impacto dos Casos de Uso aos
fontes para isso configure a matriz da seguinte maneira:

Source:

• Source: Requisitos
• Type: UseCase
• Link Type: Realization

Target:

• Target: Java
• Type: Class
• Direction: Target -> Source

Isso deve produzir o seguinte resultado.

Matriz de Impacto de UC com Fontes

Se
você quiser, pode salvar essas configurações clicando com o botão
direito do mouse sobre a barra cinza das configurações e clicando em
“Profiles” e depois “Save as new Profile”.

Agora você pode
analisar o impacto sempre que necessário, esta é uma pratica importante
que está totalmente ligada à gestão de mudanças. Apesar de paga, o EA é
uma excelente solução de modelagem e quebra o galho legal com os
requisitos.

Se você quiser pode baixar este projeto de exemplos que criei aqui.

Abraços e até a próxima.