2014-A novel executable modeling approach for system-of-systems architecture_图文

4

IEEE SYSTEMS JOURNAL, VOL. 8, NO. 1, MARCH 2014

A Novel Executable Modeling Approach for System-of-Systems Architecture
Bingfeng Ge, Student Member, IEEE, Keith W. Hipel, Fellow, IEEE, Kewei Yang, and Yingwu Chen
Abstract—A novel executable modeling approach is proposed for system-of-systems architecture by taking full advantage of the Department of Defense Architecture Framework (DoDAF) Metamodel (DM2) and de?ning the common model transformation speci?cation at the metamodel level. This methodology provides more ?exibility and adaptability for the automated construction of executable models directly from the architectural data rather than from static models. More speci?cally, the architectural data metamodel is ?rst established to guide architectural data modeling of core data elements and associations in DM2 as the common and consistent data dictionary for architecture modeling, while the executable formalism metamodel is designed to formally de?ne executable models. Then, the mapping rules between both metamodels are presented as the common transformation speci?cation regardless of which modeling language or methodology is employed in developing architectural descriptions. Finally, eXtensible Markup Language (XML) technology, like XML schema languages and eXtensible Stylesheet Language speci?cations, is discussed to facilitate the automated transformation of executable models from architectural instance data. The feasibility of the proposed approach is illustrated using a published example where colored Petri net (CPN) is used as the executable formalism. Index Terms—Architectural data metamodel, data-centric, executable formalism metamodel, mapping rules, system-of-systems (SoS) architecture.

I. I NTRODUCTION S INFORMATION science and technology continues to evolve, the paradigm of system of systems (SoS) has emerged as a popular choice for being an economic and strategic approach for enhancing existing system capabilities

A

Manuscript received September 13, 2012; revised March 20, 2013 and May 9, 2013; accepted May 10, 2013. Date of publication July 22, 2013; date of current version February 5, 2014. This work was supported in part by China Scholarship Council through the State Scholarship Fund under Award 2011611075 and in part by the National Natural Science Foundation of China under Grants 70971131 and 71001104. B. Ge is with the College of Information System and Management, National University of Defense Technology, Changsha, Hunan 410073, China, and also with the Department of Systems Design Engineering, University of Waterloo, Waterloo, ON N2L 3G1, Canada (e-mail: bingfengge@nudt.edu.cn). K. W. Hipel is with the Department of Systems Design Engineering, University of Waterloo, Waterloo, ON N2L 3G1, Canada (e-mail: kwhipel@ uwaterloo.ca). K. Yang is with the College of Information System and Management, National University of Defense Technology, Changsha, Hunan 410073, China, and also with the Science and Technology on Complex Systems Simulation Laboratory, Beijing 100032, China (e-mail: kayyang27@nudt.edu.cn). Y. Chen is with the College of Information System and Management, National University of Defense Technology, Changsha, Hunan 410073, China (e-mail: ywchen@nudt.edu.cn). Color versions of one or more of the ?gures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identi?er 10.1109/JSYST.2013.2270573

and developing new capabilities to address challenging systems engineering and management problems in the military, academia, industry, and elsewhere [1]–[3]. As “large-scale integrated systems that are heterogeneous and independently operable on their own, but are networked together for a common goal” [4], SoS is a class of complex systems whose system components are themselves systems. Relative to traditional systems, the development of an SoS is evolutionary over time and challenged by characteristics of increasing complexity, emergent behavior, and uncertainty in requirements and context (e.g., changing environmental and operational conditions); thus, it is also associated with the increasing integration of its evolutionary components and functions (in service and/or in development) with a parallel demand for more interoperability to ful?ll desired effects as a cohesive whole [5]–[8]. Modelbased systems engineering, which focuses systems engineering process on well-constructed models that represent the essence of the system, can help address these signi?cant challenges [9]– [12]. Systems architecture is the conceptual model that characterizes the fundamental concepts or properties of a system in its environment embodied in its components and relationships, and the principles and guidelines governing its design and evolution over time [6], [13]. Architecture-based capability engineering, in particular, addresses the complexity and uncertainty early in the SoS design process and therefore conceptualizes the capabilities expected to be achieved by the entire SoS via the development and continuous evolution of its systems architecture to accommodate more possibilities and unpredictable operating environments [4], [6]. Over the past few decades, many studies on architecture modeling and analysis, such as architecture frameworks and design methodologies, have served well in the description of architectures for traditional systems that meet the ?xed requirements. Moreover, these architectural descriptions are more super?cial than practical design documents with little regard for good decision support. That is, the products of an architectural description, being static models of architectural elements in nature, fail to support dynamic analysis, validation, and veri?cation of whether all elements combined together behave as expected and the overall architecture as modeled delivers the desired capabilities [6], [13], [14]. Consequently, the need for executable models has emerged to enable the time-dependent dynamic simulations for allowing a more complete examination and early exploration of the logical and behavioral characteristics and providing cost-bene?t analysis of the capabilities as modeled in the architecture against the capability requirements. It has ultimately led to the more speci?c studies of executable modeling for SoS architecture.

1932-8184 ? 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

GE et al.: NOVEL EXECUTABLE MODELING APPROACH FOR SYSTEM-OF-SYSTEMS ARCHITECTURE

5

Currently, the most popular approach for executable modeling has been concerned with synthesizing executable models from static architectural models [9], [14], [15], as reviewed in the next section. The latest U.S. Department of Defense Architecture Framework (DoDAF 2.0) [13] de?nes the DoDAF Meta-model (DM2) along with a “data-centric” approach to developing architectural descriptions in a semantically consistent and interoperable fashion. However, current studies of executable modeling usually rely heavily on static models without taking full advantage of DM2 and the “data-centric” approach. Due to the inconsistent representation for the same semantic content of static models by different modeling tools or languages, the target executable models transformed from these static models are very diverse and signi?cantly different even for a same architecture. Moreover, any changes needed or any errors found in the creation of executable models and detailed follow-up analyses must be re?ected back to guide revisions in the static models of source architectural description [15]; however, the iterative architecture re?nements (e.g., modifying an architecture design or correcting errors in the design) are often needed to better support SoS evolution and accommodate itself with desired capabilities to the changing requirements and context. Since most current studies are still a manual process with weak model consistency checking due to semiformal semantics in modeling languages [14], [16], this connotes that more signi?cant effort may be required to preserve the complete bidirectional traceability and data consistency between all elements of static models and executable models. A novel executable modeling approach is proposed for SoS architecture by taking full advantage of DM2 and the “datacentric” approach and de?ning a common model transformation speci?cation at the metamodel level, while addressing the collective shortcomings of current studies to provide more ?exibility and adaptability to the automated construction of executable models directly from architectural data. The remainder of this paper is structured as follows. Related work leading to executable modeling is reviewed in Section II, with an outline of the collective shortcomings. The proposed executable modeling approach is discussed in Section III, including the metamodels of architectural data and executable formalism, common transformation speci?cation based on metamodellevel mapping rules, and the model-level transformation to generate executable models. An illustrative example is then used to demonstrate the application of the proposed approach in Section IV. Appropriate conclusions are ?nally provided in Section V. An earlier version of this paper appeared in the proceedings of the 2012 IEEE 7th International Conference on System of Systems Engineering [17]. II. R ELATED W ORK A. “Product-Centric” and “Data-Centric” Architectural Descriptions Note that it is simply not possible to capture the entirety and all the details of a complex SoS using a single architectural model; otherwise, such a model will contain far too much information and will thus be dif?cult for individual stakeholders to clearly understand the aspects of interest and abstract

essential features from the underlying complexity. Therefore, each static model of an architectural description is purposefully kept simple to represent either one or limited key aspects of an SoS architecture, yet all together contribute to the understanding of the whole. Architecture frameworks provide some structured guidance and rules for development and management of static architectural models from multiple perspectives and on varying levels of abstraction, thereby allowing focusing on speci?c aspects of interest, while keeping sight of the whole system [13], including Zachman Framework, DoDAF, U.K. Ministry of Defense Architecture Framework (MODAF), North Atlantic Treaty Organization (NATO) Architecture Framework (NAF), and other civil frameworks like The Open Group Architecture Framework (TOGAF). Both previous versions of DoDAF and other related frameworks have emphasized reusable and interoperable data organized into individual products. Thus, many architecture design methodologies using different modeling languages have been presented to provide an ef?cient and repeatable way to facilitate the development of such “product-centric” architectural descriptions. Structured analysis methodology is a processoriented approach for developing architectural descriptions based on functional–hierarchical decomposition using a combination of an activity or process modeling language (e.g., IDEF0 or data ?ow diagram), a data modeling language (e.g., IDEF1X or entity relationship diagram), and rule modeling (e.g., structured English, decision tables/trees, or mathematical logic) [15], [18]. Object-oriented methodology is an approach based on entity decomposition typically using the Uni?ed Modeling Language (UML) to conceptualize and design information systems with both structural and behavioral diagrams [6], [15]. It has recently been extended to use Systems Modeling Language (SysML) for systems engineering applications to meet the need of functional ?ow modeling [14], [19]. The Uni?ed Pro?le for DoDAF/MODAF (UPDM), architecturally aligned with metamodels of DoDAF, MODAF, and other frameworks, is also a standardized way of expressing architecture artifacts using UML and SysML. Activity-based methodology (ABM) is a rigorous, disciplined, and structured approach toward the ef?cient and effective development and analysis of fully integrated, unambiguous, and consistent DoDAF views for both “as-is” and “to-be” architectures [20]. Since different modeling languages have different symbols (vocabulary), semantics, and syntax [6], which leads to the problem of inconsistent representation for the same semantic content in static models, these “product-centric” architectural descriptions developed with different design methodologies are magni?cent in their perfection but dif?cult to be federated and compared. The latest DoDAF 2.0 is substantially different since it expands legacy models with new models incorporated from MODAF, NAF, and TOGAF and has evolved from the “product-centric” approach to a new “data-centric” approach. It does not prescribe any particular models or views but rather places greater emphasis on architectural data as the essential ingredient of any architecture development for ef?cient and effective decision support [13]. More speci?cally, DoDAF 2.0 presents the DM2, which is an entirely new data metamodel used to organize semantically related data concepts or elements

6

IEEE SYSTEMS JOURNAL, VOL. 8, NO. 1, MARCH 2014

into common taxonomies (terminology having common de?nitions) of data types and de?ne their associations and attributes based on several important properties of a formal ontology foundation called the International Defence Enterprise Architecture Speci?cation (IDEAS). The DM2 has three levels of abstraction: The conceptual data model (CDM) de?nes the highlevel data constructs and describes the relationships among them in relatively nontechnical and easily understood terms; the logical data model (LDM) adds technical information to CDM and rei?es and formalizes relationships into an unambiguous usage de?nition; and the physical exchange speci?cation (PES), which is the tool- and methodology-neutral format and semantics of information sharing and data exchange between different architecture tools and databases for DoDAF conformance [13], is autogenerated as a set of eXtensible Markup Language (XML) Schema De?nitions (XSDs) from LDM with general data types speci?ed and implementation attributes added. To facilitate the use of information at the data layer, the new “data-centric” approach, along with DM2, enables whatever “?t-for-purpose” combination of views or static models, both DoDAF-described models populated with instance data and other user-de?ned views of a subset of architectural data, to be built for organizing and visualizing architectural data through a more easily understood format or customizable representations. B. Executable Architecture Modeling Since UML dominates most development of object-oriented architectural descriptions particularly in software engineering, several variants of UML have been created to make it executable, including executable UML (X UML) and executable and translatable UML (X T UML). However, being weak in formal execution semantics, both these variants of UML and SysML still do not support the formal speci?cation, validation, and veri?cation of executable models [14], [16]. Currently, an alternative approach for executable modeling is usually employed for addressing the use and integration of multiple related tools to facilitate the construction of executable models from their corresponding architectural descriptions; thus, the executable modeling is converted into a model transformation process of synthesizing executable models in the form of various executable formalisms from static architectural models speci?ed by different modeling languages. Levis et al. [6], [15], [18] developed a three-process framework for architecture design and evaluation (i.e., architecture design, executable model construction, and evaluation of architecture), where DoDAF-compliant architectural descriptions, produced by either structured analysis or object-oriented methodology based on UML, can be transformed into colored Petri net (CPN) executable models used for architecture analysis and evaluation. Wagenhals et al. [15] have created mapping rules to enable the automated transformation to a CPN executable model from the UML-like architectural description, in which a UML activity diagram with swim lanes is used to capture the complete description of static behavior. Wang and Dagli [14] proposed an executable system architecting paradigm with a SysML-based model-driven architecture (MDA) design process for discrete-event system modeling and analysis, in which a

new conversion procedure is developed for converting SysML models into CPN models, and related architecture evaluation and analysis techniques are used to check and re?ne the architecture design and ?nally verify the behavior and functionality of the system modeled. Huynh and Osmundson [19] proposed a systems engineering methodology for performing SoS architecture analysis, involving process modeling with SysML and the conversion of the resulting SysML models into an executable object-oriented simulation model via Extend (renamed ExtendSim in the latest version). Ring and Nicholson [20] employed the ABM to generate integrated static DoDAF models and then to facilitate the transition from these models to executable process models in Bonapart, which is an object-oriented business process modeling tool based on a CPN simulation engine. This work can be further implemented with Executable Architecture Methodology for Analysis in a federation of executable simulation environment, integrating an executable process model, an executable communication network model, and a combat simulation model. Griendling and Mavris [21] developed an executable environment as a key component of the ARCHITECT methodology which focuses on using a standard set of DoDAF views and the associated data to automatically generate four types of executable models (i.e., Markov chains, Petri nets, system dynamics models, and mathematical graphs). Other target executable formalisms include agent-based simulation [22] and discrete-event system speci?cation [23]. Overall, the aforementioned current executable modeling studies, in essence, are the model transformations using the principles of MDA at the model level [9], [14], [15]. They ?rst describe the system context and requirements with computation-independent models (CIMs); CIMs are then re?ned to static architectural models [platform-independent models (PIMs)] speci?ed by different modeling languages to de?ne system functionality and behavior; and PIMs can be further transformed into executable models (platform-speci?c models) with more implementation details based on various executable formalisms of any desired dynamic simulation platforms. Note that executable models, which are built based on different executable formalisms, have different interests and involve various abstraction levels. Those executable models in the form of CPN, no doubt, the most popular executable formalism, are well suited for information systems that consist of a number of communication and synchronous processes, while the others, such as those based on ExtendSim (formerly called Extend), are better for performing key-performance-indicator-oriented dataand rule-driven simulations for complex systems. Unfortunately, although capable of permitting the same concept to be realized with different modeling tools to draw on the strengths of each tool, the use of current studies for executable modeling, which relies heavily on the static models speci?ed by different modeling languages without taking advantage of DM2 and a “data-centric” approach, generally results in the following collective shortcomings. 1) Current studies are grounded on the fundamental premise that executable models can be fully speci?ed only if the information collectively contained in the source static models is suf?cient and consistent [6], [14]. Either design

GE et al.: NOVEL EXECUTABLE MODELING APPROACH FOR SYSTEM-OF-SYSTEMS ARCHITECTURE

7

Fig. 1.

Illustration of the “data-centric” executable modeling at the metamodel level.

methodology can produce all the information needed; however, semiformal semantics in modeling languages make them weak at model consistency checking [16], and maintaining concordance among all artifacts in different static models is still manual in many cases and particularly dif?cult for a “product-centric” architectural description. 2) Due to the aforementioned problem of inconsistent representation for the same semantic content in static models, the model transformation process based on the mappings between elements of static and executable models is tooland methodology-speci?c and diverse even for the same architecture, let alone with various modeling tools by different organizations; the process also needs someone to be familiar with both original modeling languages and target executable formalisms. It is also dif?cult to be commonly understood and compared across multiple instances. 3) The model transformation, most often a manual process, should keep the complete bidirectional traceability between both static and executable models [15]. Due to the lack of a common foundation and speci?cation, current studies offer weak ?exibility and adaptability for guiding traceable and consistent revisions in the architectural description and executable modeling, particularly for an SoS, which needs iterative architecture re?nements to better support its evolution and continuously adjust itself for alignment with any changing requirements and context.

data modeling and the common de?nition of executable models, respectively; the mapping rules between both metamodels are then presented as a common speci?cation at the higher level for the model-level transformation regardless of modeling languages, as described in Section III-B; and a procedure performs an automated model transformation to generate executable models according to the established model transformation speci?cation and with the support of XML technology, as discussed in Section III-C. A. Metamodels of Architectural Data and Executable Formalism According to the MDA with the Meta Object Facility designed by the Object Management Group [24], system models can also be organized within a four-layered architecture. At the top layer, the level M3 is the self-de?ned meta-metamodel, which allows de?ning metamodels at level M2. Then, a model conforming to its metamodel is de?ned at level M1 and represents real-world things at the bottom level M0. A metamodel (model of model or model of metadata) typically de?nes the abstract syntax of models and the interrelationships between model elements [24]. That is, it is usually de?ned as a set of concepts or model elements of a language, as well as the constraints and rules for how they may be arranged and related to build models without necessarily providing the concrete syntax of the language. Accordingly, the creation of an architectural model populated with instance data can be equivalent to de?ning the model elements in its metamodel with speci?c attributes of an instance. The key foundational principles of architecture analysis include information consistency, data completeness, data transformation, small iterative process, and lack of semantic ambiguity [13]. To meet these principles and thereby gain the full bene?t of subsequent architecture analysis based on architectural models, it is necessary to use common taxonomies and formal semantics in architecture modeling. As mentioned earlier, DoDAF 2.0 presents the entirely new data metamodel (DM2) to de?ne architectural data concepts, and their associations and attributes, which inherit several important properties from the IDEAS Foundation (formal, higher order, 4-D, and employing the mathematics of set theory and 4-D mereotopology). That is, the DM2 goes beyond a simple taxonomy to include other types of relationships between data concepts, such as before–after and temporal-whole–part relationships, for modeling any form of temporal behaviors [13]. The DM2 thus provides a high-level view of the necessary architectural data normally collected,

III. P ROPOSED A PPROACH In response to the collective shortcomings of current studies outlined in Section II, the need for a common, consistent, and integrated speci?cation of architectural data modeling has emerged, along with an increasing demand for a formal model transformation speci?cation at a higher level. In this paper, a novel executable modeling approach for SoS architecture is proposed by taking full advantage of DM2 and the “datacentric” approach and de?ning the common model transformation speci?cation at the metamodel level to provide more ?exibility and adaptability for the construction of executable models directly from architectural data rather than from static models, as shown in Fig. 1. The approach is based on the metamodels of architectural data and executable formalism, which are established in Section III-A to guide the architectural

8

IEEE SYSTEMS JOURNAL, VOL. 8, NO. 1, MARCH 2014

Fig. 3. Fig. 2. Metamodel of high-level architectural data elements.

CPN metamodel (based on [15]).

organized, and maintained at the appropriate level of detail to support the common understanding and other speci?c objectives; it also establishes the basis for semantic consistency and integration within and across architectural descriptions and serves as a road map for the exchange and reuse of architectural information for architecture development and management in a toolset-agnostic methodology-agnostic environment. Thus, one can also use DM2 for executable modeling to take full advantage of its standard terminology and formal semantics. It is a fundamental architecture principle that architectural data elements should be grouped into six semantically complete communication interrogatives [i.e., WHO, WHERE, WHAT, WHEN, WHY, and HOW (5W1H)] as an architectural data taxonomy at the highest level to ensure consistency in the meaning of each data element [13], [20]. Moreover, DM2 is still a work in progress and can result in redundancy of its broad and diverse data types and associations (currently more than 500) for a speci?c problem, while an executable model can be de?ned as an integrated dynamic model of sequenced Activities (HOW) and their Events (WHEN) performed by Performers (WHO) to produce and consume Resources (WHAT) in Locations (WHERE) under speci?ed Rules and Conditions (WHY) [20]. Therefore, it is essential and advantageous for architecture modeling to reduce the large amount of information and capture core architectural data elements around 5W1H in DM2 in order to ensure the collection of all the necessary architectural instance data suf?cient enough to fully specify the executable models, while not necessarily providing all of the details demanded by a speci?c architecture. The initially hidden details can later be extended by each individual stakeholder for a speci?c problem. For instance, if one is incorporating the performance parameters and measures into a basic executable model constructed from core data elements and their associations, one may perform more complex cost-bene?t analysis that addresses not only the performance and effectiveness but also the dynamic cost of the capabilities realized in architecture. In this respect, a simpli?ed metamodel mainly based on the Capability and Activity metamodels of DM2 is established to formally describe core data elements around 5W1H and their associations (interrelations or interactions) at the high level, as depicted in Fig. 2. In particular, these core elements with respect to WHO, WHAT, WHERE, and HOW can be further generalized to more concrete concepts from capability, operational,

and solution-related perspectives, such as PERFORMER (Person Type, Organization, Service, and System), RESOURCE (Information, Data, and Material), LOCATION (Logical Location and Physical Location), CAPABILITY (Capability), and ACTIVITY (Operational Activity, Service Function, and System Function). The reader is referred to the literature of DoDAF 2.0 [13] for a detailed exposition on these core architectural data elements and their associations that are denoted in Fig. 2 and by italics in this section. The architectural data metamodel formalizes general or high-level data concepts and their associations with standard terminology and formal semantics. Thus, all the necessary architectural instance data in accordance with the architectural data metamodel can be collected, maintained, and shared among various organizations as a common, consistent, and integrated data dictionary. It can provide the best basis and opportunity for ensuring concordance among architectural models and increasing the potential for the management of common understanding knowledge and the ef?cient integration of information within or across the same or multiple architectures [10], [25]. Due to the existence of many different modeling languages and tools resulting in inconsistent representation for the same semantic content in current studies, this data metamodel will help to integrate the diversity of design methodologies and therefore provide more ?exibility and adaptability for executable modeling regardless of what modeling language or tool is employed in the development of architectural descriptions. The capability-based architectural data modeling process can be executed consistently with the architectural data metamodel to collect architectural instance data regarding these core elements and associations for executable modeling. Under the assumption that the capability requirements of SoS have been derived via the requirements analysis process, the sequences of Activities (activityPartOfActivity) with required Resource Flows can be identi?ed to achieve the desired Capabilities (activityPartOfCapability). Then, system- or service-based solutions which satisfy the resource ?ows and support the capabilities are ?nally obtained by answering a set of questions consistent with the metamodel, as to whether these Activities are performed by Performers (activityPerformedByPerformer) to produce and consume Resources (activityProducesResource and activityConsumesResource) in Locations (resourceInLocationType) under speci?ed Rules (ruleConstrainsActivity) and Conditions (activityPerformableUnderCondition) along with

GE et al.: NOVEL EXECUTABLE MODELING APPROACH FOR SYSTEM-OF-SYSTEMS ARCHITECTURE

9

TABLE I M APPING RULES B ETWEEN C ORE DATA E LEMENTS AND M ODEL E LEMENTS OF E XECUTABLE F ORMALISMS

their Measures (measureOfTypeActivity, measureOfTypeResource, and measureOfTypePerformer). Likewise, an executable formalism metamodel can also be established to formally de?ne the model elements and their associations of a target executable formalism that is of interest to the stakeholders. Subsequently, a “?t-for-purpose” executable model can be generated when the executable formalism metamodel is populated with architectural instance data. Wagenhals et al. [15] have established such a metamodel for CPN, as illustrated in Fig. 3.

B. Common Model Transformation Speci?cation Based on Metamodel-Level Mapping Rules In contrast to a static model, which focuses on particular aspects of the architecture, an executable model is an integrated model de?ning the time-dependent dynamic behavior around the core elements and associations from holistic 5W1H. Therefore, one can take full advantage of DM2 and the “data-centric” approach in the model transformation process to construct an executable model automatically by directly pulling related instance data of core data elements and associations collected in the previous data modeling process. Executable architecture modeling, in essence, abstracts all the necessary architectural instance data, which conform to the architectural data metamodel, to populate the executable formalism metamodel. A model transformation speci?cation based on higher level mapping rules is commonly used for carrying out a family of model-level transformations, particularly when using the same target executable formalism, whereupon contradictions or inconsistencies between architectural data and executable models can be easily detected. Therefore, the mapping rules should be de?ned at the metamodel level rather than between the elements of static and executable models, as current studies have done. Accordingly, the proposed approach establishes the mapping rules between the metamodels of architectural data and executable formalism as the common model transformation speci?cation regardless of which modeling language or tool different organizations employ in developing architectural descriptions. It requires an understanding of concepts or model elements, semantics, and syntax of the executable formalism and then

assigns its formal execution semantics to the core data elements and their associations with DM2. That is, one needs to compare the metamodels of architectural data and executable formalism and then establish the mapping rules between the elements of both metamodels with semantic consistency and complete bidirectional traceability. This means that the concepts captured in the architectural data metamodel and conveyed by the target executable formalism must be consistent; those expressing the same concept should have the same semantics; and all of the elements in the target executable formalism must have a mapping from a source architectural data element. Table I gives an illustration of some key mappings from the core architectural data elements and their associations (depicted in Fig. 2) to the model elements of executable formalisms (e.g., CPN and ExtendSim). C. Model-Level Transformation for Executable Models Based on the established model transformation speci?cation at the metamodel level, the model-level transformation of executable architecture modeling, in essence, is a process of converting the architectural instance data, which are consistent with the architectural data metamodel, to the executable model conforming to the executable formalism metamodel. That is, the metamodel-level mapping rules can be seen as guiding a series of operations to construct an executable model by extracting and transforming all the necessary architectural data from the instance of the architectural data metamodel to populate the target executable formalism metamodel. According to the key mappings given in Table I, the model transformation procedure of constructing an executable model of selected executable formalism from architectural data can be de?ned. As a markup language produced by the W3C that de?nes a set of rules for encoding documents both human-readable and machine-readable, XML has become a dominant representation format of arbitrary data structures for many of?ce-productivity tools and is commonly used for the interchange and sharing of data that can occur in a tool- and methodology-agnostic environment [13], [26]. XML technology like XML schema languages and eXtensible Stylesheet Language (XSL) speci?cations can provide new possibilities for expressing the key mapping rules and the model transformation procedure in code,

10

IEEE SYSTEMS JOURNAL, VOL. 8, NO. 1, MARCH 2014

Fig. 5.

Operational concept graphic of AI SoS (based on [18]). TABLE II A RCHITECTURAL I NSTANCE DATA FOR AI SoS (PARTIAL )

Fig. 4. Executable modeling with XML technology.

thereby enabling the automated creation of executable models, as shown in Fig. 4. An XML schema is de?ned to formally describe an XML document and check its validity by constraining the set of elements, their attributes, and the logical structure [26]. Thus, the metamodels of architectural data and executable formalism can be expressed as XML schemas, such as XSD and Document Type De?nition (DTD), by mapping every element in each metamodel to appropriate constructs available in the corresponding XML schema; accordingly, the architectural instance data and executable models can be expressed as an XML instance document conforming to an XML schema (XSD or DTD) of their metamodels, respectively. The metamodels of architectural data in DoDAF 2.0 are expressed as DM2 PES XSDs to provide the neutral format for data exchange between architectural data and various data sources, while the model ?les of executable formalism, such as the CPN models in CPN Tools, are XML documents associated with and de?ned by a DTD or XSD. Note that, for those executable model ?les like ExtendSim that are not in XML, a translator needs to translate XML documents to and from the model ?les. Since architectural instance data, as well as some executable models, can be expressed in an XML instance document associated with an XML schema, the metamodel-level mapping rules can be expressed in code using the XSL speci?cations. XML Path Language (XPath) de?nes XPath expressions to select nodes from the XML document of architectural instance data to extract all the information needed for the construction of executable models. Then, the XSL Transformation (XSLT) processor can be employed for implementing the transformation process from the XML document of architectural instance data to the document of executable models in XML format or other formats according to the procedure for model-level transformation. Consequently, during each of the iterative architecture re?nements for an SoS architecture, one does not need to develop the architectural models from scratch. In fact, it is only necessary to implement some actions, such as elements

or attributes being added to or deleted from an XML schema, and instances of elements or attributes being added, deleted, or updated in corresponding XML instance documents. IV. I LLUSTRATIVE E XAMPLE A notional example of Air Interdiction (AI) SoS, previously published by Abusharekh et al. [18], is used to illustrate the feasibility of the proposed executable modeling approach in comparison with the executable modeling process of their approach. It is based on the operational concept that the AI SoS is expected to provide the capabilities of protecting a restricted key area against intruders (or threats), as shown in Fig. 5. That is, when any possible intruder is detected, an interceptor is sent to intercept and take different forms of engagement according to the hostility level and status of the intruder. The threats must be killed within a speci?ed time (e.g., 400 s); otherwise, they will be leakers and able to attack the targets. As reviewed in Section II-B, Abusharekh and Levis et al. ?rst developed the DoDAF-compliant architectural products using the structured analysis methodology and then constructed

GE et al.: NOVEL EXECUTABLE MODELING APPROACH FOR SYSTEM-OF-SYSTEMS ARCHITECTURE

11

TABLE III XML R EPRESENTATIONS OF K EY A RCHITECTURAL I NSTANCE DATA (PARTIAL )

TABLE IV P ROCEDURE FOR M ODEL -L EVEL T RANSFORMATION OF CPN M ODELS

the executable models following the three-process framework for architecture design and evaluation. In [18], a CPN executable model of the Operational View was synthesized from four architectural models: the activity model (IDEF0), the data model (IDEF1X), the rule model (the nested pattern of if–then–else–so), and the state transition diagram. Instead, the proposed approach of this paper ?rst applies the capability-focused architectural data modeling process to capture architectural data of core elements and associations (see Fig. 2) needed to provide the capabilities of AI SoS. Table II shows the partial architectural instance data of data elements

collected for this example. These architectural instance data of data elements, as well as their associations, can be represented as XML instance documents in accordance with the architectural data metamodel, as illustrated in Table III. In this example, CPN is used as the target executable formalism (its metamodel is shown in Fig. 3). As mentioned earlier in Section III-C, the transformation procedure should be established according to the mapping rules between metamodels of architectural data and CPN. Table IV gives the model transformation procedure from architectural data to CPN models. Altova Mapforce, which is a visual data mapping tool for advanced data integration projects, can be employed to accomplish the transformation by an automatically generated XSLT 1.0 or 2.0 style sheet, the built-in execution engine, and generated program code. It helps map XML data for de?ning and executing XML mappings between the source and target schemas (XSDs or DTDs). That is, when creating an XSLT transformation for the executable modeling, a source schema for the architectural data metamodel is mapped to a target schema for the executable formalism metamodel. Thus, elements and attributes in the source schema are connected to other elements and attributes in the target schema by placing connectors between the components of source and target schemas in the Mapforce tool, as shown in Fig. 6. Then, the XML documents of architectural instance data are converted to the XML format for CPN Tools based on the generated XSLT code. The resulting XML instance document of a CPN executable model, which contains data originating from the XML document of architectural instance data, can also be validated against the target schema. When additional information (e.g., performance parameters and measures) is incorporated into this basic executable model, one can carry out different forms of architecture analyses. V. C ONCLUSION In this paper, a novel executable modeling approach for SoS architecture has been proposed by taking full advantage of

12

IEEE SYSTEMS JOURNAL, VOL. 8, NO. 1, MARCH 2014

Fig. 6. Mappings between XML schemas with Altova Mapforce.

the common terminology and formal semantics of DM2 and de?ning a common model transformation speci?cation at the metamodel level, while addressing the collective shortcomings of current studies. This methodology provides more ?exibility and adaptability to the automated construction of executable models directly from architectural data, which aligns well with the “data-centric” architectural description. The metamodel of architectural data is ?rst de?ned to guide the architectural data modeling to collect architectural instance data of core data elements and their associations in DM2, which can act as a common, consistent, and integrated data dictionary for architecture modeling, and the executable formalism metamodel is designed to formally de?ne “?t-for-purpose” executable models. Next, the mapping rules are established between both metamodels as the common transformation speci?cation for executable modeling to be effective on a family of model transformations, no matter what modeling language or methodology is employed in developing architectural descriptions. Then, XML technology like XML schema languages and XSL speci?cations is discussed to facilitate the automated transformation of executable models from architectural instance data. Finally, the feasibility of the proposed approach is illustrated through a published example using CPN as the executable formalism. The proposed approach is particularly well suited for executable architecture modeling of the challenging SoS characterized by increasing complexity and uncertainty in requirements and context with a great demand for more evolving architecture re?nements, although it can be also readily applicable to other traditional or complex systems. Moreover, civil and military communities, who employ some different architecture frameworks rather than DoDAF 2.0 and its predecessors to develop their architectures, can also apply the principles of this approach for their executable modeling by using a translator or making some revisions to the terminology of data elements. The ongoing and future work of the authors is aimed at follow-up analyses that can provide further useful insights on

SoS architecture and generate valuable decision guidance on the basis of executable models. Activity-based costing can be employed to provide realistic and repeatable cost-bene?t analysis to address not only the performance but also the operating cost of the architecture. Sensitivity analysis can be performed on an executable model to conduct controlled experiments to explore how much of an impact a particular variable has on the model as a whole. In addition, simulation-based optimization can be utilized to determine ideal values for variables in an executable model to ?nd the acceptable solutions. ACKNOWLEDGMENT The authors would like to thank Mr. C. Hipel for his kind assistance in improving the presentation quality of this paper. The authors are grateful to the Editor-in-Chief, Editor, and Editorial Manager for handling the processing of their paper. The authors greatly appreciate the thoughtful comments and constructive suggestions put forward by three anonymous referees for improving the quality of their paper. R EFERENCES
[1] K. W. Hipel, M. M. Jamshidi, J. M. Tien, and C. C. White, III, “The future of systems, man, and cybernetics: Application domains and research methods,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 37, no. 5, pp. 726–743, Sep. 2007. [2] J. A. Lane and R. Valerdi, “Synthesizing SoS concepts for use in cost modeling,” Syst. Eng., vol. 10, no. 4, pp. 297–308, Oct. 2007. [3] C. B. Keating and P. F. Katina, “Systems of systems engineering: Prospects and challenges for the emerging ?eld,” Int. J. Syst. Syst. Eng., vol. 2, no. 2/3, pp. 234–256, Jun. 2011. [4] M. Jamshidi, “Introduction to system of systems,” in System of Systems Engineering: Innovations for the 21st Century, M. Jamshidi, Ed. New York, NY, USA: Wiley, 2009, ch. 1, pp. 1–20. [5] A. Gorod, B. Sauser, and J. Boardman, “System-of-systems engineering management: A review of modern history and a path forward,” IEEE Syst. J., vol. 2, no. 4, pp. 484–499, Dec. 2008. [6] A. H. Levis, “System architectures,” in Handbook of Systems Engineering and Management, A. P. Sage and W. B. Rouse, Eds., 2nd ed. Hoboken, NJ, USA: Wiley, 2009, ch. 12, pp. 479–506.

GE et al.: NOVEL EXECUTABLE MODELING APPROACH FOR SYSTEM-OF-SYSTEMS ARCHITECTURE

13

[7] J. F. Andary and A. P. Sage, “The role of service oriented architectures in systems engineering,” Inform. Knowl. Syst. Manag., vol. 9, no. 1, pp. 47– 74, Jan. 2010. [8] M. A. Corsello, “System-of-systems architectural considerations for complex environments and evolving requirements,” IEEE Syst. J., vol. 2, no. 3, pp. 312–320, Sep. 2008. [9] C. Piaszczyk, “Model based systems engineering with Department of Defense architectural framework,” Syst. Eng., vol. 14, no. 3, pp. 305–326, Jul. 2011. [10] A. L. Ramos, J. V. Ferreira, and J. Barceló, “Model-based systems engineering: An emerging approach for modern systems,” IEEE Trans. Syst., Man, Cybern. C, Appl. Rev., vol. 42, no. 1, pp. 101–111, Jan. 2012. [11] T. Ender, R. F. Leurck, B. Weaver, P. Miceli, W. D. Blair, P. West, and D. Mavris, “Systems-of-systems analysis of ballistic missile defense architecture effectiveness through surrogate modeling and simulation,” IEEE Syst. J., vol. 4, no. 2, pp. 156–166, Jun. 2010. [12] Y. Y. Haimes, “Modeling complex systems of systems with phantom system models,” Syst. Eng., vol. 15, no. 3, pp. 333–346, Jul. 2012. [13] DoD Architecture Framework Working Group, DoD Architecture Framework, Aug. 2010. [Online]. Available: http://dodcio.defense.gov/Portals/ 0/Documents/DODAF/DoDAF_v2-02_web.pdf [14] R. Wang and C. H. Dagli, “Executable system architecting using Systems Modeling Language in conjunction with colored Petri nets in a modeldriven systems development process,” Syst. Eng., vol. 14, no. 4, pp. 383– 409, Oct. 2011. [15] L. W. Wagenhals, S. W. Liles, and A. H. Levis, “Toward executable architectures to support evaluation,” in Proc. Int. Symp. CTS, Baltimore, MD, USA, 2009, pp. 502–511. [16] I. Khan, “Methodology for the development of executable system architecture,” in Proc. 8th Int. Conf. FIT , Islamabad, Pakistan, 2010, pp. 1–4. [17] B. Ge, K. W. Hipel, L. Li, and Y. Chen, “A data-centric executable modeling approach for system-of-systems architecture,” in Proc. 7th Int. Conf. SoSE, Genoa, Italy, 2012, pp. 368–373. [18] A. Abusharekh, S. Kansal, A. K. Zaidi, and A. H. Levis, “Modeling time in DoDAF compliant executable architectures,” in Proc. CSER, Hoboken, NJ, USA, 2007, pp. 1–10. [19] T. V. Huynh and J. S. Osmundson, “A systems engineering methodology for analyzing systems of systems using the Systems Modeling Language (SysML),” in Proc. 2nd Annu. Conf. Syst. Syst. Eng., Fort Belvoir, VA, USA, 2006, pp. 1–27. [20] S. J. Ring and D. Nicholson, “Activity-based methodology for development and analysis of integrated DoD architectures,” in Handbook of Enterprise Systems Architecture in Practice, P. Saha, Ed. Hershey, PA, USA: Information Science Reference, 2007, ch. 5, pp. 85–113. [21] K. Griendling and D. Mavris, “An architecture-based approach to identifying system-of-systems alternatives,” in Proc. 5th Int. Conf. SoSE, Leicestershire, U.K., 2010, pp. 1–6. [22] A. W. Zinn, “The use of integrated architectures to support agent based simulation: An initial investigation,” M.S. thesis, Dept. Aero. Astro., Air Force Inst. of Technol., Wright Patterson AFB, OH, USA, 2004. [23] S. Mittal, “DEVS uni?ed process for integrated development and testing of service oriented architectures,” Ph.D. dissertation, Dept. Electr. Comput. Eng., Univ. of Arizona, Tucson, AZ, USA, 2007. [24] Meta Object Facility (MOF) Core Speci?cation, Object Management Group, Needham, MA, USA, Jan. 2006. [25] M. Gaeta, F. Orciuoli, S. Paolozzi, and S. Salerno, “Ontology extraction for knowledge reuse: The e-learning perspective,” IEEE Trans. Syst., Man, Cybern. A, Syst. Humans, vol. 41, no. 4, pp. 798–809, Jul. 2011. [26] Extensible Markup Language (XML) 1.1, 2nd ed. Cambridge, MA, USA: W3C, Aug. 2006, Recommendation.

Keith W. Hipel (M’90–SM’92–F’96) received the B.A.Sc. degree in civil engineering, the M.A.Sc. degree in systems design, and Ph.D. degree in civil engineering from the University of Waterloo, Waterloo, ON, Canada in 1970, 1972, and 1975, respectively. He is currently a University Professor of systems design engineering and the Coordinator of the Con?ict Analysis Group, University of Waterloo. He is the Chair of the Board of Governors at Renison University College, Waterloo. His major research interests are the development of con?ict resolution, multiple objective decision making, and time series analysis techniques from a systems thinking perspective with applications in water resources management, hydrology, energy, environmental engineering, and sustainable development. Prof. Hipel is a Senior Fellow at the Centre for International Governance Innovation and the President-Elect of the Academy of Sciences within the Royal Society of Canada (RSC). He has received widespread recognition for his interdisciplinary research in systems engineering via Fellow designations from the RSC, IEEE, International Council on Systems Engineering, Canadian Academy of Engineering, American Water Resources Association, and Engineering Institute of Canada. He has served as an Associate Editor of many international journals, including the IEEE T RANSACTIONS ON S YSTEMS , M AN , AND C YBERNETICS and IEEE S YSTEMS J OURNAL . He was the recipient of the Japan Society for Promotion of Science Eminent Scientist Award; Norbert Wiener Award from the IEEE Systems, Man, and Cybernetics Society; Docteur Honoris Causa from the ?cole Centrale de Lille, Villeneuve-d’Ascq, France; Sir John William Dawson Medal from the RSC; and Engineering Medal for Research and Development from Ontario Professional Engineers.

Kewei Yang received the B.E. degree in systems engineering and the Ph.D. degree in management science and engineering from the National University of Defense Technology, Changsha, Hunan, China, in 1999 and 2004, respectively. In 2011–2012, he was a Visiting Scholar in the Department of Computer Science, University of York, York, U.K. He is currently an Associate Professor of management science and engineering and the Director of the System-of-Systems Engineering Laboratory, National University of Defense Technology, and a Visiting Scholar at the Science and Technology on Complex Systems Simulation Laboratory, Beijing, China. His research interests focus on intelligent agent simulation, defense acquisition, and system-of-systems requirement modeling. Dr. Yang has been a member of the Youth Working Committee in the Systems Engineering Society of China since 2009.

Bingfeng Ge (S’11) received the B.E. degree in systems engineering and the M.E. degree in management science and engineering from the National University of Defense Technology, Changsha, Hunan, China, in 2006 and 2008, respectively, where he is currently working toward the Ph.D. degree in management science and engineering, carrying out research in system-of-systems engineering and systems architecture development. From September 2011 to October 2012, he was a visiting Ph.D. student with the Con?ict Analysis Group, Department of Systems Design Engineering, University of Waterloo, Waterloo, ON, Canada. Mr. Ge is a member of the IEEE Systems, Man, and Cybernetics Society and the International Council on Systems Engineering.

Yingwu Chen received the B.E. degree in automation and the M.E. and Ph.D. degrees in systems engineering from the National University of Defense Technology, Changsha, Hunan, China, in 1984, 1987, and 1994, respectively. He is currently a Professor of management science and engineering and the Vice Dean of the College of Information System and Management, National University of Defense Technology. His major research interests are system-of-systems engineering and management, system planning, management and decision making, and arti?cial intelligence. Prof. Chen has been an Executive Director of the Systems Engineering Society of China since 2010.


相关文档

2013-A data-centric capability-focused approach for system-of-systems architecture modeling&analysis
An advanced physical modeling approach for brake system performance analysis
A NOVEL BROADBAND RECEIVER ARCHITECTURE FOR WIRELESS COMMUNICATION AND RADAR SYSTEMS
[ac02++++]A descriptor system approach to H∞ control of linear time-delay systems
1A novel modeling approach for the fleet deployment problem within a short-term planning horizon
A new approach for reduced order modeling of mechanical systems using vibration measurements
Modeling Social Aspects of Multiagent Systems The AML Approach
Modeling and analysis of a scheduled maintenance system a DSPN approach,” The Computer
A Meta Modeling Approach for Workflow Management System Supporting Exception Handling
DESIGNING FOR CHANGE A MODELING AND SIMULATION SYSTEM APPROACH
电脑版