Chapter 5: System Modeling

---

Executive Summary

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. Chapter 5 explores how we use graphical representations—primarily the Unified Modeling Language (UML)—to design, communicate, and analyze software before and during implementation. This chapter breaks down system modeling into four distinct perspectives (Context, Interaction, Structure, and Behavior) and introduces Model-Driven Engineering (MDE), a paradigm where models, rather than raw code, are the primary outputs of the development process.

---

1. The Foundations of System Modeling

What is a Model?

At its core, a model is an abstraction. It leaves out details to make the system easier to understand. You cannot build a complex system by jumping straight into code; you need blueprints. Models are used during requirements engineering to clarify what the existing system does and during design to explain the proposed system.

The Four System Perspectives

When you look at a building, you can look at its plumbing, its electrical wiring, or its floor plan. Software is identical. We model systems from four perspectives:

1. An External Perspective (Context): Where does the system operate? What is in its environment?
2. An Interaction Perspective: How does the system interact with its environment or how do its internal components interact with each other?
3. A Structural Perspective: How is the data and the architecture organized?
4. A Behavioral Perspective: How does the system react to specific events or data inputs dynamically?

The Role of UML

The Unified Modeling Language (UML) is the standard visual language for software design. While UML has over a dozen diagram types, Chapter 5 focuses on the five most critical:

• Activity Diagrams: Show the activities or flow of data/control.
• Use Case Diagrams: Show interactions between actors and the system.
• Sequence Diagrams: Show interactions between actors and the system (or between system objects) over time.
• Class Diagrams: Show the object classes and their relationships.
• State Diagrams: Show how the system reacts to internal and external events.

---

2. Context Models: Defining the Boundaries

Before you can build a system, you must define exactly what you are building. Context models illustrate the operational context of a system—they show what lies outside the system boundaries.

• System Boundaries: Defining the boundary is often a political and social decision as much as a technical one. It determines what features are built into your system and what features are delegated to external systems.
• Context Diagrams: Simple block diagrams that show the system at the center and the external entities (other systems, databases, hardware) it communicates with.
• Process Models: Because simple block diagrams don't show how the systems interact, we use UML Activity Diagrams to show the business processes.

Mastery Application: Imagine designing an ATM network. The Context Model would show the ATM itself as the central system, connected to the Bank's Mainframe, a Currency Database, and a Maintenance System. The boundary defines that the ATM does not verify account balances itself; it delegates that to the Mainframe.

---

3. Interaction Models: Communication and Use

Interaction models help us understand how users interact with the system (vital for user requirements) and how system components interact with each other (vital for system design).

Use Case Modeling

Originally developed for the Object-Oriented Software Engineering (OOSE) method, use cases are a high-level view of interactions.

• Actors: External entities (humans or other systems) that interact with the system. Represented as stick figures.
• Use Cases: A specific task or interaction (e.g., "Withdraw Cash", "Print Receipt"). Represented as ovals.
• Limitation: Use case diagrams are just summaries. They must be accompanied by a tabular description or structured text that explains the normal flow, alternative flows, and exceptions.

Sequence Diagrams

While use cases show what happens, Sequence Diagrams show how it happens chronologically.

• Lifelines: Vertical dashed lines representing the existence of an object over time.
• Messages: Horizontal arrows passed between objects. Solid arrows denote synchronous calls (the sender waits for a response); dashed arrows denote return messages.
• Activation Boxes: Rectangles on the lifeline showing when an object is actively processing data.

Mastery Application: In a modern web application (like a login screen), a Sequence Diagram is perfect for visualizing the flow: The User (Actor) sends credentials to the UI -> UI sends an HTTP request to the Auth Controller -> Auth Controller queries the Database. The diagram proves logically whether the controller needs to wait for the database before returning the view to the user.

---

4. Structural Models: The Architecture of Data

Structural models display the organization of a system in terms of the components that make up that system and their relationships. These are static models (they do not show time or behavior).

Class Diagrams

The workhorse of object-oriented modeling. A class diagram shows the object classes in the system and the associations between them.

• Class Box: Divided into three compartments: Class Name, Attributes (data), and Operations (methods/functions).
• Associations: Lines connecting classes, showing a relationship. Multiplicity (e.g., 1..* meaning "one to many") is placed on these lines.
• Generalization (Inheritance): Represented by an empty arrow pointing to the superclass. Used to manage complexity by abstracting common attributes into a single parent class.
• Aggregation/Composition: Represents a "has-a" relationship (e.g., a Library has Books). Represented by a diamond on the association line.

Mastery Application: Consider a Hospital Management System. A generic Employee class holds name and ID. Doctor and Nurse classes inherit from Employee. A Ward class has an aggregation relationship with Patient (a ward contains many patients, but patients exist independently of the ward). This dictates how you will write your SQL tables and Java/C# classes later.

---

5. Behavioral Models: System Dynamics

Behavioral models are dynamic. They show what happens when the system is running and responding to its environment. There are two primary stimuli a system responds to: Data and Events.

Data-Driven Modeling

Shows the sequence of actions involved in processing input data and generating an output.

• Historically done using Data Flow Diagrams (DFDs), but in UML, Activity Diagrams are used.
• They are excellent for showing end-to-end processing. For example, the flow of an e-commerce order: Receive Order -> Check Inventory -> Process Payment -> Dispatch Goods.

Event-Driven Modeling (State Machines)

Some systems don't just passively process data; they sit in a specific "state" waiting for an "event" to happen. This is crucial for real-time systems.

• State Diagrams: Show system states as rounded rectangles and events as labeled arrows transitioning between states.
• Guards: Conditions that must be met for a transition to occur (e.g., [balance > 0]).

Mastery Application: A Microwave Oven is the classic state machine. Its states are Off, Waiting for Input, Running, and Door Open. If the microwave is in the Running state and the event Door Opened occurs, the system must immediately transition to a Paused state and cut the power. A data-driven model cannot capture this instantaneous safety interrupt; a state diagram captures it perfectly.

---

6. Model-Driven Engineering (MDE)

Chapter 5 concludes by looking toward the future/alternative paradigms of software engineering. Model-Driven Engineering (MDE) is an approach where models are the focal point of the development process, not the code. In a pure MDE environment, executable code is automatically generated from the models.

Model-Driven Architecture (MDA)

A specific subset of MDE proposed by the OMG (Object Management Group). It uses a three-tier abstraction:

1. Computation Independent Model (CIM): Models the domain and business requirements (no software details).
2. Platform Independent Model (PIM): A software model that does not reference any specific technology (e.g., a standard UML class diagram).
3. Platform Specific Model (PSM): The PIM is transformed into a model tailored to a specific execution environment (e.g., a Java EE or .NET model).

Pros and Cons of MDE

• Advantages: Allows systems to be considered at higher levels of abstraction. It is cheaper to adapt a system to a new platform (just generate a new PSM from the existing PIM).
• Disadvantages: Creating complete, unambiguous models is incredibly difficult. Often, the generated code is bloated or inefficient. Because of this, MDE has seen limited adoption in general-purpose software, though it is highly successful in embedded systems engineering.