At present time a very big progress proceeds in all branches of the software engineering eld. Anyhow, one particular area is not under the enhanced focus of software developers and researchers. It is the area of the GUI formalization and modelling. The aim of our article is to overcome this deciency by the suggestion of lightweight formal method for the design of user interface by the GUI modelling based on the graph transformations of underlying conceptual data model. The proposed method gives us a very visual tool for our objective. In addition, our method is an innovative and original specication and modelling technique targeted primarily for a utilization of large and complex modern-day web based applications.
The aim of our article is a suggestion of lightweight formal method for the design of user interface by the modelling of the GUI based on the graph transformations of underlying conceptual data model. The particular problem resides in an insucient methodical support for the user interface design phase. Notwithstanding, that exist some user interface design methods; none of them is based on a conception of deriving the user interface schemes from the conceptual data model specications. This conceptual deciency makes a semantic gap between the database content and information presented by a user interface.
In this contribution we intend to demonstrate an alternative formal approach how we can compose a user interface model scheme as a result of transformations from the conceptual data model scheme. Our method is based on formal descriptions of user interface and conceptual data models and set of rules describing how to set up the resulting GUI with relevant and valid data. This approach allows constructing only the correct graphics user interfaces. This is the main advantage of herein presented method. Furthermore, the approach presented in our article is a very important for the design of sophisticated web based information systems in consideration the fact that quality of this kind of applications is strongly joined with the well-designed user interface working in cooperation with a complex database system. The issues addressed in this article, inter alia, include:
The description of our method.
The denition of conceptual data model.
The denition of logical data model.
The denition of user interface model.
The description of the transformations between the models.
This paper is structured as follows: Section 2 discusses alternate approaches to formal specications of user interface with reference to the utilization of graph transformations method. Subsequently, Section 3 introduces our approach and sections 4, 5 and 6 are concerned with the formalization of conceptual, logical and user interface model, respectively. Section 7 introduces the suggested transformation, i.e., the essential part of our work. Section 8 briey describes an AGG, i.e., the open graph transformation tool we use to realize and test the proposed graph transformations. Finally, section 9 proposes some conclusions and an overview of possible future works. 2
Up till now only some few works has been made on the formalisation of the
user interface. However, they do not result from the idea of feasibility to derive
the user interface model from the underlying conceptual data model. The
author method proposed in this paper is based on his prior works [
Another approach of the user interface formal specication and design has
been published in [
Further, the graph transformations utilization has been inspired by the works
[
Furthermore, our work is closely joined with approaches engaged in the web site development as well. Almost all web methods propose a technique for the user interface design. The insuciency of this approaches consist in the unsatisfactory interconnection between the user interface model and the underlying data model. The majority of these web methods only focus in deriving of the navigational model from the underlying data model, but that methods usually are not concerned with the type of the derivation proposed in our contribution.
The proposed approach by us is a very intuitive. Almost all GUI developers have a sense that there is a strong connection between the particular components of GUI and the data from the database system represented by these components. The way of interconnectivity of the data in a database system predestines the interconnectivity of the relevant components of GUI as well. The underlying database scheme determines not only the interconnectivity of GUI components, but their mutual behaviour and style, with respect of possibility to display singlevalued or multi-valued data, as well.
The interconnectivity between the components of GUI may be express by a model. Regrettably, there do not exists any generally accepted model yet. The proposed model used in this work is based on the graph theory. The model of GUI is not only a segment of data model of the underlying data, not even a model of GUI components separated from them. The model proposed by us is a model both independently designed by developer and derived from the underlying data as well. In other words, at developing GUI, the developer is restricted as well as conducted by underlying data. Our idea is symbolically illustrated by Fig. 1.
The general concept of our approach consists in the following three basic steps:
The transformation of UML conceptual data model into the relevant graph representation.
The simplication of conceptual data model into the logical data model.
The interactive and incremental construction of the GUI model. The resulting model of GUI may be used for the smart generation of GUI components by means of developer IDE or for a construction of SQL or other DML commands for the GUI components data lling eventually.
Reason for the utilization of the graph based model approach consists in the
possibility to use the graph transformation method in order to transform them.
This method is very advantageous for us by the reason that provides a powerful
tool for the construction of transformation grammars with the respect to the
inspectional and comprehensible visual view of the generated transformation
rules. Eventually, the graph transformation method has a robust and conrmed
fundamentals based on the graph theory[
Indeed, in subsequent chapters rstly we made denitions of the conceptual and logical graph based models and the graph transformation between them. Secondly, we dene the proposed GUI graph based model as well. And nally, we describe our algorithm for the construction of the GUI model from the logical model based on the graph transformations rules. 4
This section gives a brief description of the conceptual data model ( CDM ) we used in our method. The CDM considered in this work is composed of following concepts: class, attribute and association ( generalization-specialisation, part-whole and relationship ) in the usual sense and compliance with the object oriented modelling paradigm.
(a) Type graph of CDM.
(c) Type graph of UIM. (b) graph LDM.
Type
of
The Fig. 2(a) shows the type graph used to describe our CDM. In this type graph each node represent a class or attribute and each edge represents one of the three types of possible associations ( generalisation-specialisation, part-whole and relationship ). This particular type graph contains nodes of type c and a; and edges of type gs, pw, rs and ao. Nodes of type c represent classes and nodes of type a represent attributes. Edges of type gs represent generalisationspecialisation associations, edges of type pw represent part-whole associations, edges of type rs represent relationship associations and edges of type ao represent attribute ownerships between the class and its attributes. However, we do not use the concept of attribute temporarily. The type graph represents a condition which must be fullled by all correct graphs that could be constructed. (a) UML class diagram. (b) CDM graph
As an illustration, we demonstrate our ideas by a simple example representing a part of the real world. Our problem domain forms a part of a university information system consisting of courses, time-tables, students, lecturers, teaching rooms etc. The corresponding conceptual data model scheme in UML notation is shown in Fig. 3(a) and the corresponding graph representation in Fig. 3(b). It is evident; we use a directed, typed, attributed and labelled graph. A shorthanded name of the particular class in the corresponding UML diagram is written into the circle representing a node in the resulting graph diagram. The letter c represents a course, t represents a timetable, r represents a room, s represents a student, p represents a person and l represents a lecturer. All nodes in our resulting graph represent only one type allowed in the corresponding type graph the class. The edges are marked by its type and we use the following shorthands: gs represents a generalisation-specialisation type, pw represents a part-whole type and rs represents a relationship type. The nodes joined by relationship type may have a dierent cardinality (a participation in the relationship) and we mark these edges by cardinality value as well. The cardinality of the relationship edge means a count of possible occurrences of the instances of both classes from either sides of the particular edge. The possible values of relationship cardinality are dened by the set: (1; 1); (1; M ); (M; 1); (M; N ). The letters M and N are used as a symbolical count with denotative meaning many.
(a) CDM to LDM (b) change of cardinality
(c) LDM to UIM
For a proper design of GUI we only need to know the cardinality of associations. Because of the simple reason that various meaning of dierent types of associations disappears in the context of GUI, i.e., we do not need a precise distinction between them in subsequent text. Class attributes can be omitted temporarily from our model as well, due to the fact that the described transformation proceeds only at the level of classes and associations between them. In other words, we do not need to transform attributes. Thus, the type graph for our logical data model is shown in Fig. 2(b). It is evident that we use only one type of labelled nodes the class and one type of edges marked by cardinality the general association. The transformation rules for the transition from CDM to LDM (Logical Data Model ) in commonly used notation are shown in Fig. 4(a).
It is evident that all semantic information about the dierent types of associations is lost. But, this fact is not too restrictive, because in herein presented method we do not use this semantic information; it is our intent at this moment. In our subsequent work, we intend to propose a more complex transformation method without a loss of the type information. Thus, in our method we omit the type information from the resulting graph and mark edges only with its cardinality by reason that all edges possess only one relationship type the general association.
(a) LDM graph (b) UIM graph
The resulting graph of our example is shown in Fig. 5(a). It is apparent that original and resulting graphs can be a cyclic and doesn’t create a tree. Also, the value of cardinality depends on the selected direction we choose. Finally, we can change orientation of edge cardinality by a simple transformation dened in Fig. 4(b). 6
The main idea embedded in this work jointly involves the formalisation of the user interface model (UIM) and the denition of the graph transformations rules in order to derive UIM from LDM. Now, we may dene the UIM by means of the following rules.
Only the components of user interface which correlate to the data model (modelled by LDM, respectively CDM) are relevant.
All components of user interface can display only one value or a list of values. All associations between the user interface components are derived from the underlying LDM.
Further, we explain the attributes of the user interface model (UIM) related to our method. First of all, we need to dene a few new concepts needed in the subsequent work.
Data Model Dependent Area (or Data Area for short). The concept of Data Model Dependent Area presents a set of user interface components bounded together by a conjunctive dependency on underlying data. Change of data focus of one component can change a data focus of other components. Our work concerns about a proper design of just one Data Area.
User Interface Component (or Component for short). The concept of User Interface Component presents a visual component of user interface which has a visual representation on the screen. User can change the visual presentation of such component, but not its data content.
User Interface Data Component (or Data Component for short). The concept of User Interface Data Component presents a subset of User Interface Components bounded to underlying data. The set of such Data Components forms a Data Area that was hereinbefore dened. Our work concerns only such data components.
Data Component Class Area (or Class Area for short). The concept of Data Component Class Area presents a specic subset of Data Components bounded to exactly one entity in the underlying data model.
Data Component Same Multiplicity Area (or Multiplicity Area for short). The concept of Data Component Same Multiplicity Area presents a specic subset of Data Components having the same multiplicity. We will discuss this concept as well as concept of multiplicity in detail later in this article. Let us use the following labels for hereinbefore dened concepts; DA for data area, C for component, DC for data component, CA for class area and MA for multiplicity area. We may express the concept relations between them as 1: (1) (2) C; DC
MA
CA
DA
DC . C Let’s consider the following denitions of subsequent concepts.
Multiplicity of data component (or Multiplicity for short) is a capability to display a single value or list of values or list of list of values and so on. We will denote a multiplicity by count as a superscript associated with the particular data component. The multiplicity equates to 0 means possibility to display a single value, equates to 1 means possibility to display a list of values and so on. 1 We used a symbol . for concept of inheritance or generalization - specialization. The term A . B we read as A is inherited from B or A is a specialization of B . Dependency of data components means an abstract association between the data components laid within the particular data area. Changing the data focus of one component changes the data foci of other components. Every data component in the particular data area can be mapped to the single entity attribute in the underlying data model 2.
Dependency of class areas means an abstract association between class areas corresponding to the data relationships between entities in underlying model. Changing the data focus of one class area changes the data foci of other class areas. Every class area in the particular data area can be mapped to the single entity in the underlying data model.
Multiplicity of dependency of data components or class areas (or Multiplicity of dependency for short) is dened as an ordered pairs of numbers denotative the multiplicity of corresponding data components. It is evident, that multiplicity of dependency may take the value from the set: {(1, 1), (1, M)}. Multiplicity of dependency between the data components from a particular class area will always equate to the value of (1, 1). This is the reason why dependencies of data components from the particular class areas are not so important for us and so we can only deal with the dependencies between a dierent class areas. By reason that all data components from a particular class area have the same multiplicity, we can dene a multiplicity of particular class area as follows.
Multiplicity of class area equates to multiplicity of its data components. The type graph of our UIM is shown in Fig. 2(c). The type graph contents the nodes of type cai and cai+1 and edges with multiplicity of (1, 1) and (1, M). The nodes of type cai and cai+1 represent the class areas of multiplicity i and i+1 respectively. The edges of type (1, 1) and (1, M) represent the dependencies of class areas with the multiplicity of dependency equates to (1, 1) and (1, M) respectively. Further, the type graph represents a condition, which must be fullled by all correct graphs that could be constructed. It is good to note that for any LDM can be constructed as many UIM as you like. 7
The last phase of our method deals with the generating of UIM from LDM. We must to note that our utilization of the graph transformations is done by a somewhat dierent way as is customary. The graph transformations are usually used to transform a particular graph from the source form to the target form. We use the graph transformations to build the UIM graph by inference from the LDM graph. 2 In this contribution we do not consider derived (calculated) data components. This concept will be a subject of our future work.
The transformations may be described by the following pseudo algorithm: 1. Select the initial node in the LDM graph. 2. Add the selected node as the initial node in the new built UIM graph. 3. Mark the selected node as a new starting point in the UIM graph and simultaneously as already used node in the LDM graph. 4. REPEAT (a) Select another node in the LDM graph, which is in an incidence relationship with an arbitrary node marked before as used. (b) Change the direction of a relevant edge by using the appropriate graph transformation rule (Fig. 4(b)) if necessary it is. (c) Transform the just selected node and the corresponding edge by using the relevant graph transformations rule (Fig. 4(c)) and insert this node and relevant edge to the new-created UIM graph. (d) Mark the last selected node and the edge from preceding step as already used in the LDM graph. 5. UNTIL you need.
The key part of hereinbefore presented transformation lie in the step 4-c and can be expressed by means of the following simple rules:
If the direction of the edge is from the node of multiplicity i to the node of identical multiplicity we use the upper transformation rule shown in Fig. 4(c). If the direction of the edge is from the node of multiplicity i to the node of multiplicity of i+1 we use the bottom transformation rule shown in Fig. 4(c). Further, we may demonstrate the presented approach by a simple example shown in Fig. 6 as an explication of the algorithm described hereinbefore. The example is broken down to the single steps, labelled from 1 to 4. Furthermore, the resulting UIM graph of a little bit more complex example is shown in Fig. 5(b). Finally, another illustrations of the presented approach, the corresponding graphical representations of the user interface screens of these two demonstrated examples are shown in Fig. 7 and Fig. 8. The concepts of class area and multiplicity area are outlined in these examples as well. We need to note that an arbitrary node or an edge can be used in the step 4-a a number of time in the course of utilization of our algorithm. We break up cycling of the algorithm in the case when all nodes we required to process acording to our demand will be placed into the resulting UIM graph as we need. 8
AGG3 - the used graph transformation tool One of several improvements that have been achieved over the last year has been selection and utilization of the particular graph transformation tool. In order to continue our work we need a good tool facilitate experiments with ideas proposed in our work. Foremost we stipulate a few requirements. 3 The AGG is an acronym for Attributed Graph Grammar.
We have chosen one of the following tools:
AGG The Attributed Graph Grammar System a simple and powerful
tool developed at the Department of Software Engineering and Theoretical
Computer Science in the Technische Universitt Berlin[
AToM3 A Tool for Multi-formalism and Meta-Modelling another
powerful tool developed at the Modelling, Simulation and Design Lab (MSDL)
in the School of Computer Science of McGill University[
Groove GRaphs for Object-Oriented VErication, a simple and modern
modelling tool developed at Department of Computer Science, University of
Twente[
Fujuba - A large Eclipse based project developed at the Software Engineering
Group in the University of Paderborn[
At present time we elaborate with the AGG tool we have chose because fulls our conditions mentioned hereinbefore. We may demonstrate this excellent tool by a few gures from our last work. A scheme of the example used in this article is shown in Fig. 9 and the graph transformation corresponding to the transformation from Fig. 4 is shown in Fig 10.
It is evident that in Fig. 9 is shown the same situation as in Fig. 3(b) only with some dierences. The name of the node corresponding to the name of the class in the source UML class diagram is added as a node attribute name into the diagram. The attribute of edge named cardinality is added as well. These attributes are used by the AGG tool in subsequent graph transformation steps.
The Fig. 10 illustrate an example of one graph transformation as it is dened by the AGG tool. The left side of the gure shows the graph pattern searched in the source diagram and the right side shows the graph pattern replacing the just found pattern in the source diagram. In course of the transformation the relevant node and edge attributes are transformed as well. It is evident that the AGG tool provides all needed features, e.g., types, attributes and calculations, for the next development of our method.The AGG tool oer an easy and comfort way for the graph transformation handling. At the present time it is our favourite tool, though our searching for an appropriate tool is not denitely nished.
The proposed formalization is based on the graph transformations theory [
A good theoretical foundation based on graph transformations.
The possibility to verify correctness of the resulting user interface scheme. However, this work is not a nished yet and we used the very basic model of possible user interface. Thus, for now, we must consider following disadvantages as well.
We work only with a few basic elements of user interface.
We must do a lot of work on the development of an appropriate graph transformation tool.
In conclusion, our lightweight formal method intended for deriving the user interface schemes by graph transformations from the conceptual data model specications is not fairly good yet. We are convinced that the algorithm described in the preceding section has to be more detailed, formally and purely specied.
Consequently, our future objectives consist in an improvement of our formalization concept and transforming algorithm. Subsequently, we want to use all semantic information from the source conceptual graph for the construction of proper user interface. Next, we must a complete a software tool supporting hereinbefore proposed transformation. Finally, we intent to work on the specication of the rules for the construction of relational algebra queries or in other words, on the construction of the SQL select statement in order to automate the code generation of corresponding applications.
This research (work) has been supported by Ministry of Education, Youth and Sports of Czech Republic under research program MSM6840770017.