Whereas the above considered approaches used in model transformation, below we consider general modelling approaches in software engineering. We select those approaches which bear some affinity with model-driven engineering.
2.4.1 Object-Process Methodology (OPM)
Object-Process Methodology (OPM) [31] is regarded as a holistic approach for system develop- ment. It is supported by a CASE tool (OPCAT) [90] for enabling the generation of complete systems from specifications. It integrates the object-oriented and process-oriented paradigms to introduce a single-view MDE approach. This approach produces a size-wise (fewer lines) code in contrast to other approaches based on UML models. This is demonstrated in the comparison between the UML CASE tool Rhapsody [51], invented by ILogix, and OPCAT [90] tool proposed in [96].
In a multi-view approach, the generated code from each view is limited and represents a partial code that needs be filled by further details generated from other views. This might cause inconsistencies in the code output by different generators, as well as causing incompetence of generated behaviour. OPM [31] tries to tackle this issue due to the crosscutting representation of the system specifications using multiple views. This is achieved by providing a complete model of a system in a single model (view) [96].
The OPM [31] model consists of a set of interconnected OPM [31] concepts or entities, rep- resented graphically via a workflow-like Object-Process (graph) Diagrams (OPD), and textually via a dual-purpose and natural-like Object-Process Language (OPL) based on context-free gram- mar [60]. The metamodel introduces two general concepts (things with states, and links). The thing concept is to represent an object or a process, and the link is used to express structural or procedural connections between things to connect objects to processes. Processes are considered as transformation behaviours for translating objects [60]. Therefore, it can be argued that OPM [31] has a notation that combines static and dynamic aspects of the system in one view, which facilitates generating a complete code at the end rather than code skeletons [96].
OPM [31] has its refinement/abstraction mechanisms that enable the representation of a complete system at different levels of abstraction without losing the overall consistency of its internal components. These techniques are applied to OPM [31] entities as follows:
• Folding/unfolding mechanism for refining/abstracting the structure hierarchy of OPM [31] objects.
• In-zooming/out-zooming for hiding/exposing the inner details of OPM processes. • State expressing/suppressing for hiding/exposing the state of OPM objects.
As the OPM methodology [31] is supported by a CASE tool (OPCAT) [90], the OPM-GCG is the generator component for generating generic code. It consists of two main parts, namely, Template for Implementation Programming (OPCAT TIP), and Implementation Generator [96]. The OPCAT TIP enables users to encode transformation rules in a language-specific tem- plate (Template and Translation DB). The translation is expressed imperatively as an ordered set
of operations that contains conditions and actions (Event-Condition-Action (ECA) paradigms). The TIP then generates corresponding XML [122] files. These XML [122] documents are used as inputs to the Implementation Generator [96].
The system uses the underlying representation of the OPM model, which is an OPL-XML [122] script (automatically generated from the graphical notation OPD), with a template to cre- ate the actual system, including UI, code, and database schema. The Implementation Generator takes a language-specific OPL template and OPL-XML [122] scripts as inputs, and captures the match between corresponding elements. It executes required operations, and then generates programming languages encoded into XML [122] format. The next step is parsing these out- put XML [122] files of the system, which is based on user preferences to select transformation options: code (e.g. Java), mark-up (e.g. HTML), or comment [96, 31].
2.4.2 Pure Object-Oriented Method
It is a widely-recognised that a multi-view modelling approach is adopted by various development methodologies and tools, such as the Model-Driven Architecture (MDA) [89]. Generally, in the UML-based approach, each UML [70] model is used for representing a system from a different angle; for example, the approach proposed earlier by Chow et al. [20]. is regarded as a two-stage multi-view MDE approach for generating Java code based on five UML models [70], namely, Class, Component, Statechart, Sequence, and Activity diagrams. The approach captures the static structure of a system at the first stage and then adds the behaviour in the second one [20].
Rhapsody [51] by ILogix is another example that is able to generate partial behaviour of a system. It uses the UML Class and Statechart [49] with translation rules for generating the system, the UML Interaction diagrams to define objects and their interconnections, and the UML Use case and Activity diagrams for analysing and documenting the system [96]. In both examples, it can be argued that maintaining the consistency between these UML views (models) is not a trivial task.
ZOOM Approach
ZOOM separates software modelling into three components: the structural, behavioural and User Interface (UI) models. This separation of concerns allows each aspect of the system to be specified separately, and makes it possible for us to use an appropriate formal specification language to specify each of these unique aspects. The Structural model is defined formally, and visually represented by UML 2 class diagrams. It is completely separated from the other aspects. Besides this, the Behaviour model is regarded as a communication component that links the structural model with the UI model. It is formalised using state diagrams. It is represented visually using a UML 2 Statechart diagram, and textually using a UML 2 Finite State Machine (FSM) that contains rich syntactical grammar with formal semantics. Therefore, the behaviour model will consist of a number of FSMs for different user behaviours. The changes (transitions) from one state to another are based on user inputs and commands.
ZOOM uses a separate model for representing the UI. As a result, any change of the interface specification will lead to a change in the UI models only without any crosscutting effect in other types of model. The UI model is formally defined using pre-defined XML [122] schemas ZOOM- UIDL as a textual and concrete syntax.
2.4.3 Integrated Methods
The examples mentioned above are based only on the OO method for modelling system specifica- tions. Several attempts have been made to integrate the OO method with the Process-Oriented and Structured (Functional) Methods to enable better and more comprehensive capturing of the system specifications at the design level. Here, we consider some of them to show how this integration contributes to the MDE strategy.
FOOM Approach
Functional and Object-Oriented Methodology (FOOM) is an analysis and design methodol- ogy for developing Information Systems (IS). It combines two well-known software engineering paradigms, namely, the OO approach and the Functional approach. FOOM aims to cover the structural and behaviour representations of ISs [60].
FOOM adopts the ADISSA methodology (Architectural Design of Information Systems) that extends the Structured Analysis Methodology, during the analysis and design stages. ADISSA is used to extract: (a) menu-tree interface, as an external view of the system to users, and (b) system basic transactions, as an internal view to represent the user interaction with the system via different events. In addition to this, (c) database schema, and (d) system Input/Outputs are also obtained from above using the ADISSA method, which is supported by a CASE tool [60].
The analysis phase of FOOM produces a data model and a functional model. The data model is noted as an initial class diagram without methods. It represents only real-world data entities derived from the requirement analysis stage. The detailed methods will be added later in the design phase. The functional model is considered a hierarchical Object-Oriented Data Flow Diagram (OO-DFD) that includes initial classes instead of data stores (external entities). It is used to specify the functional requirements of a system. Like traditional DFD, the OO-DFD consists of a number of functions (decomposable and elementary), and external entities (e.g. user, time entities) [60].
The design phase produces a complete class diagram and user interfaces (UIs) based on the ADISSA methodology. The class diagram contains detailed descriptions of methods, including input and output screens. This phase is organised in sub-levels, one for extracting system transactions from the OO-DFD model. Each transaction contains a chain of functions and external entities to perform a particular process of the system. This will produce the detailed descriptions of the transaction-methods (high-level descriptions) attached to classes. The process logic of transaction at this level is expressed textually using standard structured programming such as pseudo code, or visually using message charts [60].
The next step is constructing a menu-tree interface that is derived from the OO-DFD (the second level according to ADISSA methodology). A menu item is created for each function connected to a user entity and attached in a parent menu forming a hierarchal menu tree. A generic class Menu will be added to the Class diagram, and all extracted menus become objects of it [60].
Input and output screens are designed in the third step. For each input/output command in the high-level descriptions of transaction, there is a form and report screen respectively. Generic form and report classes will be added to the class diagram and all form and report screens become become instances of these classes. Then behaviour methods are designed in the last
(fourth) step by converting the high-level transaction descriptions into a detailed description of methods, such as CRUD operations [60].
MOSYS Approach
In addition to this, MOSYS is another integrated approach that is aimed at the construction of Distributed Real-Time Systems (DRTS). It combines the functional and OO methodology and uses UML [70] with an extended DFD (E-DFD) in order to enable the automatic identification of objects and classes from high-level specifications. The components of E-DFD are weighted processes and weighted attributes. The weights are used to model the time constraints and complexity of processes [13].
After identifying the entities that interact with the system, a use case model is created to describe the system functionality. Then activity diagrams or E-DFDs are used to model the use case functionality. Then the functional model (e.g. E-DFD) is mapped into a graph that consists of edges and tasks (nodes). Based on clustering criteria, different object identifications might be obtained [13].
Besides that, [38] a practical technique in integrating notations of UML [70] and the DFD is proposed that aimed at the development of embedded systems. The combined approach is introduced as a part of an MDE process in which a system is modelled using different views; model transformations then force the integration rules between these views. In this approach, the designed DFDs can be transformed into UML object or class diagrams according to the transformation algorithm.
The development process consists of a series of mapping between different models (views). It starts decomposing each use case of an embedded system into three objects: data, control and interface. Therefore, a transformation step is performed on the use case model to produce an initial object diagram (IOD) including refactoring processes on it. Then the data flow model is obtained from the initial object diagram representing different details of the system. This step involves specifying data stores and processes, and identifying the connection between them [38]. Then an object-oriented model is derived from the constructed DFD using one of the following approaches:
• Applying a direct mapping to an object diagram, in which processes and data store will be mapped into objects.
• Applying advanced mapping into a class diagram, which classifies processes and data stores within the DFD based on their type. Processes become logical methods, whereas each data store is translated into a separate class.
DFD net Approach
Another novel approach has been introduced by [113] to complement the OO method with functional decomposition for realising uses case using extended DFDs (DFD net) at the analysis stage. This means that all processes and data flows are transformed into OO classes, including attributes and operations, at the design stage.
In DFD net, a distinction between various data flows has been considered. For instance, distinctions between main-input, inter-process, and non-inter-process data flows are made using double-solid, single-solid, and single-open arrowhead respectively. The process starts by specify- ing a main-input data flow for a collection of primitive processes in the lowest-level DFD net and connecting them with a local buffer to form a single group. Similarly, processes that share the same data as input or output are grouped together, then classes are generated for each separate group. The development process at the design stage is automatable and supported by a tool to perform transformations [113].