Object Oriented (OO)-method

The Object Oriented approach is well-established in the field of software development. The OO-method in the context of model driven architecture and development process is based on the idea of creating models that satisfy the OO-concept, which represents the business requirements accurately in order to obtain a high quality product. The main schema of OO-methodology with respect to model driven approach are as follows:

1. The modelling principles have to satisfy Object Oriented concepts and have to be defined in an accurate manner.

2. The traditional OO concept can be integrated with the formal and latest modelling concepts to create a high quality framework.

3. All the architectural layers and views represented by the models have to be represented accurately in the finished product and this can be done by maximising automation of code with the help of code generators. The layers may include static and dynamic aspects as well as the front-end.

The OO-concept merged with model-driven development well. Martin et al.[1994]. Its concept of agility is often used in the Agile methodology with its integrated platform,Qumer et

al.[2008]. This ensures rapid development to create user-friendly code satisfying current market needs. The two main phases of OO-based model driven development are: a) Conceptual mod- elling representing the problem; and b) Code Generation representing the solution. Figure 2.12 shows the OO-Method concept.

Model Creation Mapping Transformation

Requirements Conceptual Schema Application Model XXXX XXXX Application Code

Figure 2.12: OO – method concept schema,Pastor et al.[2007].

The following models are created by using the OO-method for MDSD, including some examples from my experience with C3systems:

1. Object Model – This represents the structure of objects and instances known as classes be- longing to the domain under consideration. This also represents the relationships between different objects and their service activators. For example, in C3system, targets and con- soles are object classes which can interact with each other. Whereas, a specific target with ID, is considered as an instance.

2. Dynamic Model – This represents the behaviour of the objects identified and the order in which interactions and events occur within the system. For example, a target is followed by identity creation.

3. Functional Model – This deals with the changes occurring in the system when the state of an object changes due to some action. For example, an enemy target disappears when destroyed.

4. Presentation Model – This deals with the concepts related to the presentation of the system in terms of views and user interfaces. The views are responsible for the way the user interface behaves and also for capturing the user interactions. For example, in a C3system, the airspace tactical maps is a view belonging to the presentation layer.

2.4.3.1 Key aspects of OO-method with respect to SA, SPs, and QAs

The main features of Object Oriented methods with respect to SPs and QAs are described below:

1. Any approach following the OO-method must ensure that all the information related to architectural and structural SPs present in the system must be captured and recorded accu- rately so that the correct components can be created using modelling methods. Also, the approach should capture the patterns in behaviour in order to enable the creation of proper expressive models. Therefore, these patterns act as the inputs for the creation of models. 2. After capturing the architectural information in the system, the architecture has to be doc-

2.4. MODEL DRIVEN APPROACHES AND ARCHITECTURE

umented in a precise order and the important patterns must be marked.

3. The use of OO Method for a specific SP that is related to a specific QA, will have an affect on the overall system’s qualities, as explained in Chapter 3.

According toPastor et al.[2007], patterns in the architecture are an important part of the product creation. These patterns must be studied and used well so that a high quality product is obtained. However, there are some problems associated with this approach.

1. First and foremost, there is a shortage of empirical data that supports the relationship be- tween architecture/designPatterns andQAs. Hence, obtaining measurable quality using these patterns is still a difficult task; although there is plenty of research that has been done in this area, such as the analysis of architecture styles workshop conducted byKim et al. [2006],Bass et al.[2013],_{Mistrı́k et al.}[2014].

2. Second, the quality and efficiency of the patterns are dependent on the environment and quality measurements. What may work well in one environment may not hold good for others. This leads to inconsistent results.

3. Third, sometimes patterns interact with each other through interfaces and it is not clear if the quality attributes of a particular pattern will apply to that pattern alone or be valid across interacting patterns as the implementation details may vary for each pattern.

2.4.3.2 Mapping OO-Processes to MDA-Processes

From the previous sections, it can be seen that OO-development phases are most similar to MDA-development phases, in order to produce high quality softwares with the help of trans- formation mechanisms and generators. This section will explore the relationship between the OO-method and MDA in order to examine the similarities between them and also the extent to which patterns are applied within their models.

The OO driven modelling approach is made up of 2 phases:

1. Conceptual Modelling – This involves the identification and creation of platform indepen- dent models known as PIMs in MDA approach.

2. Code Generation – This involves the generation of code from the models using transfor- mation techniques, which includes two steps as follows:

• Initially, the PIMs are converted into platform specific models or PSMs.

• then the PSMs are converted into source code for the application. The transformations define the mapping between PIM to PSM and PSM to code.

OO-method phases can be directly mapped to MDA stages,Pastor et al.[2007], as shown by Table 2.7.

Table 2.7: Analogies between MDA and the OO-method.

MDA OO-Method

Platform-independent model (PIM) Conceptual Model Platform-specific model (PSM) Application Model

Implementation Model (IM) Application Code

PIM-to-PSM transformation Mappings

PSM-to-IM transformation Transformations

2.4.3.3 Extra features of OO-methods missing from MDA

There are certain features in the OO-methodology that cannot be directly mapped to MDA. According to theKleppe et al.[2003b], PIMs may often contain all the information necessary to generate the application code, thereby eliminating the need for any extra information. Whereas, the OO-method is more definite due to the fact that the Object-Oriented Administrative Systems- development in Incremental Steps (OASIS) specification language provides a very precise plat- form which means that the OO-models contain complete information needed for code generation each and every time as opposed to sometimes.

Another difference between the two approaches is that in the case of MDA, whenever the PIM contains all the necessary information, the PSM becomes obsolete and is no longer required. In such cases, the code can be generated directly from the PIM, Pastor et al.[2007]. On the other hand, in the case of OO-method modelling, it is necessary to define an application model which is platform specific and this cannot be bypassed even though it is not mandatory for the application model to be revealed. This difference goes to prove that the MDA PIMs contain some level of platform details required for code generation which means that they are not platform independent. Whereas, conceptual models generated by the OO-method are completely platform independent. This implies that the OO-method models can be run on any platform accurately.

Overall, this means that the models generated using the OO-method are complete entities by themselves which contain all the computational information necessary for code generation and it is possible to create complete systems with these models without the need for any other predefined elements, such as libraries and controls,Pastor et al.[2007].