Model-Based Systems Engineering with OPM and SysML

We live in a world of interconnected systems. In fact, as humans, each of us is a highly complex system living in a host of socio-political-technological systems that are no less complex. In order to understand and design complex systems, it is necessary to have a methodology and a language for building models that can express what these systems do, why they do it, how they do it, and what they need in order to do it. While the visual and intuitive nature of diagrams has made them widely used means for building models of systems, natural language text is also an important way of conveying complex ideas. Formal diagrams are a graphic language in that they contain interconnected symbols, expressing meaningful facts and statements about the world. Combining graphics with text reinforces our ability to specify complex ideas in science and engineering.

Winograd and Flores (1987) noted that “Nothing exists except through language… In saying that some ‘thing’ exists (or that it has some property) we have brought it into a domain of articulated objects and qualities that exist in language.”

Links are graphical expressions of relations between things. OPM links connect processes with objects or their states, providing meaning to relationships among them. This chapter expands the use of links in our model and explains the semantics of various kinds of links.

We leave OPM for a while and turn to start our parallel SysML model. SysML is a multi-view language, where each view uses a different type of diagram. There are nine SysML diagram types in total. In this chapter we are exposed to three diagram types: the use case diagram, the block definition diagram, and the state machine diagram. The use case diagram shows the context of the system and how the system is used to bring value to at least one of its actors. The block definition diagram presents the blocks of the system—major entities of interest. The state machine diagram shows how states of blocks in the system are changed. Comparing OPM and SysML, we already see that the approaches they take are different and complementary. OPM uses a single model that combines the various system aspects, while SysML uses a number of diagram types, each focusing on some particular aspect of the system.

The previous chapters have exposed us to the basic concepts of OPM, yet we have barely scratched the surface of the system we are modeling. In this chapter, we specify more details about the system while revealing some more modeling concepts of OPM and how they can be utilized to represent our system in more detail. In order to examine the text that specifies the system we are modeling, we return our focus to information from the first sentences:

Continuing with modeling our case study, in this chapter we further discuss process issues, such as execution order and how to specify that processes are sequential, concurrent, or alternative. These issues are related to the system's dynamic aspect and to its operational semantics.

Control in the context of conceptual modeling is the ability to determine the flow of processes and how they transform objects under various conditions and circumstances. Several control structures enable us to determine how the system will behave over time. These include Boolean objects for branching and control modifiers—condition and event indicators that are added to procedural links and augment their semantics. In this chapter we discuss and show how control structures are used to model system behavior.

So far we always increased the refinement (detail) level of our model and we did it via zooming into processes. There are cases where we need to decrease the refinement level, or, in other words, abstract the model. This can happen when we realize that there are too many details already squeezed into a single diagram, making it too crowded and hence less comprehensible. We do not want to delete details of the model, as they are important for complete system specification. Yet we want then taken out of a specific crowded diagram. We do this by creating a new OPD at an intermediate detail level by zooming out of the too detailed OPD and creating one at a higher level of abstraction. In this chapter we focus on this abstracting process and then discuss and improve a structural view of the system.

Before going into formal presentations of OPM and SysML as conceptual system modeling languages and OPM as a systems engineering methodology, we discuss the theoretical aspects underlying the framework of systems, systems architecture, and systems engineering, within which conceptual modeling is a valuable intellectual activity.

Immanuel Kant said that “Objects are our way of knowing.” While this is obviously true, it is not the whole truth, but only about half of it. Objects are our way of knowing what exists, or in other words, the of systems. To know what happens, to understand systems’ behavior, a second, complementary type of things is needed—processes. We know of the existence of an object if we can name it and refer to its unconditional, relatively stable existence, but without processes we cannot tell how this object is transformed—how it is created, how its states change over time, and how it disappears. These two fundamental concepts—objects and processes, generalized as things—are the focus of this chapter.

OPM is bimodal: it employs both the visual (graphical) modality—OPD, and the verbal (textual) modality—OPL. The textual OPL representation of the OPM model has both human-oriented and machine-oriented goals. This chapter is devoted to presenting OPL and discussing its merits.

Systems Modeling Language (SysML) is a profile of the Unified Modeling Language (UML), i.e., a customized version intended for systems engineering applications. We begin the presentation of SysML with a brief description of UML, followed by an overview of SysML and its various diagram types, with reference to OPM. Recall that while OPM uses a single model that combines the various system aspects and presents them in graphics and text, SysML uses nine diagram kinds, each focusing on some particular aspect of the system. We focus on the SysML diagram kinds that have not been discussed so far: sequence diagram, activity diagram, requirements diagram, and parametrics diagram. The shows the time flow and exchange of messages among blocks. The presents the activities performed by the system, their order and their control. The presents user and derived requirements that the system shall satisfy. Finally, the models the computations that take place in the system.

Systems change over time. An important motivation in the development of OPM has been to strike a needed balance in a system’s conceptual model between the structural, static and procedural, dynamic aspects of the system. The dynamic aspect of a system specifies how the system operates to attain its function, complementing its static aspect. OPM is at least process-oriented as it is object-oriented. Indeed, OPM models unify structure and behavior in one coherent frame of reference, with time being the fundamental underlying concept. This chapter addresses modeling the dynamics aspect of a system.

Structure pertains to the relatively fixed, non-transient, long-term relationships that exist among objects—components or parts of the system. Alternatively, structure can be viewed as a snapshot—a picture of the generally dynamic system, or part of it, at some point in time. This snapshot captures the entire system at some state, where each stateful object is at some state or in transition between two of its states, and specific relationships between objects hold. Structure is contrasted with the complementary dynamic aspect of the system, or its behavior, which has to do with the changes the system undergoes over time, along with the causes for and effects of these changes. In other words, structure is about the static aspect of the system, while behavior is about its dynamic aspect. This chapter is devoted to discussing the structure of systems and expressing it through OPM.

In all the examples and discussions so far we have tacitly assumed that each thing, be it object or process, participates in the relation singly, i.e., in a quantity of exactly 1. Indeed, the convention in OPDs is that when no quantity is explicitly recorded by the side of a structural link, it is taken to be 1, which is the default value. In general, however, we may wish to specify a certain number or a range of numbers of instances of the same class of things that participate in the relation. Similarly, our models so far have tacitly assumed that a process involves one object instance of each object class to which it is linked. Indeed, this is the default. However, it is sometimes required to model the fact that more than one object takes part in a process. Process participation constraints and link cardinalities are designed to take care of this. We then turn to another useful notation—the fork—which is based on the observation that structural relations are distributive in a sense analogous to the distributive law in algebra. This is graphically represented via forks, as defined, discussed and demonstrated in this chapter.

This chapter discusses the first fundamental structural relation, possibly the most important one: aggregation-participation—the relationship between the whole and its parts. Any interesting system can be described as a whole decomposed into parts. The system as a whole and any one of its parts can then be described separately using natural language adjectives to assign attribute values to objects and adverbs to assign attribute values to processes. Without the ability to mentally take things apart and examine their features, our ability to study systems would be greatly hindered. Aggregation-participation is also known as whole-part (Coad and Yourdon 1991), composition (Kilov and Simmonds 1996), or the part-of relationship (Fowler 1996).

To define and describe things in the world, natural languages use adjectives and adverbs. Without these types of words, which describe objects and are also interchangeably called attributes, features, qualities, characteristics, or properties, neither objects nor processes can be adequately distinguished and understood. Exhibition-characterization is the fundamental structural relation that binds a refineable (object or process)—the exhibitor, with a refinee—another object or process, called feature, which characterizes the exhibitor.

While discussing aggregation and exhibition, we talked about entire groups of objects or processes—any scientific paper, any employee, any running. However, what if we wanted to consider the example of a specific paper, written by a certain John Doe? Or if we wanted to consider a group of employees, namely managers, who receive a certain salary out of the range of salaries available for the company? Perhaps we would like to discuss running in a marathon, as opposed to just any kind of running? We need to be able to pay particular attention to a specialized group, which belongs to a more general group, or even a specific instance out of a class of objects. As its name clearly points out, generalization-specialization is the relation between a general and a special case of a thing. Classification-instantiation is the relation between a class of things and a unique instance from the class. Since these two concepts are important to systems modeling, we consider them two of the four fundamental relations; and since they are intimately related, they are discussed and explained together in this chapter.

The very need for systems analysis and design strategies stems from complexity. If systems or problems were simple enough for humans to be grasped by merely glancing at them, no methodology would have been required. Due to the need for tackling sizeable, complex problems, a system development methodology must be equipped with a comprehensive approach, backed by set of reliable and useful tools, for controlling and managing complexity. OPM provides four refinement-abstraction mechanisms to manage systems’ inherent complexity: (1) unfolding–folding, (2) in-zooming–out-zooming, (3) state-expressing–state-suppressing, and (4) view creating. These mechanisms, defined and discussed in this chapter, make possible the specification of contextualized model segments as separate, yet interconnected OPDs. Taken together, they provide a complete model of the functional, value providing system. These mechanisms enable presenting and viewing the modelled system, and the elements it contains, in various contexts that are interrelated by the common objects, processes and relations. The set of clearly specified and compatible interconnected Object-Process Diagrams completely specify the entire system to an appropriate extent of detail and provide a comprehensive representation of that system with a corresponding textual statement of the model in OPL. This chapter elaborates on complexity management issues and specifies the various abstracting-refining mechanisms.

To control the flow of system execution, OPM has precise operational semantics, based on the event-condition-action paradigm and expressed by modifying the procedural links with control modifiers—event and condition symbols. This is the focus of this chapter.

Logical operators, including AND, NOT, OR, and XOR (exclusive OR) enable modeling complex conditions on performance of processes. Using XOR, OPM can also assign probabilities to such outcomes as creating one of several possible objects, or an object in a specific state. We discuss these in this chapter.

This book contains a comprehensive coverage of OPM that is compatible with ISO 19450 Publically Available Specification (PAS) titled “Automation systems and integration—Object-Process Methodology”, and in French: “Systèmes d’automatisation et intégration—Méthodologie du processus-objet”. The ISO 19450 PAS has been adopted by the International Organization for Standardization (ISO) in December 2015 through the work of ISO Technical Committee 184/ Sub-committee 5 (TC184/SC5) after a six-year effort, mainly by Richard Martin, David Shorter, Alex Blekhman, and this author. This book was prepared in parallel with the ISO 19450 PAS standard, so the two are almost completely aligned with each other. Since the standard (formally PAS) must conform to the rules of ISO for standard authoring, it is structured differently and is not as elaborate as the book. Rather, it is an orderly exposition of OPM that enables tool developers to use it, along with this book, as a solid basis for developing an ISO 19450-complaint software tool to support OPM-based conceptual modeling. ISO standards like ISO 19450 PAS contain normative parts and often also one or more informative parts. To be compliant with the standard, a normative part must be strictly followed, while an informative part is not mandatory. This book is a superset of ISO 19450 PAS. About 90% of the material in this book is aligned with ISO 19450. The rest can be considered as the equivalent of an addition to the informative part of the standard—it should be followed, but ISO 19450 in its current initial form does not mandate it. This closing chapter describes briefly the content of the ISO 19450 PAS, where each section is devoted to a summary of one or more sections of ISO 19450.