Design da CAL

Uma linguagem visual específica de domínio é composta por diferentes elementos: um grafo de conceitos (ou classes), relacionamentos (compreendendo papéis, cardinalidade, etc.), atributos, entre outros. Uma abordagem comum para especificar uma DSL visual é utilizar uma linguagem de meta-modelagem, como Eclipse Modeling Framework EMF [55] ou a linguagem de meta-modelagem da DSL Tools. Esta última foi utilizada no presente trabalho para a especificação visual da DSL CALV3. A tabela 1 apresenta uma visão geral dos conceitos relacionados a esta linguagem de meta modelagem.

Tabela 1 - Linguagem de meta-modelagem da DSL Tools

Nome do conceito Representação Gráfica Descrição

Classe Uma classe representa

um elemento básico da DSL Visual. Ela refere- se a um conceito do domínio, como Perfil ou Usuário. Ela também pode ser abstrata.

Propriedade Representa um atributo

fortemente tipado de uma classe. Por exemplo, Nome é um atributo do tipo String

da classe Perfil.

Enumerações Sem representação gráfica São tipos especiais de propriedades. Definem valores discretos para as mesmas. Por exemplo, Tipo de Perfil é uma enumeração cujos valores são Administrador, Comum e Genérico.

Relacionamento de herança

Usado para expressar que um conceito é uma especialização de outro.

Relacionamento de agregação

Representa uma relação forte entre dois conceitos. Por exemplo, Objeto tem Ações. Se o Objeto for excluído do modelo, todas as suas ações também serão. Papéis (roles) e cardinalidades se aplicam a este tipo de relacionamento.

Relacionamento de referência

Representa uma relação fraca entre dois conceitos. Por exemplo, Usuário pode estar associado a um Perfil, mas Perfis existem independentemente da existência de usuários.

Cada lado do

relacionamento define um papel (role) gerando uma propriedade na classe relacionada para acessar o outro lado do relacionamento. No exemplo, acima um perfil acessa a lista de usuários associados a ele através da propriedade Users, especificada no relacionamento.

Uma linguagem de meta-modelagem é utilizada para construir um meta-modelo, que descreve uma linguagem de modelagem, como a CALV3, da mesma forma que um modelo descreve um sistema. Em domínios não muito conhecidos, pode ser essencial a definição de uma ontologia. Ontologias provêm um vocabulário comum de uma área e definem, com diferentes níveis de formalidade, o significado dos termos e relações entre eles. Assim sendo, o design da DSL fica mais intuitivo e acurado. No caso da CALV3, não foi necessária a definição de uma ontologia própria, tendo em vista o uso da ontologia do modelo RBAC.

Contudo, dois conceitos adicionais, Informação e Valor, foram incluídos no meta-modelo, pois são específicos do CA V3. Seguem suas definições:

Informação – Representa um meta-dado que possuirá valores associados, com o objetivo de parametrizar um sistema. O tipo dos valores de uma informação são aqui definidos e podem ser: texto, numérico ou data.

Valor – Dado associado a uma determinada Informação, cujo tipo de dado é definido por ela. A melhor analogia é que Valores são como registros de uma tabela, a Informação.

O meta-modelo da CALV3 será apresentado nas figuras seguintes, pois, devido ao seu tamanho, sua visualização completa não ficará muito clara. A Figura 11 detalha a classe raiz do meta-modelo CAV3Model. Ela representa o próprio diagrama no qual os outros conceitos serão criados. Os conceitos que podem ser associados a este diagrama diretamente, através da operação de arrastar e soltar, aparecem relacionados à classe raiz. São eles: Role (Perfis), User (Usuário), Group (Grupo), Objeto e Information (Informação). Os conceitos restantes, Ação e

Valor, só poderão ser arrastados para dentro de conceitos containers, Objeto e Informação, respectivamente. Com exceção de Informação e Valor, que foram definidos acima, todos os conceitos representam termos do modelo RBAC (vide seção 4.1). Além disso, a cardinalidade dos relacionamentos indica que podem existir nenhum ou vários destes elementos em cada diagrama gerado. Outro detalhe digno de nota são as propriedades especificadas na classe raiz, uma das quais, Ambiente, é uma enumeração que pode conter apenas os valores DESE, TEST, HOMO e PROD, representando os valores possíveis de ambientes de infra-estrutura do CA: desenvolvimento, teste, homologação e produção.

A Figura 12 demonstra que um perfil pode ser associado aos seguintes conceitos do CA: Grupo (Group), Objeto, Ação (Action) e Valor. Esta associação demonstra uma pequena diferença entre o modelo RBAC e o modelo do CA V3, pois, neste último, não é possível associar um perfil a outros perfis.

Uma característica interessante do meta-modelo é que, dependendo como seja feito o relacionamento, a forma como os conceitos serão associados no designer gráfico será afetada. Por exemplo, na Figura 13, temos o relacionamento entre Usuário (User) e Perfil (Role). Isto

significa dizer que a conexão entre estes dois conceitos que será feita no diagrama deverá partir de Usuário para Perfil e nunca o contrário. Esta decisão de design, bem como outras

exibidas até agora, foi tomada para refletir mais fielmente a forma de trabalho atual no Console do CA.

A Figura 14 expressa o relacionamento entre dois conceitos iguais, no caso entre um objeto e outro. Lembrando que o conceito de objeto, no contexto da CALV3, representa um objeto de interface de usuário, tal como um item de menu, uma tela ou botão e, sendo assim, estes podem ser relacionados entre si formando uma hierarquia. Como, por exemplo, na relação hierárquica expressa abaixo:

• Menu principal o Sub-Menu 1

Tela 1 o Sub-Menu 2

Tela 2

Outro detalhe importante é que os nomes dos relacionamentos podem ser modificados para melhor exprimir sua semântica. Neste caso, o relacionamento foi denominado Hierarquia e suas respectivas roles foram chamadas Pai (Parent) e Filhos (Children), para deixar bem claro que um Pai pode ter vários filhos, mas um filho só tem um pai, como expresso pela cardinalidade.

Para finalizar a explanação sobre o design da CALV3, na Figura 15, apresentamos o exemplo de um relacionamento de agregação entre objetos e ações. Foram criadas duas

Figura 15 - Relacionamento de agregação entre objeto e ação Figura 14 - Relacionamento de hierarquia entre Objetos

classes abstratas ContainerObjAbstrato e InnerContainerObj. Estas duas classes tem a finalidade de modificar o comportamento do designer, permitindo que uma classe que herde de InnerContainerObj, no caso Ação (Action), possa ser arrastada para dentro de uma classe que herde de ContainerObjAbstrato, neste caso Objeto. O relacionamento entre Informação e Valor seguem este mesmo padrão de design.

Abaixo segue a representação completa do design da CALV3, unindo as partes do modelo apresentadas até aqui.