J. Cent. South Univ. (2012) 19: 1334-1340 

DOI: 10.1007/s11771-012-1146-7

Domain-specific modeling and verification for C4ISR capability requirements

DONG Qing-chao(董庆超)¹, WANG Zhi-xue(王智学)¹, CHEN Guo-you(陈国友)¹,

JIANG Xin(蒋鑫)¹, ZHANG Ting-ting(张婷婷)²

1. Technology of Command and Control Department, PLA University of Science and Technology,Nanjing 210007, China;

2. Institute of Sciences, PLA University of Science and Technology, Nanjing 211101, China

? Central South University Press and Springer-Verlag Berlin Heidelberg 2012

Abstract: An approach was proposed to specify the C4ISR capability of domain-specific modeling language. To confine the domain modeling within a standard architecture framework, formally a C4ISR capability meta-ontology was defined according to the meta-model of DoD Architecture Framework. The meta-ontology is used for extending UML Profile so that the domain experts can model the C4ISR domains using the C4ISR capability meta-concepts to define a domain-specific modeling language. The domain models can be then checked to guarantee the consistency and completeness through converting the UML models into the Description Logic ontology and making use of inference engine Pellet to verify the ontology.

Key words: C4ISR capability; meta-ontology; domain-specific modeling; description logic

1 Introduction

Architectural analysis of C4ISR system requirements is a hard and challenging work. IT projects were often described in terms of technical deliverables not as business outcomes, making it difficult for business to appreciate what was being delivered and often the IT architects lost sight of the ultimate business goal. The western industries recently advocated a methodology of capability-based planning (CBP) for defense acquisition. CBP focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise. It frames all phases of the architecture development in the context of business outcomes, clearly linking the IT vision, architectures, and the implementation and migration plans with the corporate strategic, business and line of business plans. Such paradigm has been popularly applied. The US government adopted a capability-based approach of the Joint Capability Integration and Development System (JCIDS) [1] to replace the previous requirements of acquisition system. The Canadian defense research agency proposed a capability engineering process (CEP) for defense acquisition [2]. And more recently, the Open Group issued the new version of generic architecture framework (TOGAF v9) [3] to support the CBP paradigm.

It is worthwhile to see that the architecture development methods are integrated with CBP paradigm, ontological modeling and domain-specific modeling technique. The RAND Corporation has conducted a series of researches and reached a number of achievements on practical theory and methods for capability-based planning, including analytic frameworks, methodologies, and tools [4]. The Swedish Armed Forces [5] proposed the new conceptual framework of IDC2 (Integrated Dynamic Command and Control) to model the network enabled capability. To realize a reuse of domain knowledge, the Canadian Research Agency [6] believed that C4ISR capability analysis requires the expertise and exploits the technologies based on the ontology paradigm. CHEN and POOLEY [7] proposed a meta-model for Zachman Framework which integrates the Bunge-Wand-Weber ontology and Enterprise Ontology. Many researchers of software engineering are more inclined to domain-specific modeling based on hybrid of UML and ontology paradigms. BRAHE and ?STERBYE [8] applied domain specific modeling (DSM) languages to model business processes, such that an enterprise can define its own DSM language(s) capturing its vocabulary and data requirements. POHJONEN [9] presented the MetaEdit+ metaCASE tool, and showed how meta modeling and tool support for domain-specific modeling languages can be completed without programming.

Most architecture development methods, such as MODAF (The UK Defence Architecture Framework) [10] and DoDAF (The US Defense Architecture Framework) [11], recommend UML (Unified Modeling Language) to model the capability concepts and C4ISR requirements. DoDAF provides a set of UML meta models to define its Meta-Model Data Groups (MMDG) [11]. Applying the UML modeling approach brings a number of advantages: 1) As UML is a popular modeling language, the requirement models are understandable for both software and system engineers, who do not worry about misunderstanding due to different technical backgrounds; 2) UML offers multiple view-points for different stakeholders and is more easily applied to modeling integrated architectures; 3) The architecture models can be smoothly turned into software application designs, and even into excusable simulation models by means of some emerging excusable UML approaches.

However, some problems might arise if UML is directly applied to the capability-based architectural analysis. Firstly, it is a semi-formal and weakly constrained modeling language. As a result, the built models may suffer inconsistency and concept conflicts, and it is hard to find a logic inference engine to do automatic model check. Secondly, based on abstract and domain-meaningless symbols or constructs, UML is of poor domain applicability [12] and thus it is difficult to model the capability concepts adequately. Thirdly, when a large-scale C4ISR system is broken into a number of sub-projects which are undertaken by different sub-contractors, the requirement engineers would debate on some domain-specific concepts which mean same things but are understood or explained differently in different systems. Consequently, it would be difficult to integrate and verify the separately built models as a whole.

To solve the problems and enable a way of automatic model checking by use of inference technique, in this work, a method of domain-specific modeling and verification is suggested. It helps the domain experts to model the C4ISR operational domains to define the domain-specific modeling languages (DSMLs) within the constraints of the C4ISR capability framework. Those DSMLs may offer IT architects domain-specific concepts and easy-to-learn modeling languages to define C4ISR capability requirements precisely. The domain models, though built in UML, can be turned into domain ontology specified in description logic (DL) and then be automatically verified with the help of some DL-supporting inference engines [13].

2 C4ISR capability meta-ontology

The domain-specific modeling of C4ISR capability requirements should be based on a capability meta-ontology to provide the modeling semantics. We built the ontology from the Meta-Model Data Groups of DoDAF v2.0 by extracting capability related meta-concepts and relationships from the architecture framework.

Definition 1: The C4ISR capability meta-ontology is a formal framework to detail the domain concepts of the C4ISR capabilities at the architectural level. It is composed of three parts, .

MetaConcept is a finite set of meta-concepts which contain all capability related meta-concepts from the MMDG, such as Activity, Capability, Service, Resource and Performer, and keep the same semantics as those in the MMDG. Figure 1 shows all the meta-concepts in MetaConcept .

MetaAssociation is a finite set of meta-relations among meta-concepts which contain all capability related meta-relations from the MMDG, such as Desired Effect Part Of Capability, Activity Performed By  Performer, and Rule Constrains Activity, and keep the same semantics as those in MMDG. Figure 1 shows all the meta-relations in MetaAssociation.

MetaRule is a finite set of meta-rules which provide the constraints that need to be held by all concepts and relations in the C4ISR capability models, and provide a set of domain general rules for C4ISR capability modeling. All rules in MetaRule are those suggested in the MMDG, such as “Every Capability must be a result of one or more Activities”, “Every Performer must perform one or more Activities”, and “Every Rule can constrain one or more Activities”.

3 Domain-specific modeling for C4ISR capability requirements

3.1 Domain-specific modeling language

The C4ISR capability meta-ontology gives formal definition of the C4ISR capability meta-concepts and relationships, and provides fundamental semantics for description of C4ISR capabilities. But, the ontology itself does not contain any domain-specific concepts, and consequently, its domain applicability may be a challenge. Therefore, we advise to pre-define a set of domain-specific concepts and relations based on the meta-ontology to construct a domain-specific modeling language for the modelers.

Definition 2: The C4ISR domain model defines a domain-specific modeling language which can be used to describe the C4ISR capability requirements in a specific C4ISR domain. It is composed of four parts: .

DomConcept is a finite set of domain-specific concepts, each of which is defined by sole meta-concept of the C4ISR meta-ontology. Table 1 gives an example of field armored car repairing domain concepts, DomAssociation is a finite set of domain-specific relations associated with a pair of concepts, each of which is defined by a sole meta-relation of the C4ISR meta-ontology, as given in Table 2. DomFunction is a complete function, mapping DomConcept to MetaConcept or DomAssociation to MetaAssociation, which is used to trace the type of domain concepts or relations in the meta-ontology. DomConstraint is a finite set of domain-general constraints specified in description logic according to the rules of MetaRule.

Fig. 1 C4ISR capability meta-ontology

Table 1 An example set of domain concepts

Table 2 An example set of domain relations

3.2 Enhanced OO modeling technology for C4ISR requirements specification

The C4ISR capability meta-ontology provides DoDAF compliant requirements of description framework, which can be incorporated into the OO modeling language UML and helps domain experts to capture domain concepts under the meta-concepts and consequently develops a domain-specific modeling language for a particular C4ISR domain (i.e. the C4ISR domain model). Such languages, composed of more specific semantic constructs, are more applicable to C4ISR requirements modeling and easier to make model conversion and verification.

In Refs. [8] and [14], a way of UML-based domain-specific modeling is suggested. They capture the domain-specific concepts from the problem domains and then extend the UML constructs with the help of UML profile mechanism. The models built with the   extended UML will thereafter abide by both    semantic constraints of UML and the domain-specific concepts.

With the similar idea, we define new stereotypes of UML2.1 constructs according to the C4ISR meta-ontology to specify a UML-based domain modeling language. Figure 2 reflects the UML extension mechanism, where the Class at MOF (Meta Object Facility) level is elaborated as the meta-concepts such as Capability, Resource, Activity etc. and the Association as meta-relations such as Desired Effect Part Of Capability, Activity Performed By Performer, and Capability Performer Manifestation. Having imported the UML extension profile, the domain experts can model a specific C4ISR domain with a popular UML modeling tool. Figure 3 gives an example of the Armored Car Repairing domain model, which reflects architecture- level requirements and defines a DSL for the Armored Car Repairing domain. Furthermore, the domain model can be exported as a new UML extension profile for the program level requirements modeling.

Fig. 2 UML profile based on C4ISR capability meta-ontology

Fig. 3 An example model of battle field armed car repairing domain

4 Domain model conversion and verification

The interoperability issue might arise when multiple system models exist and the models are built by different modelers with different tools, and therefore model verification is needed. We suggest an approach of transforming the models into ontology to verify consistency and completeness of the concepts of capability requirements through logic inference.

As a semi-formal modeling language, the UML does not by itself support model checking through logic inference. The popular way to solve the problem is adopting UML OCL (Object Constrain Language) to define additional well-formedness rules that are applied to the concepts in the model. Unfortunately, it is well known that the full expressiveness of OCL leads to undecidability of reasoning [15]. CABOT et al [16] explain that first-order logic (FOL) itself is undecidable in general and OCL is more expressive than FOL. Therefore, to avoid undecidability, existing methods able to reason on UML/OCL diagrams either limit the UML/OCL constructs that may appear in the diagrams, or are not automatic or are semi-decidable. This is obviously difficult for the domain experts who may lack of formal language background. Here, we suggest to express the C4ISR capability meta-ontology and domain models using SHOIN(D), the subsystem of description logic, because it is powerful in express-ability and decidability for a knowledge system and allows to make use of some handy inference engines like Pellet and Racer.

In Refs. [17] and [18], description logic is applied to UML model checking to find the inconsistent problems. Those methods focus on modeling semantics checking and fail to resolve conflicts between the UML models and the related domain knowledge, and therefore do not satisfy the needs of capability requirements analysis. But, our method aims at guaranteeing the models semantically consistent within themselves and with the other related domain knowledge as well, such as the meta-rules defined in the meta-ontology. Upon their works, we introduce a way of model conversion (from UML to SHOIN(D)) and automatic verification through logic inference. As a by-product, the generated domain ontology, since documented in the standard ontology description language, can be populated in the similar domains.

The basic principle of conversion and verification, as shown in Fig. 4, is as follows: 1) Convert the C4ISR capability meta-ontology into the rule set in SHOIN(D) Tbox and the domain models into the instance relation set in SHOIN(D) Abox; 2) Verify consistency and completeness with the help of an inference engine like

Fig. 4 DL-based domain model conversion and verification

Pellet which supports logic inference through the SHOIN(D) ontology. The automatic conversion can be made in following steps:

Algorithm: Convert the UML domain model into the domain ontology;

Input: A C4ISR domain model in UML; the C4ISR capability meta-ontology;

Output: The C4ISR domain ontology.

Step 1: Create the concepts and their instances

For every meta-concept CMetaConcept, create a same name concept C in Tbox; for every domain concept C_wDomConcept and DomFunction(C_w)=C, create a same name instance C_w in Abox, and declare the be-instance-of relationship between C_w and C with the function Instance(C, C_w).

Step 2: Establish the relationships among concepts and instances

For every meta-relation R(C₁, C₂) and Type(R)≠ Super-sub ( R is not a UML generalization relationship), create in Tbox a same name relation R and then add in Tbox a SHOIN(D) rule: C₁R·C₂；For every domain relation R_w(C_w1, C_w2) and DomFunction(R_w)=R, create in Abox the relation R(C_w1, C_w2). For every meta-relation R(C₁, C₂) and Type(R)=Super-sub, create in Tbox the relation Super-sub and then add in Tbox two SHOIN(D) rules: C₂C₁, C₂ Super-sub.C₁; For every domain relation R_w(C₁, C₂) and DomFunction(R_w)=Super-sub, create in Abox the relation Super-sub(C_w1, C_w2).

Step 3: Generate domain rule-base

All domain-general rules of the MetaRule set can be formally expressed as the cardinality restrictions imposed on the instance associations of meta-concepts. Before introducing the rule-base construction algorithm, we classify those rules into three categories so as to handle them respectively.

FCR (Free Cardinality Restriction) type: The FCR is a kind of the weakest cardinality restriction rules imposed on pairs of instances. It can be expressed in first-order predicate logic as

where the predicates C₁ and C₂ are concepts, R is the relation and # represents the cardinality of instance set of a concept. The samples of such rules defined by DoDAF are: Each rule may be a constraint on one or more Activities; each Performer may be constrained by one or more Rule; etc.

QCR (Qualified Cardinality Restriction) type: Compared with FCR, the QCR is strict on cardinality of instance association of concepts, expressed as

The examples of such rules are: Each Capability must be the result of one or more Activities; Each Organization must be the Performer of one or more Activities; etc.

CCR (Constant Cardinality Restriction) type: The CCR rules are the strictest meta-rules, expressed as

The examples provided by DoDAF are: Each Materiel must be used by one or more Persons, where each Person must be the member of only one Organization at any time, etc.

Based on the above classification, the domain-general rules are constructed in the following way in SHOIN(D) system, forming the domain-general rule base.

Rule-base construction:

For every Type (Rule(R(C₁,C₂)))=FCR, add in Tbox a rule C₁R·C₂.

For every Type (Rule(R(C₁,C₂)))=QCR, add in Tbox a rule C₁R·C₂ and C₁.

For every Type (Rule(R(C₁,C₂)))=CCR, add in Tbox a rule C₁R·C₂ and C.

Having acquired the domain ontology of the system requirements, the model checking is replaced by ontology consistency and completeness checking. The latter can be easily made by using DL-supporting inference engine technology which is currently mature and popularly applied to Semantics Web. Usually, such inference engine is based on the inference algorithm Tableau, details of which can be further referred to Ref. [19].

Let F_UML be a UML model and φ(F_UML) the SHOIN(D) Tbox derived from F_UML by the model conversion algorithm. In Ref. [18], it has been proved that every instantiation of F_UML is a model of φ(F_UML), and vice versa. It has also been proved that the translation from UML to DL preserves the semantics of UML models. The conversion algorithm has been realized and integrated into a requirement analysis tool called OBCREAT (ontology-based capability requirements elicitation and analysis tool). We use OWL+DL to code the domain models and apply the open-source DL-supporting engine Pellet 1.5.0 to make automatic model check. As the C4ISR meta-ontology contains only a few hundreds of concepts and a limited number of rules in Tbox, the tool is free from dead running and execution of the algorithm Tableau takes less than 1 min.

5 A case study on domain modeling

Figure 3 shows a fragment of domain model of the battle field armored car repairing system and details the business pattern of the battle field armored car repairing. The model is derived from MODAF and is a typical example to illustrate the model verification restricted by DoDAF rules. The model verification is made on consistency and completeness separately.

Case 1: Consistency checking

The consistency checking is to examine whether there is a logical contradiction to modeling semantics, i.e. whether the concepts and relations in the models, of which there is mapping to the meta-ontology, break the meta-relation constraints declared in the C4ISR capability meta-ontology. Such checking may also solve the interoperability issue, since all related models will be converted into ontology comprising a knowledge base, where logic inference can be made to check the whole requirements.

Suppose that the domain expert wrongly adds in  Fig. 3 a relation Activity Part Of Capability between the domain-specific Activity RCBF (Repairing Cars at the Battle Field) and the domain-specific Service VRS (Vehicle Repair Service). But according to the meta-ontology, that relation should only appear between Activity and Capability and thus the consistency constraint is broken.

Having built the wrong model and converted it into a domain ontology (the file named as FBACR_domain.owl) and done model checking by entering a command “pellet consistency FBACR_domain.owl”, we will find a response from the Pellet engine: “Consistent: No  Reason: Individual Vehicle Repair Service is forced to belong to class Capability”. The Pellet has found that the domain concept VRS should belong to the meta-concept Capability instead of Service, because of the declared relationship. In another word, we must be careful in building the association between the concepts strictly sticking to their meta-relation restrictions.

Case 2: Completeness checking

The completeness checking is to examine whether the models abide by the constraints from the MetaRule set of the C4ISR capability meta-ontology so that the architectural completeness is guaranteed.

Suppose again that the domain expert wrongly adds in Fig. 3 a relation Person Part Of Organization between the Person Type FSRT (Firepower System Repair Technician) and the Organization Type VSRD (Vehicle-power System Repair Department). Such relation violates the domain-general rule in the MetaRule set, stating that each Person must be at any time the member of only one Organization.

After conversing and checking, we find the result prompted by Pellet: “Consistent: No Reason Individual Firepower System Repairing Technician has more than one value for property Person Part Of Organization violating the cardinality restriction”. This implies that there are more than one instance association between the two domain concepts Person Type and Organization Type and thus it violates the cardinality restriction in MetaRule set.

6 Conclusions

1) An approach of domain-specific modeling and verification is introduced, based on the UML profile mechanism and description logic. The system engineers may ask the help of domain experts who can model the C4ISR domains to define a domain-specific modeling language. The domain models should be built under the constraints of the standard architecture framework like DoDAF.

2) Extending UML by specifying new UML profiles is suggested according to the C4ISR capability meta-ontology, which is built from the DoDAF, to develop a UML based domain-specific modeling language. In order to verify the domain models, a model conversion algorithm is provided to convert the UML models into ontology specified in SHOIN(D) and hence the verification can be automated by an inference engine such as Pellet.

3) A case study demonstrates that such verification can examine semantic consistency on one hand and check the model completeness on the other hand.

References

[1] Joint Chief of Staff. CJCSI3170.01D. Joint capabilities integration and development system [S/OL] 2005. http://www.dtic.mil/ cjcs_directives / index.htm.

[2] CAPDEM T D. Collaborative capability definition engineering and management technology demonstrator [S/OL]. 2010. http://www.drev.dnd.ca/poolpdf/e/162_e.pdf.

[3] The Open Group. Part III: ADM guidelines and techniques, TOGAF version 9 [S/OL] 2009. http://www.opengroup.org/architecture/ togaf9/downloads.htm.

[4] DAVIS P, SHAVER R, BECK J. Portfolio-analysis methods for assessing capability options [R]. US: RAND Corporation, 2008.

[5] JOSEFSSON A, MARKLUND J. IDC2-A new C2 concept within the framework of a network based defence concept [C]// Proc of 13th Int Conf on Command and Control Research and Technology Symposium. Seattle, 2008: 1-19.

[6] AUGER A, GOUIN D, ROY J. Decision support and knowledge exploitation technologies for C4ISR [EB/OL] 2006. Technical Memorandum, http://pubs.drdc.gc.ca/PDFS/unc52/p525876.pdf.

[7] CHEN Z, POOLEY R. Rediscovering Zachman framework using ontology from a requirement engineering perspective [C]// Proc of 33th Annual IEEE International Computer Software and Applications Conference. Washington, 2009: 3-8.

[8] BRAHE S, ?STERBYE K. Business process modeling: Defining domain specific modeling languages by use of UML profiles [J]. Journal of Lecture Notes in Computer Science, 2006, 4066(1): 241-255.

[9] POHJONEN R. Metamodeling made easy–MetaEdit+ (tool demonstration) [J]. Journal of Lecture Notes in Computer Science, 2005, 3676 (1): 442-446.

[10] UK Ministry of Defence. Mod architecture framework overview version 1.0 (MODAF-M09-002) [S/OL] 2005. http:// www.modaf.org.uk/.

[11] US Department of Defense. DoD architecture framework version 2.0 (Volume I-II-III) [S/OL] 2009. http://www.us.army.mi/suite/page/ 454707 MOD Partner.

[12] GIANCARLO G, LUIS F, MARTEN V. An ontology-based approach for evaluating the domain appropriateness and comprehensibility appropriateness of modeling languages [J]. Journal of Lecture Notes in Computer Science, 2005, 3713(1): 691-705.

[13] HORROCKS I, PATRL P F. Reducing OWL entailment to description logic satisfiability [J]. Journal of Web Semantics, 2004: 345-357.

[14] KIM D K, ROBERT F, SUDIPTO G. A UML-based language for specifying domain-specific patterns [J]. Journal of Visual Languages & Computing, 2004, 15 (3): 265-289.

[15] QUERALT A, RULL G, TENIENTE E, FARRE C, URPI T. AuRUS: Automated Reasoning on UML/OCL Schemas [J]. Journal of Lecture Notes in Computer Science, 2010, 6412: 438-444.

[16] CABOT J, CLARIS R, RIERA D. Verification of UML/OCL class diagrams using constraint programming [C]// Proc of 2008 IEEE International Conference on Software Testing Verification and Validation Workshop. Lillehammer, 2008: 73-80.

[17] VAN R. Inconsistency management in model-driven engineering [D]. Brussels: Vrije University, 2005.

[18] DANIELA B. Reasoning on UML class diagrams [J]. Journal of Artificial Intelligence, 2005, 168(1): 70-118.

[19] HORROCKS I, SATTLER U. A tableau decision procedure for SHOIQ [J]. Journal of Automated Reasoning, 2007, 39(3): 249-276.

(Edited by YANG Bing)

Foundation item: Project(2007AA01Z126) supported by the National High Technology Research and Development Program of China; Project(51306010202) supported by the National Defense Advance Research Program of China

Received date: 2011-03-21; Accepted date: 2011-05-30

Corresponding author: DONG Qing-chao, PhD; Tel: +86-25-80824566; E-mail: dongqingchao001@sohu.com