Diagramas de classes - um exemplo funcional com Visio Enterprise Architecture 2003 e C#

Neste artigo vamos abordar um caso prático de construção de diagramas de classes com o Visio Enterprise Architecture, que chamaremos simplesmente de VEA, e como gerar automaticamente seu respectivo código em C#.

por Fabio Camara

Uma especificação clara aliada a um diagrama de classes construído pelo Visio Enterprise Architecture 2003 gerando automaticamente o código na sua linguagem preferida (VB.NET ou C#) podem incrementar a produtividade do seu time de desenvolvedores. Nossa proposta é exemplificar esta afirmação nas linhas abaixo e possibilitar ao leitor adicionar uma nova proposta ao seu dia-a-dia.

Neste artigo vamos abordar um caso prático de construção de diagramas de classes com o Visio Enterprise Architecture, que chamaremos simplesmente de VEA, e como gerar automaticamente seu respectivo código em C#. Consideramos que o leitor já consegue basicamente manipular o VEA e o Visual Studio.NET 2003, assim como possui conceitos básicos da notação UML. De forma incidental serão comentados alguns procedimentos baseados no Team Model e Process Model do MSF 3.1 (Microsoft Solutions Framework). Não é objetivo desse artigo, abortar questões sintáticas e semânticas da linguagem UML.

Em muitos anos de realizações históricas a frente de projetos de software, seja como desenvolvedor, arquiteto, coordenador de time ou "program manager" (no modelo de time do MSF), verifiquei ser uma salutar prática ao projeto de desenvolvimento separar atividades de criação de atividades de replicação. Entenda-se atividades de criação por desenvolvimento de funcionalidades que requerem pesquisa e, ou, questões relacionadas a arquitetura da solução. Atividades de replicação são funcionalidades mais corriqueiras ao escopo de uma solução, como por exemplo classes "CRUD" - Create, Read, Update, Delete (1).

Nota 1

Classes CRUD são classes especialistas na manipulação de dados e no gerenciamento das questões envolvendo a camada de persistência.

Obviamente que as atividades de replicação necessitam ser "o mais automatizada possível" para não desperdiçar a inteligência dos seres humanos nesta missão "robotizada" de digitar código replicável. Nesta linha de raciocínio, intuitivamente pensamos para esta função utilizar geradores de código, como por exemplo as inúmeras ferramentas "case" que podem ser adquiridas no mercado hoje em dia.

Do ponto de vista de codificação somente, estas ferramentas de geração de código possivelmente incrementarão significativamente a produtividade do seu time de desenvolvimento, entretanto particularmente defendo o Visio como uma alternativa que possui suas vantagens, especialmente quando colocamos em questão também práticas de especificação e documentação.

O VEA não irá gerar muito código como estas ferramentas de geração de código automatizado que geralmente constroem as interações com os conjuntos de dados de uma camada de persistência, contudo ele permitirá que a partir de uma especificação útil para diversas finalidades escrita na notação UML, que é uma "linguagem universal", gerar código suficiente para eliminar vários fatores de criação dos desenvolvedores e até definitivamente padronizar algumas características importantes a boa codificação, como as assinaturas dos métodos e eventos, e nomes das propriedades e variáveis (2).

Nota 2

Desde que exista um documento de padrões definindo estas questões, popularmente conhecido como design patterns, e o analista responsável pelos diagramas utilize os padrões especificados.

A proposta que encaminhamos neste artigo é a automação de atividades que não necessitam de criatividade e estão diretamente ligadas a normas e padrões de desenvolvimento. Particularmente considero improdutivo, na maioria dos casos, a "geração" de códigos fontes genéricos através de "ferramentas cases" pelo simples fato de que não acredito em problemas "genéricos". Cada solução, se deseja ser completa, deve ser especifica, ímpar.

Então, o que estamos automatizando são as assinaturas do métodos, nomes de propriedades, variáveis e constantes, uma espécie de "esqueleto" para a implementação de classes.

Diagrama de classes

É um diagrama geralmente construído na Planning Phase (Process Model MSF) e utilizado como uma espécie de "validador" dos requisitos obtidos nos levantamentos realizados. O diagrama de classes levanta questões como "o que pode acontecer" e também verifica o que o sistema deve fazer quando questionado a fazer. Este diagrama fornece ricas visões ao corpo técnico de um projeto, especialmente ao program manager, team development leader e aos programadores.

Nos diagramas de classes, visões lógicas e físicas e o relacionamento entre objetos de uma solução são diagramados. Em outras palavras isto significa que as classes identificadas nos diagramas de caso de uso estão modeladas no diagrama de classes.

É uma representação da estrutura estática de um sistema, em termos de classes e da relação entre estas mesmas classes. Sua imagem na forma mais simples está demonstrada na figura 1.

Figura 1. Demonstração visual de uma classe UML.

Com o objetivo de capacitação aos procedimentos necessários para o exercício deste artigo, alguns conceitos de diagramas de classes serão superficialmente apresentados, em especial a aspectos visuais. A figura 1 possui 3 divisões horizontais, são elas: O nome da classe, atributos e operadores.

O nome da classe é auto explicativo. Atributos são as propriedades, inclusive para o mundo .NET e operadores são os métodos, especificamente procedimentos e funções no mundo .NET.

As questões de visibilidade de atributos e operadores estão explicados na figura 2.

Figura 2. Visibilidade de atributos e operadores de uma classe UML.Implementando

Para nossa proposta precisamos entender antecipadamente o que é um package também. Se você estudar a fundo o assunto, o package pode estar relacionado a diferentes significados dependendo da forma como implementa seu diagrama de classes. Na minha leitura, o package possui duas excelentes finalidades:

• Ser um grupo de elementos, o que é bastante útil como organização e facilita a visualização do diagrama;
• Ele será o "namespace" de nossa implementação no C#, quando solicitarmos a geração automática do código.

Os próximos textos serão práticos e refletiram os conceitos apresentados anteriormente.

1. Inicie o VEA (Visio Enterprise Architecture 2003) e selecione o template Software / UML Model Diagram (não faz diferença entre o Metric e o US Unit para nosso exemplo);
2. Grave seu Class Diagram com o nome CDXProposal;
3. Crie um package chamado pXProposal, este será o namespace que conterá nossas classes. Para isto arraste e solte um package para o diagrama, clique duas vezes sobre o mesmo com o mouse e preencha o campo "name" no formulário que irá surgir;
4. Selecione e arraste uma class para o diagrama e nomeie-a clsLogon;
5. Na janela Model Explorer, selecione e arraste a class clsLogon para dentro do package pXProposal. O novo nome da class será "pXProposal:: clsLogon";

Figura 3. Desenhando o package e a classe

A título de curiosidade você pode verificar como o VEA transforma seu diagrama em código C#. Com esta finalidade, selecione o menu UML / Code / Generate, surgirá o "Generate Dialog Box" conforme representado na figura 4. O resultado esta representado na listagem 1.

Figura 4. Code Generator do menu UML

Listagem 1. Código .NET gerado pelo Visio EA

namespace pXProposal
{
	public class clsLogon
	{

	}// END CLASS DEFINITION clsLogon
} // pXProposal

Como próximo passo vamos criar os atributos de nossa classe. Para efeito de controle, exclua o arquivo clsLogon.cs que geramos para a visualização anterior.

1. Clique duas vezes com o mouse em cima de nossa classe no Visio, isto abrirá o formulário de edição da classe;
2. No list view "Categories" selecione o item attributes (3);

Nota 3

Attributes são propriedades no ambiente de desenvolvimento .NET

3. Clique no botão "New" e preencha com as seguintes informações:

Attribute	Type	Visibility	Multiplicity
_userID	C#::String	Private	1
_password	C#::String	Private	1

Aproveitando o "embalo", vamos definir também os métodos que precisamos.

4. Selecione no list view "Categories" o item "operations" (4);
5. Digite Logon na coluna "Operation" e selecione C#::bool na coluna "Return Type List";
6. Clique no botão "Properties" enquanto a operação Logon esta selecionada, uma nova caixa de dialogo irá surgir conforme demonstrado na figura 5;

Nota 4

Operations são geralmente métodos na .NET_lândia. Tecnicamente, um "operations" é uma interface e o método é o seu código fonte, contudo estes termos são modificados conceitualmente quando compreendemos sua implementação prática. No modelo de classes UML, um "operations" possue os seguintes tipos .NET: Constructor, Destructor, Event, Procedure e Property procedure.

Figura 5. Criando os parâmetros do método

7. Selecione primeiramente o item "Code Generation Options" do list view "Categories" e certifique-se que a opção "Procedure" esta ativada na lista "Operation Kind";
8. Voltando para o list view "Categories", marque o item "Parameters";
9. Conforme sugere a figura 5, preencha incluindo dois novos parâmetros com os nomes userID e password;
10. Como medida de prevenção, após clicar em OK na caixa de dialogo e confirmar definitivamente clicando no botão OK do primeiro formulário, selecione o item "Code Generation Option" do list view "Categories" e certifique-se que está selecionado C# em "Target Language";
11. Finalize e compare o resultado com a figura 6.

Figura 6. Resultado das implementações na janela Model Explorer

Repetindo a operação para gerar o código fonte, obteremos o seguinte resultado demonstrado na listagem 2.

Listagem 2. Código .NET final gerado pelo Visio EA para nossa classe

namespace pXProposal
{
	public class clsLogon
	{
		private string _userID;
		private string _password;

		public bool Logon(string userID,	string password)
		{
			
		}
	}// END CLASS DEFINITION clsLogon
} // pXProposal

Vantagens

Um ponto de vista funcional, extremamente útil, é se consideramos para esta proposta que você está liderando um time de desenvolvedores. Avalie o aspecto que além de passar o Caso de Uso apropriado, você submete conjuntamente o diagrama de classes e seu respectivo código devidamente gerado para ser adicionado ao projeto no Visual Studio .NET. Certamente isso trará um impacto positivo nas prováveis dúvidas dos programadores e no resultado da implementação também.

Considere também a seguinte outra situação: Você é um desenvolvedor e precisa escrever uma classe de negócios para um determinado projeto. Você verifica a documentação fornecida e percebe uma grande preocupação com aspectos funcionais do negócio mas não encontra orientações sobre como "criar" esta classe. Você procura (se já não decorou) o documento geral de padrões e verifica as determinações sobre nomenclaturas e tipos, abre o Visual Studio .NET e começa a escrever "do zero". Imagine agora a mesma situação, contudo você recebe também um arquivo pronto com as assinaturas dos métodos que necessitam ser preenchidos com as implementações do negócio além de outros como constantes, variáveis e propriedades. Qual das duas é mais produtiva?

E finalizando, esta proposta é imbatível quando encontramos arquiteturas de software nos moldes Windows DNA.

Desvantagens

Dois aspectos não atenderam completamente minhas expectativas sobre esta proposta, especificamente para .NET, contudo esta é uma consideração pessoal.

1. O VEA não possui e não permite implementar o tipo "Dataset". Dependendo de sua "crença", este tipo é amplamente utilizado em classes de acesso a dados.
2. A sincronização entre o modelo estático no VEA e o código fonte não é confiável e em muitos casos podemos observar divergências entre eles. Isso requer uma atenção maior na atualização destes e possivelmente podemos classificar esta questão como um "bug" da ferramenta.

Resumo da ópera

Seja como desenvolvedor ou como "team leader", estude com afinco a possibilidade desta iniciativa em seus projetos, os passos não são complexos, não é uma cultura difícil de introduzir em seu time de desenvolvimento e os benefícios são brevemente visíveis.

Neste momento histórico de oportunidades ímpares com ferramentas .NET, adicione este diferencial ao seu perfil e destaque-se comprovando que além de implementar, és proficiente em planejamento e controle - técnicas ardentemente exigidas para aspirantes a líderes de projetos. Afinal, implementar todo mundo de uma forma ou de outra sabe fazer, rara são as competências de diagnosticar, planejar e controlar.