quarta-feira, outubro 10, 2007

Identificação de Elementos de Design no RUP e OpenUP / Série Análise e Design - Parte 4

Conforme visto no artigo anterior (parte 3) da série Análise e Design, trataremos agora acerca da atividade Identificar Elementos de Design (Identify Design Elements em inglês).

Podemos resumir a atividade de Identificação de Elementos de Design como aquela aonde as classes de análise são refinadas em classes de design e subsistemas.

A seguir os quatro passos dessa atividade:

1 - Identificar Classes e Subsistemas: Aonde o arquiteto deve decidir se uma classe de análise virará uma ou mais classes de design ou então um subsistema.

2 - Identificar interfaces dos subsistemas: Aonde o arquiteto deve definir todas as responsabilidades (operações) que serão fornecidas pelas interfaces dos subsistemas.

3 - Identificar oportunidades de reuso: Com base nas interfaces identificadas no passo 2, o arquiteto deve analisar internamente na empresa e externamente no mercado para buscar subsistemas (componentes, frameworks, web services, etc) que possam atender as necessidades da solução sem ter que reconstruir o subsistema do zero. Esse é um passo fundamental que costuma ser feito apenas de forma intuitiva pelos arquitetos.

4 - Atualizar a organização do modelo de design: Aonde o arquiteto define um esboço inicial da arquitetura em camadas e do empacotamento da solução.

Um subsistema nada mais é que um conjunto de elementos que fornecem um comportamento através de uma interface definida. A diferença de um subsistema e um pacote ( package ) da UML é que o subsistema realiza uma ou mais interfaces enquanto o pacote não possui uma interface definida (a interface do pacote são as operações públicas das classes que o compõem).

Por ser uma definição muito genérica e ter o nome de subsistema(o sistema no nome assusta e dá impressão de um módulo grande) os desenvolvedores confundem às vezes o que pode ser um subsistema. Alguns exemplos para facilitar:

- um componente COM+ de uma solução .NET pode ser considerado um subsistema.
- um Session EJB que fornece uma interface e faz ligações com outras classes pode ser considerado um subsistema.
- um módulo, componente ou API para um produto existente como, por exemplo, softwares de comunicação, acesso a bancos de dados, utilitários comuns (exemplo: uma solução open source para geração de logs como o Log4J, um componente para persistência de dados como Hibernate, ADO, etc).
- um componente para acessar um sistema externo ou legado.
- um web service.

Lembre-se da regra: um subsistema é tudo aquilo que possui uma ou mais classes reunidas e que são acessíveis somente através de uma interface bem definida.

Nessa atividade de identificação dos elementos de design o arquiteto ainda não deve detalhar o componente em si e suas interações internas. Aqui ele só deve identificar as responsabilidades ( operações ) que devem existir nas interfaces para atender aos requisitos do sistema e das realizações dos casos de uso. Cada subsistema deverá ter no mínimo uma interface (pode ter mais de uma).

Outra dica importante é a referente ao passo 4, que trata da arquitetura em camadas da aplicação. Recomendo fortemente a leitura do livro "Patterns of Enterprise Application Architecture" onde o grande Martin Fowler aborda em profundidade o assunto e também o livro "Applying UML and Patterns, 3rd Edition" do Craig Larman para uma abordagem mais didática.

No próximo artigo trataremos da atividade de identificação dos mecanismos de design. Até a próxima!!!

Marcadores: , , ,

1 Comentários:

At 3:26 AM, Blogger Alan Daniel disse...

Parabêns, gostei do blog

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas