A description of the architecture of a complex system contains an enormous amount of ­information—far more than any single human can readily comprehend. How should we ­present this information? There are essentially two choices. We can maintain an integrated model and form projections when they are needed, or we can maintain multiple views in the model.

These two approaches can be seen in traditional civil architecture. Before there were 3D computer rendering tools, an architect would draw several views (a floor plan of a building, façades, and several sections), and these views would be the documents that guided construction. But there would be no guarantee that the views would be consistent and that they would produce a building with all parts connected.

Since the advent of 3D rendering, civil architects have been able to construct an integrated 3D model. If the civil architect needs a specific view, the software projects the model onto the 2D plane that shows us what we want to emphasize: a floor plan, façade, or section. The projections are certain to be consistent, because they came from the same 3D model.

The same options exist for system architectures. We can construct a larger integrated model and, when necessary, project it to get views. Or we can start by constructing the views, with only limited confidence that they will yield a consistent whole. Both of these approaches are in ­common practice.

The integrated-model school is represented in contemporary tools by the Object Process Methodology (OPM). [4] These approaches try to incorporate information about form, function, entities, and relationships into one model. An alternative approach is to use a representation that develops individual views. Both the Systems Modeling Language (SysML) [5] and the Department of Defense Architecture Framework (DoDAF) [6] use this approach.

SysML and OPM are discussed below. Both tools appeared at approximately the same time in the early 2000s, and both are widely used. Note that this introduction provides only an overview of the tools, without going into the details of the different views and diagrams, which are best obtained by reviewing the references. Further details for both approaches are described in Part 2.

SysML was developed in 2003 as a joint effort of the Object Management Group (OMG) and the International Council on Systems Engineering (INCOSE) to adapt the software engineering Unified Modeling Language (UML) [7] to the needs of systems engineers. SysML uses a subset of UML and adds several features oriented toward modeling system requirements and performance.

The original UML consists of thirteen diagrams or views. Six of them are used to ­describe software structure (class diagram, package diagram, object diagram, component diagram, composite structure diagram, and deployment diagram). The other seven UML diagrams are used to describe software behavior (state machine diagram, activity diagram, use case diagram, ­sequence diagram, communications diagram, timing diagram, and interaction overview diagram).

As shown in Figure 3.5, the most recent version of SysML (2009) consists of nine views. Seven of these views are directly taken from UML: the class diagram (renamed the block definition diagram), the package diagram, the composite structure diagram (renamed the internal block diagram), the activity diagram, the state machine diagram, the use case diagram, and the sequence diagram. Two new views were added: a parametric diagram and a requirement diagram.

The reader may wish to refer to SysML for Systems Engineering (Holt and Perry 2008) for a more comprehensive discussion. [8] In Figure 3.5, the block definition diagram and the internal block diagram represent the system form: The block definition diagram represents the elements, and the internal block diagram represents their structure. We develop these ideas further in Chapter 4.

The requirements diagram captures the text for and relationships among requirements. (This is analogous to our discussion of stakeholders and goals in Chapter 11.) The parametric diagram represents information on property values and constraints; it contains more detail than is generally encountered in architectural analysis. The package diagram is used to bookkeep the model elements.

The four behavioral diagrams represent the functional domain and associated behavior. The use case diagram portrays what in Chapter 5 we call externally delivered function and value. The remaining three diagrams represent various aspects of function and time-dependent behavior discussed in Chapters 5 and 6.

OPM was developed by Professor Dov Dori at Technion with the goal of unifying the object- and process-oriented paradigms for describing systems in a single methodology.

In OPM, objects (which appear in SysML Structural Diagrams) are represented by boxes and are discussed in Chapter 4. Processes (which appear in SysML Behavioral Diagrams) are represented by ovals and are discussed in Chapter 5. In OPM, however, objects and processes appear in one diagram and are connected through different types of relationships: The object can be an instrument of a process, or the object can be changed by the process (Figure 3.6). We discuss these relationships in Chapter 6.

An important feature of OPM is that it does not have different views or types of diagrams for a system but, rather, a single integrated model. The information in many of the SysML diagrams can be represented with a single diagram in OPM, using objects, processes, and relationships.

Both SysML and OPM are expressive enough to represent system architecture, and they contain many of the same features. For example, Table 3.2 provides equivalent representations of the decomposition and logical relationships between entities introduced in this chapter. Translating entire representations is a more complicated task. See, for example, Grobshtein and Dori (2009) on how to generate SysML views from an OPM model. [9] We will use OPM as the primary tool for architecture representation in this text, but we will refer to relevant SysML diagrams as needed.

Relationship	SysML	OPM
Decomposition/ aggregation
Specialization/ generalization
Class/instance