GENERATION OF UML2 USE CASES FROM MEASURS ONTOLOGY CHARTS

A MDA approach
George Tsaramirsis
Independent Consultant,
gtsaramirsis@gmail.com

Mohammed Yamin
Department of Information Systems Management, King Abdoulaziz Univeristy, Jeddah, Saudi Arabia

doctoryamin@gmail.com

Keywords:

MEASURs Ontology Chart, MEASURs Semantic Analysis, UML Use Case diagram, MDA

Abstract: Semantic Analysis builds on Ontology Charts, which capture all possible relationships amongst entities involved. MEASUR project has produced a description Semantic Analysis tools and constructs, one of them being
Ontology Charts. MEASURs Ontology Charts used to capture the ontological dependencies of an information system. These charts can be transformed to database models and database schemas, class diagrams, component architecture diagrams and prototype systems. This paper shows how MEASURs Ontology Charts can be transformed to UML Use Case diagrams so the developers can get a quick view of the systems interaction with the users. The paper utilizes the Model Driven Architecture approach and using simplified versions of the Ontology Chart and Use Case Meta models. For simplicity and clarity reasons the transformation is described in English rather than a transformation language.

1 INTRODUCTION
MEASURs Ontology Charts are the product of MEASURs Semantic Analysis [6, 7]. These diagrams represent ontologically dependent temporal information and include a number of selfevaluation rules. MEASURs Ontology Charts can be transformed to databases and database schemas [1], class diagrams [2], component architecture diagrams [9,10,11,12] and prototype systems [8]. Ontology Charts were proved to be capable of producing extendable system designs [3, 12] but they quite often can be complex. Other diagrams such as the UML Use Case diagrams offer simple view of the system. Use Case diagrams focus on the users and how they can interact with the system [13]. While Use Case diagrams contain less information about the system than an Ontology

Chart, they are easy to understand, can be used for communications with the users and can be useful testing artefacts. This paper will utilize the Model Driven Architecture [4] approach and show how Use Case diagrams can be auto generated by Ontology Charts. Even if there is significant loss of information during the transformation because Use Case diagrams capture less information than Ontology Charts, this transformation can autogenerate a fair part of the Use Case, saving time from the human designer.

2 RELATED WORK
Earlier research conducted in [12], a UML2 component architecture diagram was described and was auto-generated from an Ontology Chart. Apart

Chapter Error! No text of specified style in document.

from component architecture models during this research they manage to auto generate a number of software engineering artefacts such as class diagrams [2], COM+ diagrams [10], architecture diagrams [11] and prototype systems [8]. These models were mainly used as proof of concept as they generate component architecture which was the main goal. In the future work section of the thesis it was mentioned that it is possible to partly autogenerate Use Case diagrams from Ontology Charts but no details were provided. This paper builds on the future work of [12] and details how Use Case diagrams can be partly auto-generated from Ontology Charts.

Entity, an object or concept of existence that cannot take any responsibility, Relationship, a common interest between two affordances Communication act, The recording of an agent is talking to another agent about something, Determiner, properties of affordances, such as name and so on. There are a number of connectivity rules as to what type of affordance is permitted to be connected with what, however these rules are out of the scope of this paper that focus on the transformation of an Ontology Chart to Use Case diagram.

3 ONTOLOGY CHARTS
MEASURs Ontology Charts are the output of MEASURs Semantic Analysis [7]. These diagrams represent ontologically dependent temporal information and include a number of self-evaluation rules. MEASURs Ontology Chart can be mapped to database diagrams, class diagrams, architecture diagrams and prototype systems. The key idea behind Ontology Charts is that everything is an affordance because it can afford something for example it can afford a property [5]. Affordances are ontologically dependent to other affordances, which mean that if an affordance siege to exist, all the ontologically dependent to this affordance, affordances will also siege to exist [6]. For example if a house ceases to exist, the rooms of the house will also ceases to exist. Each affordance is ontologically dependent to one or two antecedents but for simplicity reasons, when the antecedent of an agent is a country, the society or another concept outside the scope of the system, no antecedent is required. The affordances are temporal and they have start and finish time attributes [1]. The ontological dependency can be seen as a rule, stating that if an antecedents finish time has a value; all its dependents must have a finish value that can be less of equal to this value. So if an antecedent finish, all the dependents will automatically, finish. However, the finish of a dependent does not imply the finish of its antecedent. In the most recent version of Ontology Charts are presented in [12], each affordance can be of one of the following types. Agent, a physical of legal person,

4 USE CASE DIAGRAMS

UMLs Use Case diagrams are mainly used to represent functional requirements in a simplified way [13]. The main elements of the Use Case diagrams are actors, uses cases and their association. Actors represent humans or computer system. Use Cases are a list of text describing how the actor can interface with the system. There are two main associations between Use Cases; include and extend. The include association means that that if the actors interacts with a Use Case that includes another Use Case, has to interact with the included Use Case as well. For example an actor customer is associated with place an order Use Case that includes the pay Use Case. The include association is represented with an arrow from the source Use Case to the Use Case to be included. The extend association means that if the actor interfaces with a Use Case another use may happen as well. For example the actor orders food, sometimes also orders drink. The extend association is accompanied by a trigger which determines when this Use Case will be activated. The extend is represented like the include but the arrow is at the opposite direction and it also has the trigger on the association. Actors can inherit the Use Cases of other actors. This is represented by an arrow from the child to the parent actor. Use Case diagrams are very popular among the software engineering

Error! No text of specified style in document.. Authors Instructions

community due to their simplicity and they are a good starting point for system analysis and design as they show the actors of a system and how they interface with the system. This paper attempts to auto-generate them from MEASUREs Ontology Charts.

following figure 1 shows an overview of the MDA framework.

5 MODEL DRIVEN ARCHITECTURE

The key idea behind Model Driven Architecture (MDA), is to auto generate code from software design models [4]. In MDA terms every representation can be a model and code is considered as a model. Models can be auto generated from other models. The MDA uses transformations to transform source models to target models. These transformations can be manual if they are mainly conducted by humans, semi-automatic when computer is doing them but with human input or automatic if no human input is required. The idea of auto-generate code from models is not new but MDA does it in a more structured way. MDA divides models to four layers. These models are Computational Independent Model (CIM) layer, the Platform Independent Model layer, the Platform Specific Model layer and the code layer. The first consists of models that contain information about the business as well as the computerized system and interactions between them. Models of this layer contain information about the sociotechnical aspect of the system. MEASURs Ontology Charts are considered as CIMs. CIMs are then transformed to Platform Independent Models (PIMs) via a manual or semi-automatic transformation. PIMs are models that contain information about the computerized part of a system but remain at the requirements level. They do not include any implementation details specific to any programming language, operating system or hardware. Use Case diagrams considered as PIMs as they do not include any implementation details. The PIMs are then transformed to Platform Specific Models (PSMs), usually via an automatic transformation. The PSM contain all the implementation details required for auto-generating the code. These details include programming language specific, operating system or hardware specific information. The PSM can be transformed to code via automatic transformations. The

Figure 1: Overview of MDA

As it can be seen from figure 2, transformations can be from source to target and vice versa but this remains at a theoretical level as some times data are lost during the transformation especially, during the CIM to PIM transformation as the PIM contains computerized data only. It is also possible to transform between models in the same layer. For example it is possible to transform a PSM to another PSM (e.g JAVA PSM to C# PSM). The next section utilizes MDA to transform a MEASURs Ontology Chart to Use Case diagram.

6 THE TRANSFORMATION
Before a model can participate in a MDA transformation its corresponding MOF Meta model [14] is required in order to formalize the semantics of the model. A Meta model is a model that explains the semantics of a model. MOF is the Meta modelling standard of MDA. It is like a class diagram that describes all the elements of a model. This section presents both the source and the target Meta models as well as the transformation rules. For simplicity and clarity the rules were written in English rather than a transformation language.

6.1

Source Met model

Chapter Error! No text of specified style in document.

In this paper we only include the properties of the Ontology Charts that will be used by the specific transformation to generate a Use Case diagram. The full Ontology Chart Meta model can be found in [11]. In the Meta model in figure 2, every node of the Ontology Chart is an affordance. An affordance can have a maximum of two antecedent nodes and many dependents that are also affordances. Each affordance has two attributes, a label of type string and a type that is an enumeration and can take the values; agent, entity, relationship, communication act and determiner.

Use Case in the form of: Communication_act:label + for + antecedent2:Label and associated with the first antecedent that has been converted to actor. So a person that applies for a loan, will be transformed to an actor will the label person, a Use Case with the label apply for loan. The entity loan was transformed to text and was placed at the end of the label of the Use Case. Relationships with agents as their First antecedent will be treated similar but without the word for to connect the label of the relationship and the label of the second antecedent. If the second antecedent of a relationship is another relationship or a communication act then an include arrow from antecedent to the dependent will also be added to link relationships and communications acts that participate at the Use Case level. The following example shows how an Ontology Chart has been converted to a Use Case diagram.

Figure 2: The source Meta model

The above is a simplified Meta model that does not include any information about how the affordances are allowed to be connected with each other or any temporal data capabilities. This is because the focus of this paper is on the transformation of the Ontology Chart to Use Case diagram and not to how to accurately represent and evaluate Ontology Charts.

Figure 4: Ontology Chart to Use Case example

6.2

The target Meta model

In this transformation we used a simplified version of Use Case diagrams. The actor has a label of type string and can have many Use Cases. Each Use Case has a label of type string and can extend or include many Use Cases.

In the above example a person applies for a loan and an employee that authorize that loan. To summarize, Ontology Charts can be transformed to Use Case diagrams by the following rules: Agents will be transformed to actors.

Communication acts are transformed to Use

Cases with their label because the label of the Use Case followed by the word for and the label of the second antecedent.

Figure 3: The target Meta model

Use Case diagram will be used as the target Meta model. The next section describes the transformation.

Relationships with at least one agent as an

6.3

The transformation proper

The main idea is that agents and roles will be mapped to actors. All communications acts will be a

antecedent are transformed to Use Cases with their label as label of the Use Case followed by the words associated with and the label of the second antecedent. If the second antecedent is a communication act or relationship then an include arrow can be generated from the antecedent to the relationship and the label of the second

Error! No text of specified style in document.. Authors Instructions

antecedent will follow the label of the relationship. Relationships that do not fall under this category are ignored by the transformation.

CONCLUSIONS

Entities that participate as antecedents of a

relationship or communication act that also have an agent as antecedent will be transformed to text and be part the last part of the label of the Use Case.

Entities that do not fall under the above category will be lost during the transformation Determiners are transformation. ignored during the

The main benefit of transforming Ontology Charts to Use Cases is that Use Case can show the interaction between the users and the system. This paper proposed an illustrated a method and transformation rules for transforming Ontology Charts to Use Case. The key idea behind this transformation is that agents are transformed to actors, relationships and communication acts to Use Cases, entities to text and part of the label of the relationship or communication acts Use Cases and the determiners are ignored. Due to the incompatibilities of the two models a fair number of information is lost during the transformation. Further research could possibly limit the amount of lost information and it is the wish of the authors that other researchers in the area could build on this proposal and improve the transformation.

The above rules propose a general method for transforming Ontology Charts to Use Case diagrams but a lot of information is lost during this transformation. This is due to the nature of the Use Case that only captures the interaction with the system where the Ontology Chart captures the structure and the ontological dependencies of the system.

ACKNOWLEDGEMENTS
This work would have not been possible without the work of Ronald Stamper and Yasser Ades on MEASUR methods and Semantic Analysis. We would like to thank all those who played important role for development and testing Semantic Analysis and Ontology Charts.

LIMITATIONS

Some of the weaknesses of transformation of Ontology Charts to Use Case diagrams are as follows: It cannot identify extent associations and it can only deal with limited cases of include associations. It can only treat agents with communication acts or relationships associated with them. It cannot deal with agents that have another agent as their antecedent. It offers a limited treatment of entities as it only includes them in the transformation if they participate in a communication act or relationship with an agent. Any other association among the semantic units apart from the cases described in the proposed transformation is ignored. Last, the auto-generated text of the labels needs corrections. Hence with more research these weaknesses could be address and an auto-generated Use Case could show a simplified view of the system. Other UML2 diagrams such as sequence could be auto-generated since we can party auto-generate a Use Cases but more research is needed towards this direction.

REFERENCES
1. Ades Yasser. Semantic normal form: Compliance. University of Twente, 1999. 2. Yasser Ades, Farouk Ben Umar, Iman Poernomo, and George Tsaramirsis. Mapping ontology charts to uml class diagrams: an snf preserving transformation. In ICOS2007. University of Reading, 2007. 3. Yasser Ades, Manos Nistazakis Iman Poernomo Mohammad Yamin George Tsaramirsis, Navid Karimi. Implementing snf-compliant software: Mda and native technology. In Proceedings of ICISO 2009, pages 71,78. ICISO, 2009. 4. Anneke G. Kleppe, Jos Warmer, and Wim Bast. MDA Explained: The Model Driven Architecture: Practice and Promise. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 2003 5. Ronald Stamper. Knowledge as action: a logic of social norms and individual affordances, gowerpress. 1985.

Chapter Error! No text of specified style in document.

6. Ronald Stamper. Measur methods of theory and analysis of information systems. In Proceedings of IWRA 2008, pages 135-160, London, 2008. PEARSON. 7. Kecheng Liu. Semiotics in information systems engineering. Cambridge University Press, New York, NY, USA, 2000. 8.George Tsaramirsis and Iman Poernomo. Prototype generation from Ontology Charts. Information Technology: New Generations, ITNG, 2008. 9. Iman Poernomo, George Tsaramirsis, and Naibai Zheng. Coarse-grain architectures from business requirements:an organsational semiotics approach. In ICISO2009. Aussino Academic Publishing, 2009. 10. Mohammad Yamin Naibai Zhang Manos Nistazakis, George Tsaramirsis. Transformation of Semantic Analysis to com+ business requirements using mda approach. Journal of Service Science and Management, 2010. 11. Iman Poernomo, George Tsaramirsis, and Mohammed Yamin. Ontology based uml2 component architecture generation. In the proceedings of ICISO2010, 2010. 12. George Tsaramirsis, Bridging the Divide: Transforming Business Requirements into Component-Based Architectures PhD Thesis, Kings College London, 2011 13. OMG, UML superstructure, version 2.1.1. OMG document formal/2007-02-03, 2007. 14. OMG, Meta Object Facility (MOF) Core Specification, OMG document formal/06-01-01, 2006.