Representação de restrições deônticas em OCL

Abstract

Por vezes com a utilização, real, dos sistemas de informação somos confrontados com situações cujo carácter excepcional não permite, ao modelador de sistemas de informação, representar todas as propriedades que revestem as relações entre as entidades do mundo real. Isto acontece porque as associações entre classes de objectos, que representam as entidades do mundo real, dependem de restrições rígidas, verificadas por um valor “sim” ou “não” das quais depende a formação dos objectos da associação. Nestes casos não basta retirar a restrição imposta e permitir a associação, porque a representação da realidade sairia empobrecida, em vez disso torna-se necessário o enriquecimento gráfico e semântico do diagrama de classes da UML, possibilitando a caracterização de um novo tipo de restrição: a restrição deôntica. É proposta uma metodologia de levantamento e descrição de casos reais em que a utilização de sistemas de informação justifique a utilização de restrições deônticas. Através dos mecanismos de extensão da uml e do recurso à linguagem de modelação ocl pretende-se definir uma representação genérica, a aplicar a estes casos. Em qualquer sistema de informação é fundamental preservar a persistência da informação, assim o modelo relacional será utilizado para o efeito. Como o diagrama de classes implementa o modelo orientado ao objecto é necessário proceder ao mapeamento do diagrama de classes para o modelo relacional, para o efeito é proposta uma metodologia que assenta na aplicação nas regras generalistas de mapeamento entre os dois modelos; seguidas da criação de tabelas adicionais para mapear e preservar a informação relativa às restrições deônticas; e da criação de uma estrutura de triggers que implementam a semântica, ou seja o comportamento esperado das restrições deônticas. Pretende-se após representação, no diagrama de classes, do sistema, e das restrições deônticas, que seja criado automaticamente o diagrama relacional que lhes corresponde. Para o efeito é proposto o desenvolvimento de uma aplicação, em Prolog, que lê os dados do diagrama de classes, processa os mesmos, e finalmente, cria automaticamente, a estrutura relacional correspondente.

Sometimes we are faced with exceptional situations that cannot be represented, by the modeler, as they exist in the real world. This happens because the associations between object classes, that represent the real world entities, depend on strong constraints, verified by a value "yes" or "no", on which depends the creation of the association objects. In these cases it is not enough to remove the restriction imposed and allow the association, because this would impoverished reality demonstration, instead it is necessary to enrich the graphical and semantic representation of the UML class diagram, allowing the characterization of a new type of restriction called deontic, or soft, constraint. A methodology for survey and description of actual cases in which the use of information systems justify the application use of soft constraints, is proposed. Through the extension mechanisms of UML and the use of OCL modeling language, it is intended to define a generic representation, to apply to such cases. In any information system it is essential to preserve the persistence of information, so the relational model will be used for this purpose. As the diagram of classes implements the object oriented model it is necessary to map from this model to the relational one. To achieve this it is proposed a methodology based on the application of general mapping rules between the two models; followed by the creation of additional tables, to map and preserve the information of soft constraints; and the creation of trigger structures that implement the semantics, or in other words the expected behavior, of those kinds of constraints. After representation in the class diagram of the system and soft constraints, it is intended to be automatically created the relational diagram that represents them. The aim is to develop an application in Prolog, which reads data from the diagram of classes, processes them, and finally, automatically generates the correspondent relational structure.