A Military-Means Approach to Women, Peace and Security

Será considerado, a seguir, um exemplo prático de transformação manual de modelos. Supondo que um analista estudou o domínio de negócio de uma escola e definiu um modelo simples em linguagem textual natural (facilmente interpretada por humanos e dificilmente interpretada por máquinas) que descreve um problema a ser resolvido através de um sistema de software, conforme o Quadro 1.

Evidentemente, este modelo, que serve para o propósito ilustrativo, é simples quando comparado com casos típicos, pois nem mesmo menciona notas ou critérios de aprovação. O modelo está expresso em linguagem natural, sem fazer referência a nenhuma plataforma computacional ou recurso específico. Está, portanto, descrito em uma linguagem abstrata, e descreve aspectos sobre como o negócio funciona e também sobre os requisitos desejados para a solução. Não descreve, por exemplo, como deve ser a interface de usuário ou a sequência de operações do sistema,

24 pertencendo, então, a domínios de descrição abstratos. Assim sendo, o modelo se localiza em algum ponto na parte superior à esquerda, dentro da área vermelha da Figura 3.

Quadro 1 – Modelo de domínio de negócio de uma escola em linguagem natural

Em uma escola, existem cursos, turmas e alunos. Em um dado semestre, alunos matriculam-se em cursos, formando-se turmas. Uma turma pode ter de 1 a 40 alunos. Havendo mais alunos matriculados do que o permitido, a escola pode optar por abrir uma nova turma para o mesmo curso no mesmo semestre. Um único professor ministra um curso para uma turma, mas o mesmo professor pode ministrar um ou mais cursos para mais de uma turma. Um professor também pode estar desalocado no semestre, não ministrando nenhum curso para nenhuma turma.

Deseja-se construir um sistema que permita armazenar, cadastrar e consultar alunos, turmas, cursos, professores e notas.

Fonte: autor

Sabe-se que, por estar descrito em linguagem natural, é muito difícil aplicar transformações automáticas com esse modelo. Mas, para fins de exemplo, aplicar- se-á a estratégia da MDE manualmente.

De acordo com a Figura 3, deseja-se partir desse modelo em direção a uma implementação concreta de sistema, seguindo a direção da curva.

O analista poderia, então, propor o modelo da Figura 4, expresso por meio de um diagrama de classes UML, que descreve os tipos de dados com os quais o sistema lida e seus relacionamentos.

Esse modelo reflete apenas um domínio de descrição específico da construção do sistema (classes de negócio e seus relacionamentos), sendo necessários outros modelos complementares para prover informações suficientes para uma implementação final em código-fonte. Mesmo assim, já é possível observar que surgiram informações de implementação da solução que não existiam explicitamente no modelo anterior.

25

Figura 4 – Diagrama de classes do sistema escolar exemplo

Fonte: autor

Pode-se dar um passo adicional e criar então mais um modelo. Desta vez, um modelo de interface de usuário para cada classe persistente, ou seja, para as classes cujos objetos precisam ser armazenados em disco para persistirem após o término da execução do sistema e serem recuperados na próxima execução. No diagrama UML, essas classes estão indicadas com o estereótipo «persistent». Trata- se de um modelo de outro domínio de descrição.

Se considerada a implementação do sistema em plataforma web, por exemplo, pode-se expressar o modelo da interface de usuário para cadastro de alunos através do código de uma página HTML com um formulário de entrada de dados, conforme Figura 5.

Esse modelo está à direita no gráfico, por ser expresso por meio de uma linguagem mais concreta e apresentar dependência da plataforma web (já sendo inclusive parte do código-fonte final do sistema). Também está abaixo, por estar em um domínio de descrição concreto, já que a interface está sendo definida com precisão. Portanto, esse modelo estaria dentro da área verde da Figura 3.

De volta ao modelo original do Quadro 1, outro analista poderia ter criado um diagrama de classes diferente da Figura 4 com base no mesmo modelo original. Poderia, por exemplo, ter criado uma classe CPessoa com os atributos Nome e

26 Endereco. As classes CAluno e CProfessor poderiam ser subclasses CPessoa, herdando esses atributos.

Figura 5 – Modelo para especificação da interface do cadastro de aluno (a) Código HTML (b) Renderização da interface no navegador

<html> <head> <title>Cadastro do Aluno</title> </head> <body> <h1>Cadastro do Aluno</h1> <br /><br /> <form name="CadastroAluno"> <table border="0"> <tr> <td>Nome:</td> <td><input type="text" /></td> </tr> <tr> <td>Endereco:</td> <td><input type="text" /></td> </tr> </table> <br /> <input type="submit" /> </form> </body> </html> (a) (b) Fonte: autor

De maneira análoga, outro analista poderia ter criado o modelo de interface de usuário da Figura 5 contemplando botões e controles para realizar algumas operações relativas ao aluno, tais como efetuar a matrícula em um curso e inseri-lo em uma turma.

Pelo exemplo apresentado é possível observar que, se não houver uma forma de sincronização automática de modelos, um trabalho manual deve ser realizado caso haja alterações no modelo inicial, aumentando o custo, prazo e susceptibilidade a erros no projeto. Linguagens textuais naturais podem ser práticas para descrever modelos em qualquer nível, mas por serem difíceis de serem interpretadas por máquinas, elas não servem para a aplicação de transformação automática.

Se existissem funções com regras pré-definidas para gerar um modelo a partir de outros, seria garantida a repetibilidade das decisões quando se transformam modelos contendo instâncias do mesmo tipo. Se for necessário trocar uma regra por outra mais adequada em determinado contexto, basta reexecutar a transformação e

27 obtêm-se novos modelos a partir dos originais. Ou seja, as regras padronizam a maneira de construir modelos a partir de outros modelos. Se posteriormente for percebida a necessidade de melhoria e evolução nessas regras, o trabalho manual ficará centralizado na atualização dessas regras. Feito isso, é possível reaplicá-las de forma automática sobre os modelos desejados. Com a ausência desse mecanismo automático, os analistas ou desenvolvedores precisariam atualizar e checar manualmente todos esses modelos, tornando a manutenção do sistema mais cara e demorada.

A seguir, será retomado o conceito de metamodelos, necessário para o entendimento de como podem ser definidas as funções de mapeamento para realizar transformações automáticas de modelos.