Article Preview
Top1. Introduction
In this day and age no one can question the importance of Information Technology (IT) in the business world. A world in which there is a market that is more and more competitive. With the continuous integration and standardization of new computer technologies, the business world is changing frequently. Therefore the business world is immersed in a cycle of continuous improvement, where essentially, the level of quality of the IT services delivered to the customers is often the deciding and differentiating factor. Thus, business people have increased their expectations related to the IT department, and now they need IT to support their business processes in a strategic way. That is, organizations are aware of the closer relationship and convergence between business and IT.
In this vein, IT Service Management (ITSM) provides a set of specialized organizational capabilities and a professional practice, supported by an extensive body of knowledge, experience and skills for providing value to customers in the form of IT services (OGC, 2007).
The implementation of any IT service-oriented software system requires performing a number of different steps in order to produce all the required artifacts (either internal or deliverable). Based on the notion that a software system is a representation of another system (i.e., the real-world), the first step is to formalize the domain concepts and the relationships between them (i.e., the ontology), in order to obtain a common vocabulary agreed by all the stakeholders involved in a given project for requirements elicitation. In addition, apart from the domain concepts, additional rules, constraints and semantics are required in order to avoid semantic ambiguities, uncertainties and contradictions. The Web Ontology Language (OWL) (Smith, Welty, & McGuinness, 2004), the de facto standard for ontology representation, enables the definition of rules, constraints and semantics in terms of logic based domain concepts. The importance of an investigation of the issues involved in the IT service-oriented requirements analysis is also remarked by Lichtenstein, Nguyen & Hunter (2004). However, in spite of the efforts of the Software Engineering (SE) community to define new intuitive and powerful techniques, there is still an open gap regarding the automated and seamless integration of domain aspects (i.e., the business view) into the software development process.
The emerging Model-Driven Engineering (MDE) paradigm offers a promising solution to cope with this limitation. MDE addresses the inability of third-generation languages to cope with increasing software complexity, allowing us to describe domain concepts effectively (Schmidt, 2006; Gašević & Hatala, 2010). Model Driven Engineering (MDE) is a software and system construction approach based on high-level abstract modeling. All the relevant information in a project is stored in models based on well-defined languages and development is then carried out as a sequence of model transformations. The MDE term was first proposed by Kent (2002) but it is derived from the OMG’s Model Driven Architecture (MDA) initiative (OMG, 2003).
As shown in Figure 1, MDA defines a particular MDE process aimed at separating the business logic from the technological platforms. Thus, organizations can use MDA to meet the integration challenges posed by new platforms, while preserving their investments in existing business logic. MDA proposes three modeling levels, namely (ordered from highest to lowest levels of abstraction): Computation Independent Model (CIM), Platform Independent Model (PIM), and Platform Specific Model (PSM). Different Model-to-Model (M2M) transformations among these abstraction levels can be defined either top-down or bottom-up. Commonly, each CIM (model gathering high-level business requirements, sometimes called a domain model) is transformed into one or more PIMs (platform-independent architectural models). Similarly, each PIM is transformed into one or more PSMs (one for each target platform). PSMs are commonly very low level models, enabling the definition of a direct Model-to-Text (M2T) transformation for automatically generating the final system implementation, including code, documentation, etc.