Model driven software development

Over the years, several different approaches have been adopted by the software community towards the design and development of software systems. Although each approach has its advan- tages and disadvantages, concepts like abstraction and object orientation have always remained in vogue. Recently, the focus has been on a new approach towards software development which utilises models to create and support software development. This is known as Model Driven Architecture (MDA), which manifests itself in several forms. The main advantage of MDA is the high level of abstraction and platform independence achieved by the use of models, thereby eliminating any tight coupling with specific programming languages.

The general common manifestation of this approach is Model Driven Software Develop- ment (MDSD), which is implemented in different ways in several domains. MDSD is considered to be a more accurate way of describing MDD and its use has increased dramatically in the last few years, Stahl et al.[2006],Pons et al.[2012]. All the model driven approaches are bound to concepts like Object Oriented Methods and UML. In almost every kind of model driven ap- proach, initially a domain model is created which is then translated into a meta-model, then converted into code generally by using some kind of generator,Rech et al.[2009]. The genera- tion of models can be done with the help of a language like Executable UML (X

2.4. MODEL DRIVEN APPROACHES AND ARCHITECTURE

focuses on semantics and helps people utilise existing knowledge repositories to create precise systems. To identify the ways in which the various modelling approaches vary from each other is beyond the scope of this thesis; however, several valuable research studies exist, seeRech et al.[2009], and the MDA official website.

The most important common factor among these approaches is that all of them use stan- dardised notations to create models, then to generate code from those models. Also, patterns are actively used by all these approaches within the context of models and the corresponding generators to aid in the process of development. For instance, X_TUML is very helpful in do- main specific modelling. Within a software system, there are several domains and sub-domains each performing a different function. For example, service domains are used for security and networking, application domains provide the context to run the actual application, architecture domains deal with the architectural decisions and so on. The abstraction of the domain is not dependent on the underlying implementation details, andX

TUML can be used to create different abstract models for each of these domains with the help of elements like class diagrams and domain charts,Mellor et al.[2002]. According toFowler[1997], under theX_TUML approach, UML behaves like a normal compilable programming language.

Furthermore, in each of the model driven approaches, styles/patterns form an integral part and are used extensively. Also, Domain Specific Modelling Languages DSLs are used for model development.

As mentioned earlier, MDSD is an effective software development approach that speeds up the software development process. It creates compact, precise, high quality models which vary between semi-formal and formal, based on stakeholders needs. The created models have a direct mapping with the code which is generated using them, and form an integral part of the software system. The focus of the created models is to solve the domain related problems. Hence, the choice of programming language is unimportant, thereby allowing higher levels of abstraction. This holds well, not only for MDSD but also for other model driven approaches irrespective of the domain,Stahl et al. [2006]. Some of the main advantages of the MDSD approach are described in Table 2.5 and it can be seen that MDSD provides various advantages in terms of cost, time and effort, irrespective of the domain and technology. However, identifying domain and models types is a very important aspect of MDSD and will be explored further in the next section.

Table 2.5: Advantages of MDSD

Aspects Economic Benefits

MDSD Adapting new business requirements is cheaper.

properties Adapting new technologies is cheaper.

The entire software lifecycle cost is reduced.

It’s advantageous in terms of cost, effort, time etc increases it’s business value.

Expert knowledge, availability and

Focus is on domain knowledge as compared to technical knowledge, since domain knowledge is more important from the functionality perspective.

usage Technical knowledge is integrated into MDSD platforms by experts so that

it can be used by developers during application development.

Due to the ready availability of technical knowledge, fewer experts are needed for technology consultations.

Business knowledge is captured by models and technical knowledge is cap- tured by platforms. Due to these integrations, knowledge repository is avail- able during the entire project life cycle.

Software Development and implementation time is reduced.

development Newer technologies can be adopted through automation.

automation Due to automation, speed is increased and requirement for manual interven- tion reduced.

Marketing time is less. Creating high Overall quality is increased.

quality applications The non-functional QA related to infrastructure is clearly segregated from functional code thereby making it easier to adopt new technologies. Due to automation, the number of bugs is reduced and hence the mainte- nance of systems is much easier, in terms of technology and architecture. Maintenance and rework is reduced and hence client satisfaction is high.

Extensive decou-

pling of technologies

Since technology is captured by platforms and transformations, it is not tightly bound to the application and hence changes to technology do not reflect in application model changes.

Every time a new technology is adopted, it needs to be mapped to the plat- form once, then it will be available for future use.

which will increase business value. Use of formal

application models

Any changes or enhancements are captured via models thereby saving the application and infrastructure from disturbances.

Since the software specifications and design are not dependent on the tech- nology, the model is more robust and consistent irrespective of underlying details.

There are several levels of model maturity that may apply during model development. Each of these levels has a set of characteristics with respect to the specifications and approaches.

According to the model development level descriptions proposed byRensink et al.[2006], I have mapped those levels into the formality levels presented in Table 2.3, which help to visu- alise and compare both characteristics, in order to help precisely set the target of the notations formality and models maturity during architecture description, based on the business needs, as illustrated in Table 2.6 .

Regarding software patterns, they are a means of solving software problems which occur repeatedly in different scenarios. The solutions for such problems involve the creation of good architecture and/or design descriptions by skilled and knowledgeable architects and designers. When recurring problems can be solved with the help of these designs, they become known as best practices which eventually evolve into established patterns. Patterns are most useful at

2.4. MODEL DRIVEN APPROACHES AND ARCHITECTURE

Table 2.6: Mapping (Rushby1993b) formality levels into the model maturity levels byRensink et al.[2006].

Rensink and Warmer Maturity levels

Rushby’s Formality

levels Model Maturity Level 0: no specification.

Not Applicable

(N/A)

Model Maturity Level 1: some text specification. (N/A)

Model Maturity Level 2: specification is text along with diagrams. 0

Model Maturity Level 3: specification is mainly diagrams with some text. 0

Model Maturity Level 4: specification characterised by precise and accurate models. 1 Model Maturity Level 5: complete modelled specification, only containing models. 2 & 3

higher abstract levels. They can be used in one single abstract layer (for example, architecture patterns, or implementation patterns) or they can span across multiple abstract layers (for exam- ple, patterns which involve a combination of architecture and design, such as Layer or Pipe-Filter styles). The MDSD approach uses patterns extensively and the application of patterns can be automated. Whenever newer elements are created, the existing elements are also modified in such a way as to remain in-sync with the patterns used. For example, in an architecture using the Pipe-Filter family, whenever a new element is created and attached to the family using ACME- Studio (as the modelling tool), this new element conforms to the existing patterns which have been used within the family. This pattern conformance feature is an advantage of this approach. MDSD is a powerful modelling approach which has a variety of features and characteristics.

More information and brief summary of MDA advantages and disadvantages is illustrated in two figures, in Appendix B and Section B.2.

2.4.1.1 Importance of domains in MDSD

Any system can be described by a combination of domains, and domain identification is a crucial part of the MDSD approach. A domain refers to a particular knowledge spectrum with boundaries. It is an independent unit made up of several relevant elements which also belong to that particular area of knowledge. The entities or elements of a domain depend on the ex- istence of other entities in the same domain, but are independent of the entities’ existence in other (external) domains, unless it is linked to that other domain. However, any domain can use the functionalities of other domains and can similarly provide its own functionalities for use by other domains. Also, domains could be real or imaginary and each domain has a set of af- fected behaviours associated with it,Mellor et al.[2002]. For example, the surveillance domain (Radars) within Command, Control, and Communication (C3) systems provides functionalities to the (Weapons) domain, like target information (speed, coordinates, etc.), through the logic domain (C3) main processor.

The same situation applies in C4I systems, where, for example, Air Operations Centre (AOC) as (a mission-planning domain) publishes its missions to database (another domain).

This database is accessible by Air Tasking Order (ATO)/Airspace Control Order (ACO) (as another domain) that encompasses thousands of sorties/ missions and a very large amount of related information. The Operational Unit (as another domain) subscribes to ATOs. An ATO can be edited so that the Unit views only those missions assigned to it.

Before embarking on an application development life cycle, it is important to identify and segregate the domains that will make up the system as a whole. Generally, software systems are made up of the application domain (e.g. an e-commerce site, such as Ebay), technology do- main consisting of the technologies used in development (e.g. Java and J2ee), database domain consisting of the database providers (e.g. SQL and Oracle) and any other middle layer domains which may be relevant to the application, like message frameworks, user interfaces and business processes,considering the fact that sometimes architecture is considered as a domain by itself. While identifying the domains, it is necessary to define clear functional boundaries so that each domain represents a specific purpose through the entities making up that domain. For example, an e-commerce site (e.g. Ebay) represents an application residing in a domain and made up of entities like orders, payments and rules. Similarly, a graphical user interface has entities, such as windows and forms, with functionalities deciding the application behaviour on actions like click and hover. Domain partitioning enables the segregation of application from underlying implementation details thereby allowing creation of layered models. Once the domains and sub-domains have been identified, they can be represented through models using modelling techniques. It is useful to divide the domain into sub-domains, because smaller units provide better control. A system can be divided into one or more sub-domains. Generally, sub- domains fall under the following 2 categories:

1. Technical sub-domains – These are portions of a system which are identified based on a technical aspect and need to be modelled based on a specific language. These are contained within the parent domain, (e.g. graphical user interfaces and persistence).

2. Partitions – Domains are often divided into several partitions to enable parallel function- alities or load-balancing. For example, within an insurance domain several product types, like Vehicle, Buildings and Life, can be defined. These partitions can further be decom- posed into smaller parts, such as the Vehicle being decomposed into Motor Vehicle and Marine Vehicle,Stahl et al.[2006].

Since domains are an integral part of MDSD executions, it is important and necessary to identify the domains belonging to a system before attempting to model and formalise them. Domain segregation is also important to identify the inputs for automation processes.