MODEL-BASED SYSTEMS ENGINEERING AND OBJECT-ORIENTED SOFTWARE ENGINEERING: AN

INTEGRATED APPROACH

ABSTRACT
In this paper, we propose a framework for integrating model-based systems engineering and
object-oriented software engineering based on their interfaces. We show that the context,
behavior, and structure models captured by the systems engineering process are precisely
those inputs necessary to begin the object-oriented software engineering process. Conversely,
the object-oriented architecture generated by the software engineering process is needed by
systems engineering to perform object-based rather than function-based architecture synthesis.

INTRODUCTION
Most of the complexity in the modern-day systems is concentrated in the software. Significant
systems engineering effort must therefore be spent on the specification and integration of the
software subsystem. Research and proposals on how best to combine systems and software
engineering have long history. A recent example is the Object-Oriented Systems Engineering
Method proposed by the eponymous working group of the International Council on Systems
Engineering (INCOSE)[1a][1b]. The method has the stated goals to:
… facilitate integration of systems engineering with object-oriented (OO) software
engineering, and to apply OO modeling in a way that benefits the systems
engineering process.
However, these previous works tend to be systems engineering-centric or software
engineering-centric. The systems engineering-centric viewpoint tends to minimize the
contribution of software engineering to systems architecture where objects, not functions, are
allocated to components. The software engineering-centric viewpoint tends to ignore the
structured requirements artifacts generated by model-based systems engineering. In this
paper, we present an integrated model of systems and object-oriented software and explicitly
identify the types of information passed and when the transfer occurs. As a case study, we use
a simplified model of a TV-network satellite distribution system, derived from a real system
with which the author was involved.

THE MODEL-BASED SYSTEMS ENGINEERING PROCESS

The model-based systems engineering (MBSE) process is described in [2][3][4]. The model-
based systems engineering process still consists of the traditional steps of Requirements
Analysis, Functional Analysis, and Architecture Synthesis. However, the emphasis is on
capturing key aspects of the system using three main types of models: context, behavioral, and
structural. Context models contain the information needed to identify the relationships
between the system of interest and other systems. Behavioral models capture the dynamic
interactions. Structure models delineate the “built-from” relationship between a system and its
components and the aspects of the system that are inherited from other systems. These
models provide a simple and generic way to describe important properties of a system.
THE OBJECT-ORIENTED SOFTWARE ENGINEERING PROCESS
Object-oriented software engineering (OOSE) has become the process of choice for large-scale
software development. OOSE promotes abstraction, information hiding, and reusability, which
are all properties of well-designed software systems. Several frameworks encapsulating OOSE
exist. Examples include the Rational Unified Process [5], Feature Driven Development [6], and
Extreme Programming [7]. These processes are use case driven, architecture centered, and
iterative and incremental [8]. Inputs to the process are requirements in the form of use cases
and text descriptions of scenarios. When finished, the outputs of the OOSE architecture
development process (using Unified Modeling Language definitions [9]) are:
1. Class/Object diagrams showing the key abstractions and relationships between the
classes and objects in the application
2. Sequence/Collaboration diagrams showing the behavior of key objects in response to
external inputs
3. Deployment diagrams showing the allocation of objects to processes and processors
In some cases (such as real-time software) state diagrams further describe object behavior.

THE INTEGRATED MBSE/OOSE PROCESS

The major difficulties with integrating MBSE and OOSE lie at their interface. The systems
engineer traditionally wants to hand-off a structural architecture with functions allocated to
components to the software engineer. The software engineer wants to start from the customer
requirements to create the architecture. Either exchange ignores the important contribution
that each discipline brings to system design. By allocating functions to components
prematurely, the systems engineer ignores the reality that the OOSE process will generate an
object-based design, not a function-based one. The architecture must therefore be developed
by allocating objects, not functions, to components. In OOSE, the usual recommendation is that
customer requirements are captured in “use cases”- text descriptions of scenarios [9][10].
However, MBSE-derived models provide a richer source of information for the software
engineer than text descriptions of scenarios which:
a. cannot be executed
b. are difficult to merge, and
c. are hard to check for consistency

Our proposed integrated MBSE/OOSE approach addresses these issues. The integrated process
is shown in Figure 1. In this process, the systems engineer, executing the MBSE process,
generates the context, structure, and behavior models. These models are then given to the
software engineer executing the OOSE process (we selected the Rational Unified Process [5]).
The software engineer generates the object-oriented allocating objects to components.
Traceability results from the mapping of object-oriented collaboration/sequence diagrams back
to the originating behavior models and/or a table mapping functions to objects. In the
following sections, we demonstrate the process by developing the MES_To_Affiliate Control
System for a simplified TV satellite distribution system.
 Figure 1. The integrated MBSE/OOSE Process

Step 1: Requirements Analysis

The TV network programming distribution system is shown in Figure 2. The Master Earth
Station (MES) sends programming to a designated group of affiliates. To receive the
programming, the affiliate must have the name of the designated group in its Site Table. The
MES_To_Affiliate Control System (MES_To_ACS) in the MES is responsible for ensuring that an
affiliate’s Site Table has the names of all of the groups that it is a member of. Our goal is the
design of the MES_To_ACS. The context diagram (figure 3) shows that the MES_To_ACS
interfaces with the Scheduler and the MES Equipment, which are part of the MES (figure 4
structure diagram). The MES_To_ACS consists of 4 subsystems, the Scheduler Interface, the
computer hardware, the computer software, and the MES equipment interface. The computer
hardware allows for a maximum of two boards CPU boards.

Figure 2. Satellite TV Network Distribution System

 Figure 3. Context diagram for the MES_To_ACS

Figure 4. Structure Diagram

Step 2: Functional Analysis

The behavior model is shown in figure 5. The Scheduler sends the affiliate table to the
MES_To_ACS. The MES_To_ACS then converts the Scheduler format to the command string
format required by the affiliate and sends the string via the MES Equipment. To ensure that the
table was received, the affiliate must be queried and the resulting response compared with the
table that was sent. If the desired and actual tables do not match, then a failure notification is
sent to the Scheduler. If there is no response or non-matching responses after 3 tries, the
Scheduler is notified of a failure.

At this point, the traditional systems engineering process would be to partition the functions
between the two computers, including further subdividing the functionality, creating more
behavior diagrams as needed. However, in the integrated process, we move to object-oriented
analysis and design.
 Figure 5. Behavior diagram for updating a site table

Step 3: Object-Oriented Analysis and Design

Using the context, structure, and behavior diagrams the software engineer(s) develop the
object-oriented architecture. Various architecture design methods and patterns are detailed in
[5][8][9][10][11]. One important addition from MBSE is the capture of scenarios as behavior
diagrams as opposed to use cases (see Appendix for the use case equivalent of Figure 5).

In this example, the OOSE process led to the “pipes and filters” architecture [11]. The pipes and
filters pattern:
“…provides a structure for systems that process a stream of data. Each processing
step is encapsulated in a filter component. Data is passed through pipes between
adjacent filters.”
Figure 6 shows the class diagrams. Figure 7 shows how the filters A-G perform the nominal
sequence involved in updating a site table. Normal OOSE practice suggests the development of
deployment diagrams that allocate the objects to the computers. In integrated MBSE/OOSE,
both systems engineering and software engineering perform this function by working together
on Step 4: Architecture Synthesis.
 Figure 6. Pipe and Filter class diagrams

Figure 7. Sequence diagram: update site table

Step 4: Architecture Synthesis

As discussed earlier, in OOSE, it is objects, not functions, that are distributed among
components. The allocation of objects can have major effects on both the object architecture
and the system design. The issue of how to allocate these objects to processes/processors is a
complex one that involves trading off minimization of communication and task switching
overhead against maximizing processor utilization. Handling failure scenarios may involve
changing how the operator works with the system. Any of these issues may, in turn, effect the
design of the software. Allocation of objects to processes/processors will therefore necessarily
involve a large amount of interaction between the systems and software engineers. The
interface between these engineers consists of the information discussed plus the addition of a
process/processor allocation diagram.

In this example, the process yielded the result in figure 8b. In the actual project the allocation
of objects to hardware was based on the following factors:
1. the real-time operating system on Computer #2 did not support SQL database access,
which some of filters needed, and
2. the development environment on Computer #1 was superior to that of #2, so
minimizing the number of filters on #2 decreased the code-test-debug cycle

Figure 8. Object-Oriented Architecture (a) before allocation, (b) after allocation

The object architecture must be mapped back to the functional requirements. The simplest
approach is creating a function-to-object mapping table as in Table 1, by comparing the
behavior diagrams (figure 5) with their object-based sequence/collaboration diagrams (figure
6). The simplest mapping is 1:1, one function is implemented by one object. The more general
(and usual) case is that several objects may be needed to implement a function or vice-versa.

Table 1. Object to Function Mapping

A B C D E F G
Generate Update Site Table X
Send Update Site Table X X
Generate SMT Request X
Send SMT Request X X
SMT Response Detect/Timeout X X X X X
Check Table X
Send Fail Message X
CONCLUSION
The model-based systems engineering process interfaces directly with the object-oriented
software engineering process. The primary artifacts of the requirements and functional analysis
phases of MBSE consist of context, behavior, and structural models. This information is
required for the object-oriented software engineering design effort. The traditional OOSE
model assumes that these items are provided in the form of documents. Since the MBSE
approach emphasizes the use of executable behavior models and consistency-checked static
models, the software engineer has much more information at their disposal. Final development
of the software architecture consists of iterating between the systems and software
engineering processes to develop a process/processor/object architecture that meets the
system requirements. A simple table provides traceability from software objects to the
required functions.
REFERENCES

[1a] Object-Oriented Systems Engineering Method, https://www.incose.org/incose-member-

resources/working-groups/transformational/object-oriented-se-method, last accessed 8/23/21.

[1b] “Sample Application of OOSEM to Real Time Application”,

https://www.omg.org/news/meetings/workshops/RT-2007/00-T6A_Friedenthal_etal.pdf, last
accessed 8/25/21.

[2] Oliver, David, Tim Kelliher, and Jim Kerrigan, Engineering Complex Systems with Objects and
Models, McGraw-Hill, 1997.

[3] “Introduction to Model-Based Systems Engineering (MBSE) and SysML”,

https://www.incose.org/docs/default-source/delaware-valley/mbse-overview-incose-30-july-
2015.pdf, last retrieved 8/23/21.

[4] Estefan, Jeff A., “Survey of Model-Based Systems Engineering Methodologies”,

https://www.omgsysml.org/MBSE_Methodology_Survey_RevB.pdf, last accessed 8/29/21.

[5] “Rational Unified Process Overview”,

https://sceweb.uhcl.edu/helm/RationalUnifiedProcess/, last accessed 8/29/21

[6] “Feature-driven development”, https://en.wikipedia.org/wiki/Feature-driven_development,

last accessed 8/29/21.

[7] “Extreme Programming: Values, Principles, Practices”,

https://www.altexsoft.com/blog/business/extreme-programming-values-principles-and-
practices/, last accessed 8/29.21.

[8] Booch, Grady, Object-Oriented Analysis and Design, 3rd Edition, Addison-Wesley, Boston,
2007.

[9] Unified Modeling Language, https://www.omg.org/spec/UML/, last accessed 8/29/21.

[10] Martin, Robert C., Designing Object-Oriented C++ Applications Using the Booch Method,
Prentice-Hall, New Jersey, 1995.

[11] Bushmann, Frank, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal, A
System of Patterns, Wiley and Sons, 1996.
APPENDIX: Use Case Example

Use Case Update the group table at an affiliate site

Actors Scheduler, Master Earth Station equipment, MES to Affiliate Control System
Preconditions System is initialized and operating
Description The Scheduler sends the group table to be loaded by the site to the system.
The system packages the table into the update site table command and
sends to the site via the Master Earth Station equipment. The system then
sends a query to the site for the actual group table. If the actual group
table matches the commanded table, an “OK” message is sent to the
Scheduler.
Exceptions If no response is received after a timeout period, then the table query is
sent to the site again. If the site doesn’t respond after 3 retries, a “Fail”
message is sent to the Scheduler. If a response is received, but the actual
table is not the commanded one, then a “Fail” message is sent to the
Scheduler.