**2.2.1 Overview of model-driven TSDO modeling approach**

MDA adopts the model-based development mode (Miller & Mukerji, 2003) as shown in Figure 10. Computation Independent Model (CIM) mainly describes the requirements of software system, which specify the system function and boundary. Platform Independent Model (PIM) is the high level abstraction of system function, without any information related to implementation techniques; Platform Specific Model (PSM) is the model which contains specific implementation platform technique information. The MDA–based development process is: firstly, establishing CIM based on the system requirements; secondly, according to the specifications of CIM, creating PIM with the platform independent modeling language, such as UML; thirdly, transforming the PIM to PSM according to some specific mapping rules; lastly, generating platform specific code automatically or semi automatically. In this process, modeller can further refine the created models in CIM, PIM or PSM stage.

Fig. 10. Model-driven TSDO modelling approach.

According to the modelling idea of MDA, we presented a concrete model-driven TSDO modelling approach to provide a practical engineering implementation as shown in Figure 10. The definition of TSDO scope and the establishment of domain ontology framework belong to the CIM modelling stage. Modeller can employ use case diagram of UML to define the scope of TSDO and set up its framework. In this approach, PIM mainly focuses on the multi-channel domain concept acquisitions and the further conceptual integration and refinement, i.e. conceptual modelling. UML class diagram or use case diagram can be used to model the collected domain concepts and their relationships. After acquiring the domain terminologies, the following step is to integrate and refine these

Telecommunications Service Domain Ontology:

mapping example is illustrated in the Figure 12.

(a) (b)

Fig. 12. The direct mapping example from UML to OWL.

example is shown in Figure 13.

Figure 14.

Semantic Interoperation Foundation of Intelligent Integrated Services 195

After defining the CIM of TSDO, the following step is to construct the PIM of TSDO. It means that the telecom service related domain terminologies should be collected and then integrated into a high-level abstract domain ontology model which is independent of a specific ontology language like OWL. The collection of domain terminologies can be modeled by the UML Use Case diagram like Figure 4. However, the high-level domain conceptual modeling is the emphasis of PIM. How to model the conceptual model of domain ontology based on UML is needed to resolve. Fortunately, UML and ontology language have some common features, although sometimes represented differently. This provides a possible transformation from UML model to ontology model. For example, both ontology representation language and UML are based on *Class*. The *Generalization* elements of UML can represent the subClass or subProperty semantic of ontology. The ownedAttribute of UML Class can describe the DatatypeProperty of ontology language. The

However, although UML Class diagram has some constructs similar to the constructs of ontology representation language, there are still some ontology constructs which cannot be represented by UML constructs directly. We need to find the appropriate UML elements to represent some other ontology constructs, like objectProperty, equivalent class relation, and disjointing class relation. For instance, we can select the directedAssociation element of UML to represent the ObjectProperty and use the constraints anchored with association to represent the inverse, symmetric or transitive feature of ObjectProperty. An illustrated

As a common software modeling language, most of software developers, system analysts and designers are familiar with UML. So, in order to decrease the technical threshold, it's a practical approach for the conceptual modeling of TSDO by UML. Although UML has some similar constructs with ontology language, however, the modeling goals and description capabilities of both languages have some differences. From the above analysis, in order to use UML to represent high-level ontology conceptual model, we need to define a specific tailored representation method to guide the modeler to build the conceptual model of domain ontology. Table 1 shows the main corresponding relation of UML elements with ontology elements. According to this semantic representation way, the modeler can use the UML elements to describe the semantic-enabled high-level ontology conceptual model like

**2.2.3 PIM step: Terminology acquisitions and conceptual modeling of TSDO** 

concepts and their relationships to form a high-level domain ontology model, which is independent of a specific ontology description language. The PSM and code steps are used to realize the formalization of high-level domain ontology conceptual model by a specific ontology language. By the model to model transformation technology, the highlevel conceptual model (i.e. PIM ) can be transformed into an ontology language specific model (i.e. PSM). And then by using model to code transformation technology, the concrete ontology description file encoded by a specific ontology language like OWL (i.e. code) can be generated from the ontology language specific model (i.e. PSM). When we need to revise or maintain the created ontology, we can return back to the CIM or PIM to modify the related models and then generated the corresponding code again. In this mode-driven ontology development approach, all processes adopt the standard UML model or UML extension mechanism (i.e. UML Profile). The technical details are described in the following sections.

#### **2.2.2 CIM step: The scope and framework modeling of TSDO**

In order to well organize the development of TSDO, this approach uses the UML use case diagram to model the scope and framework of TSDO. As is shown in Figure 11(a), the ontology hierarchy is represented by package *InfrastructureOfOntology*, which consists of three types of package: common ontology, domain ontology and application ontology. Each package contains the related ontology concepts and their relationships. The *Common Ontology* package contains some general concepts particularly designed for high reusability, where other different domain ontologies and application ontologies either import or specialize its specified concepts or relationships. This is illustrated in Figure 11(a), where it is shown how domain ontologies and application ontologies each depends on the common ontology. The common ontology is generally defined by some standard organizations or research communities. In this chapter, we mainly focus on the building of telecommunications service domain ontology. In order to facilitate reuse, the *Telecommunications Service Domain Ontology* package is further subdivided into a number of packages: *ServiceCategory, Netowrk, TerminalCapability, ServiceQuality, ServiceRole*, and *Charging*, as shown in Figure 11(b).

Fig. 11. CIM modelling of telecommunications service domain ontology.

concepts and their relationships to form a high-level domain ontology model, which is independent of a specific ontology description language. The PSM and code steps are used to realize the formalization of high-level domain ontology conceptual model by a specific ontology language. By the model to model transformation technology, the highlevel conceptual model (i.e. PIM ) can be transformed into an ontology language specific model (i.e. PSM). And then by using model to code transformation technology, the concrete ontology description file encoded by a specific ontology language like OWL (i.e. code) can be generated from the ontology language specific model (i.e. PSM). When we need to revise or maintain the created ontology, we can return back to the CIM or PIM to modify the related models and then generated the corresponding code again. In this mode-driven ontology development approach, all processes adopt the standard UML model or UML extension mechanism (i.e. UML Profile). The technical details are

In order to well organize the development of TSDO, this approach uses the UML use case diagram to model the scope and framework of TSDO. As is shown in Figure 11(a), the ontology hierarchy is represented by package *InfrastructureOfOntology*, which consists of three types of package: common ontology, domain ontology and application ontology. Each package contains the related ontology concepts and their relationships. The *Common Ontology* package contains some general concepts particularly designed for high reusability, where other different domain ontologies and application ontologies either import or specialize its specified concepts or relationships. This is illustrated in Figure 11(a), where it is shown how domain ontologies and application ontologies each depends on the common ontology. The common ontology is generally defined by some standard organizations or research communities. In this chapter, we mainly focus on the building of telecommunications service domain ontology. In order to facilitate reuse, the *Telecommunications Service Domain Ontology* package is further subdivided into a number of packages: *ServiceCategory, Netowrk, TerminalCapability, ServiceQuality, ServiceRole*, and

(a) (b)

Fig. 11. CIM modelling of telecommunications service domain ontology.

described in the following sections.

*Charging*, as shown in Figure 11(b).

**2.2.2 CIM step: The scope and framework modeling of TSDO** 
