Specializing a reference architecture
In this recipe, we will discuss the first of two approaches for using a reference architecture.
What is a reference architecture?
In Chapter 1, Basics of Agile Systems Modeling, we defined architecture as “the set of strategic design optimization decisions for the system.” The use of the word strategic here is important; these are design decisions that affect most or all subsystems and impact the overall performance and structure of the system. In the previous discussions, we went on to identify the six key views of architecture: the subsystem and component view, the concurrency and resource view, the distribution view, the data view, the dependability view, and the deployment view.
In the Pattern-driven architecture recipe in this chapter, we talked about how an architecture is an instantiation of patterns. In fact, a systems architecture is an integration of one or more patterns in each of the architectural viewpoints.
A reference architecture is an extension of this concept. A reference architecture is a pattern writ large; it is a combination of a set of patterns to define a master pattern for the architecture of a type of system, such as perhaps an aircraft, satellite, or medical ventilator. That means that a reference architecture generally cannot be used as-is. It must be instantiated for use to create specific system designs. In this recipe, I will call that process specializing the reference architecture.
Why would I use a reference architecture?
There are six main reasons for using a reference architecture.
Frame of reference
A reference architecture provides a frame of reference to get an overview of a system’s structure, organization, functionality, and behavior. Because the principles of the system’s architecture are defined by the reference architecture to which it complies, it becomes easier to understand how a system is put together and how to effectively maintain, update, and enhance the system.
Interoperability
Systems are almost never standalone islands of capability. They fit into both an engineering and an operational context. In the engineering context, we have common development tools, plug-and-play components, and other common elements to assist in design and development. In the operational context, we have concerns about the use, maintenance, and sustainment of the system in operation – including the dev sec ops culture, automation, and integration of the system into enterprise architectures.
Interoperability is also important when you have a portfolio of related systems. You will gain economy-of-scale advantages with common usable elements and designs across a portfolio. Reference architectures are a way of specifying that commonality.
Reuse of effective architectures
The vast majority of systems are rehashing or slight improvements on the existing design. We have decades of experience developing avionics and medical systems, for example. As we gain industrial experience with such systems, we learn which architectures are effective in practice (and not just in theory) and which are not. Complying with a reference architecture enables gaining these benefits with relatively little effort.
Benchmarking
Comparing metrics and outcomes of different systems is made easier when they are specializations compliant with a common reference architecture.
Regulatory compliance
In regulated industries, such as aerospace, automotive, and medical, gaining regulatory approval is crucial to a system’s success. Regulators often show a preference for architectures that have previously demonstrated that they are safe, secure, and effective. Reference architectures can provide that assurance.
Owning the baseline
In the US Department of Defense (DoD), a common concern is the ownership of the baseline technology and architecture. The DoD doesn’t develop the vast majority of systems that it owns but has them developed under an acquisitions process. One of the historical problems with the acquisitions approach is that the Original Equipment Manufacturers (OEMs) generally retain ownership of the system design as their intellectual property. This has the downside of vendor lock. The DoD can call for the development of a system – such as the F-35 aircraft – and purchase hundreds of millions of dollars worth of systems, but they do not own the design. As such, when it becomes necessary to modernize or update the system, the DoD cannot simply go through an open acquisitions process but is limited to working with the vendor who owns the design. This has led to the Modular Open Systems Approach (MOSA). See https://ac.cto.mil/mosa/
Using a reference architecture
A reference architecture is a collection of interlocking patterns for a kind of system or a set of systems in a kind of operational environment. Put another way, a reference architecture is a generalized set of abstractions that collectively organize a system at a strategic level. However, you don’t manufacture a reference architecture; you manufacture a specific architecture. The use of a reference architecture involves the specification of a specific system that complies with the reference architecture and instantiates the patterns that constitute it.
Purpose
The purpose of this recipe is to create a specific system design that conforms to a reference architecture. This recipe is particularly relevant whether you want to develop a new system type or simply a system instance.
Inputs and preconditions
The system’s primary capabilities have been identified and analyzed, along with a significant set of system requirements.
Outputs and postconditions
A reference architecture is selected and a specific system architecture is defined, especially with respect to conformance to the selected reference architecture.
How to do it
Figure 3.49 shows the workflow for this recipe:
Figure 3.49: Specializing a reference architecture
Select a reference architecture
In your industry, it is likely that reference architectures exist and are competing with each other. It may also be that there is a single reference architecture provided to you. It may even be that one of your engineering tasks is to develop a reference architecture.
In any case, this first step is to select the reference architecture with which your system must conform. This architecture should have, at a minimum:
- Definition of the operational context in which conformant systems exist both as type definitions (BDD) and connected architectures (IBD)
- Standardized and possibly generic interfaces to actors in the operational context
- Standard capabilities of a system that is conformant, generally represented as system use cases
- Composition architecture of the system, including identification of the subsystems relevant to conformance, and the multiplicities of those relations
- Type architecture of the system, including the key properties of the subsystems, such as ports, relations, key system data, and key system functions allocated to the subsystems
- Connected architecture shows how the subsystems connect (IBD)
- Standardized and possibly generic interfaces between the subsystems
Identify areas of deviation from reference architecture
There are several different ways that a specific architecture differentiates itself from the reference architecture to which it conforms:
- Specific subtypes of identified subsystems or components
- Specific implementation technologies
- Specific multiplicities of contributing design elements
- Addition of new capabilities
- Addition of new subsystem and design elements to support new capabilities
- Addition of greater levels of detail over what is specified in the reference architecture
Create a specific architecture type
This structured action contains the following sequence of actions. This sub-workflow is appropriate when you want to create a new type of system or when you want to add a fundamentally new capability to the specific architecture.
Define the specific system block
In this recipe, one of the outcomes is a new system type that is still conformant to the reference architecture. The new system block is that type.
Subclass relevant architectural elements
When developing specific architectures, it is very common to subclass an architectural element to redefine how a behavior is performed (also known as polymorphic behavior) or to extend the functionality of the element. In SysML, this is done by subclassing the element.
Redefine the specific architecture elements
Once the subclasses are defined, they must be referenced in the specific architecture at exactly the same point in which their super-classes are used in the reference architecture. This is done with a redefinition of the element in the specialized system.
Add new architectural elements
Of course, a specialized system may do additional things beyond the capabilities of the reference architecture. An E3 Sentry (AWACS) is a specific kind of aircraft and may be compliant with an aircraft reference architecture, but it is also a Command-and-Control Battle Management (C2BM) platform as well. Additional architectural elements must be added to support additional capabilities of the specific system.
Create a specific architecture instance
This structured action contains the following nested actions. This sub-workflow is used when you 1) don’t need to create a new type of reference architecture system and 2) you don’t need to add fundamentally new elements or capabilities to the specific architecture. It is always possible to refine and extend existing parts and capabilities in an instance, but it is difficult to add entirely new ones.
Define the specific system instance specification
Another approach to creating a specialized architecture is to create a specific instance, represented with an instance specification. This is most useful when you needn’t create a new type of system but merely wish to create a specific instance of the architecture. In this step, create an instance specification of the reference system.
Subclass relevant architectural elements
If the elements from the reference architecture are used as is, you can create instance specifications of those elements to plug them into the slots of the system instance specification. You may, however, want to put in specialized forms of those elements, so in this step, you may subclass some of the architectural elements.
Create instance specification of architectural elements
The system instance specification has slots for all its part properties. In this step, create an instance specification for every subsystem you want contained within the system instance.
Populate instance specification slots
In this step, you add the instance specifications of the architectural elements into the slots of the system instance specification.
Demonstrate compliance
The last step in this recipe is to demonstrate how the specific system complies with the reference architecture. This may be a simple matter if relations formally represent compliance when it is direct usage in the specific architecture or the subclassing of elements defined in the reference architecture. It is a bit more work when you don’t have the model of the reference architecture or when the reference architecture is notional or not formally defined.
Example
Select a reference architecture
For this example, we’ll start with a reference architecture for a generic Exercise Bike. The reference composition architecture for this system is shown in Figure 3.50:
Figure 3.50: Exercise bike reference composition architecture
This system has a Mechanical Frame, zero to two Gear Shifters, and a Power Train subsystem that contains an internal Pedal Assembly, Drive Train, and Resistance Assembly. If the system has at least one Gear Shifter, then it will also have a Computation Unit to change the resistance offered at the pedal assembly. Optionally, if the system has at least one Gear Shifter and a Computation Unit, it may also optionally have a Display and may also provide information via a Comms unit.
Figure 3.51 shows how these parts connect in the reference architecture:
Figure 3.51: Exercise bike reference connected architecture
One can imagine different specific architectures that could conform to this reference architecture. The simplest such system would have only the required subsystems of a mechanical frame and a power train.
Indeed, I trained on wind turbine trainers in the 1980s that worked just like that. More elaborate specific systems might add a dual shifter (simulating front chain rings and a rear cassette) and a computation unit that modifies the resistance, which might be provided hydrostatically by pushing fluid through variable valves or by varying resistance electronically with a motor. An even more elaborate system that still conforms to this reference architecture might add both a display of information about resistance and gearing, and even send it out through the (optional) communication system. Each of these variants can vary not only the multiplicity of elements (say, from 0 to 1) but also their type and implementation. A display could be done with simple LEDs, a low-resolution black and white screen, a high-resolution color display, or even a virtual reality headset. Communications can be similarly varied to support different kinds of networks and communication standards. Even with such a simple reference architecture, one can easily envision many different specific architectures derived from it.
Identify areas of deviation from the reference architecture
Let’s envision two systems, one for each of the different paths through the workflow. For the left workflow in Figure 3.49 (Create a specific architecture type), let’s develop an exercise bike that has a single shifter, a computational unit, and a nice large color display.
We’ll also add a communications link that uses Ethernet so we can log on to live training sessions offered by the League of Racers Extraordinaire server site. In addition, we’ll add a built-in fan for cooling off our sweaty user. For the right workflow (Create a specific architecture instance), let’s create a system with two shifters (for front and back shifting), and BLE for connection to a suitable phone or tablet running the Cycling God training application. This system will have no display, as the relevant data will be displayed by the training application.
We’ll do the left workflow first.
Define the specific system block
In this step, we simply create the League of Racers Extraordinaire (LORE) block and make it a subclass of the Exercise Bike block.
Subclass relevant architectural elements
For the LORE system, we need a special kind of display and a special communications unit that supports Ethernet. In addition, we subclass to change port multiplicity in the subclass; for example, the Computation Unit is subclassed so that the multiplicities of the ports can be set to specific values from the range of values in the reference architecture. The same is true for the Power Train and Resistance Assembly blocks. See Figure 3.52:
Figure 3.52: LORE architectural subclasses
Redefine the specific architectural elements
This is the secret sauce of this recipe. You must redefine the architecture with the subclassed elements and with the specific multiplicity in the LORE system.
To do this in Cameo, first, expose the inherited parts for the LORE symbol on the diagram with the Symbol Properties dialog. Then, right-click the part property in the block symbol you want to redefine and select Refactor > Redefine To. This pops up a dialog from which you can select the subclass you want. If you only want to change the multiplicity, use this same technique but select the original type, then open the specification dialog for the part and change the multiplicity. Figure 3.53 shows what that looks like for redefining the display part:
Figure 3.53: Redefining part properties in Cameo
The result of this redefines the parts inherited in the LORE block to the new subclasses and then part property multiplicity can be changed in their specifications dialog as needed. The redefinition of the port multiplicity, such as LORE::pExternalComms, must be done in the specification dialog for the owning block.
Once this is done, you have the parts redefined in the LORE system as shown in Figure 3.54:
Figure 3.54: LORE redefined
Add new architectural elements
Now we can add the Fan to the LORE block with a composition relation. We can see in Figure 3.55 the connected architecture of the LORE system with all its specialized parts and specific multiplicities:
Figure 3.55: LORE redefined connected architecture
Let’s now create the right workflow and create our specific instance of the Cycling God system. Remember that this system has two shifters and supports the BLE communications protocol.
Define the specific system instance specification
In this step, we add an instance specification named Cycling God of the Exercise bike block.
Subclass relevant architectural elements
We only really need to subclass Comms to BLE Comms because we want different behavior in the included element, that is, support for the BLE protocol.
Create instance specifications of architectural elements
The instance specifications for the architectural element of the Cycling God instance are shown in Figure 3.56:
Figure 3.56: Set of instance specifications
Populate instance specification slots
The next step is to populate the slots in the instance specifications. The Power Train has three instance slots, so they must be populated with the ra, pa, and dt instances. The Exercise Bike::Gear Shifter slot must hold both the left and right shifter instances.
The resulting instance specifications with populated slots are shown in Figure 3.57. Note that the names of the instances are given in the slots:
Figure 3.57: Populated instance specifications
In this latter example, we minimized the use of subclasses. Had we wanted to, we could have specialized the multiplicities of the ports and parts with subclassing and redefinition.
Join our community on Discord
Join our community’s Discord space for discussions with the author and other readers:
