Model-Based Systems Engineering in Support of Complex Systems Development J. Stephen Topper and Nathaniel C. Horner odel-based systems engineering techniques facilitate complex system design and docu- mentation processes. A rigorous, iterative conceptual development process based on the Unified Modeling Language (UML) or the Systems Modeling Language (SysML) and consisting of domain modeling, use case development, and behavioral and structural modeling supports design, architect- ing, analysis, modeling and simulation, test and evaluation, and program management activities. The resulting model is more useful than traditional documentation because it represents structure, data, and functions, along with associated documentation, in a multidimensional, navigable format. Beyond benefits to project documentation and stakeholder communication, UML- and SysML-based models also support direct anal- ysis methods, such as functional thread extraction. The APL team is continuing to develop analysis techniques using conceptual models to reduce the risk of design and test errors, reduce costs, and improve the quality of analysis and supporting modeling and simulation activities in the development of complex systems. INTRODUCTION A team from APL has been using model-based sys- net-centric operations and warfare domain, which has tems engineering (MBSE) methods within a conceptual proven particularly challenging to the modeling, simula- modeling process to support and unify activities related tion, and analysis community because of its complexity, to system-of-systems architecture development; model- information richness, and broad scope. ing, simulation, and analysis efforts; and system capabil- In particular, the APL team has used MBSE tech- ity trade studies. These techniques have been applied to niques to provide structured models of complex systems support analysis of complex systems, particularly in the incorporating input from multiple diverse stakeholders JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 1 (2013) 419 J. S. TOPPER AND N. C. HORNER to support understanding of critical components, inter- • Structural model: This specification of system struc- faces, and processes of these systems, and to document ture allocates attributes and operations to system explicit traceability between analytical needs and the components, expanding and adding detail to the simulations designed to meet them. domain model. This article provides an overview of the conceptual The process is shown in Fig. 1 and is described in modeling process used to support these goals, presents more detail below. a simple example to illustrate the process, and explains The conceptual modeling process provides an essen- some of the analytical techniques that can be applied tial foundation as a project moves from problem space to directly to such models. It concludes with a discussion of solution space. In the early stages, the domain models the broader benefits of this approach. and use cases provide a basis for analyzing needs and identifying problem parameters. Once the concept space is modeled, possible solutions can be developed during OVERVIEW OF THE CONCEPTUAL MODELING creative synthesis in the configuration space. PROCESS Finally, each configuration is evaluated using an applicable analysis process. It is during this evaluation In brief, a conceptual model is a complete, coherent step, not before, that M&S or another analysis meth- representation of a system and its operating domain, odology is carried out based on what has been learned including interactions with other systems and with its and specified during the previous iteration of the con- environment, that is common across the stakeholder ceptual development cycle. The results of this evaluation community. Conceptual models are created to docu- are then reflected in alterations to the conceptual model ment and understand a problem and its context and during a subsequent iteration; the cycle is repeated as to provide a foundation for developing and analyzing many times as is necessary to develop a robust solution potential solutions—regardless of the method for that (e.g., a final system design or an M&S architecture). analysis, which may or may not include modeling and Ultimately, the process provides a coherent view of a simulation (M&S). system and its domain that can be used (and reused) as The general goal behind conceptual modeling is to a basis for analysis of the system configuration, behavior, establish a framework that facilitates understanding of and alternatives. It can also form the basis for software the problem space, synthesis of possible solutions, and model design in the event that an M&S effort is desired. analysis of those identified solutions. The process devel- The process helps project stakeholders transform oped and used to build the conceptual model involves informal descriptions of systems into formalized, com- creating the following artifacts: plete documentation. Each step produces output that • Domain model: This artifact describes what the provides traceability from the final product back to ini- system and its environment are—it captures the tial descriptions and assumptions. The process forces high-level components of the system and its oper- domain understanding before design, evaluation, and ating environment and establishes the normalized development. referential framework particularly important for multidisciplined stakeholder organizations. Guiding Principles Several overarching principles guide the conceptual • Use cases: These written descriptions of what the modeling process. system will do capture its expected behaviors and its interactions with external actors. Breadth-First Development (or, Scope Before Fidelity) • Functional model: The functional model describes Scope is defined as the area within the boundaries how the system will accomplish its goals—it breaks of the problem space. Fidelity is defined as the level of the use cases into greater detail and shows activity detail incorporated into the modeling or analysis activi- flows and state transitions among components. Com- ties associated with the problem. The modeling process plex functionality, an increasingly common char- dictates a breadth-first approach in which the scope is acteristic of modern systems, is difficult to address covered comprehensively before fidelity is addressed. using traditional assessment techniques. In conjunc- This mandate forces designers and analysts to thor- tion with other artifacts presented in this section, oughly and objectively define the problem domain scope new techniques, outlined in the Functional Thread and prevents “jumping ahead” to selection of a particular Analysis section, enable and enhance analysis, test- analysis methodology, development of simulation tools, ing, and evaluation of complex systems, which are or premature conclusions. difficult to assess using traditional analytical meth- We first capture the entire domain at a high level of odologies and tools. abstraction and then drill down into more detail where 420 JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 1 (2013) MODEL-BASED SYSTEMS ENGINEERING IN SYSTEMS DEVELOPMENT The How the components system’s collaborate to accomplish goals system goals Realization Behavioral diagrams Use cases (particularization) (activity and state, with class mappings) Operator Parameter Creative identication synthesis Structural diagrams Problem (class and block diagrams) Solution space x y z space Domain models x ya yb yc y Concept Conguration Evaluation z space space How individual components support system The components of the goals: system and its specication for environment Abstraction attributes and (generalization) operations Needs and area analysis Solutions analysis Figure 1. Conceptual modeling process and the systems development process. (Some concepts in this diagram are adapted from Ref. 1.) such detail is necessitated by the problem. This approach stand the context of their use. A development strategy fulfills several important roles. First, by scoping the based on the conceptual modeling practices described problem before developing fidelity, it ensures that effort in this article places emphasis on ensuring that cur- and resources are not wasted on work that does not con- rent work will remain relevant and useful for future tribute to the current task (i.e., work that falls outside projects. Processes should be well defined, documented, the problem scope). Second, it ensures that no pertinent and repeatable, products should be reusable and extend- areas of the domain are ignored. A project that moves able, and analysis results should add to the general body too quickly toward detailed analysis of the most acces- of knowledge used in future studies. This philosophy sible elements in the problem space risks ignoring sig- means that, again, projects are started at a more gen- nificant elements at the periphery of the domain. Each eral level than they would be if they were aimed at a element in the domain outside of the problem scope single-use solution, but these generic initial outputs pro- should be placed there explicitly after consideration, not vide a common starting point for future work and reduce excluded by default. Third, the approach establishes a duplication of effort. Defined, repeatable processes also basic understanding of the problem domain composition reduce project scope, schedule, and resources required at the beginning of the effort that, through extension, for future