Chapter 5 – System Modeling Software Engineering • Quick Study Guide

Chapter 5

System Modeling
Quick Study Guide • Midterm Edition

Software Engineering

What Is This Chapter About?

System modelling is about creating abstract pictures (models) of a software system — each picture showing a
different viewpoint. Think of it like blueprints for a building: the electrical plan, the plumbing plan, and the
structural plan all describe the SAME building from different angles. UML is the standard language for these
blueprints in software.

LECTURE 1 · Context, Use Cases, Sequences & Structural

Models

1. System Modeling Overview

System modelling = developing abstract graphical models of a system, each presenting a different
perspective. Today this almost always means UML diagrams.

Two Types of Models:

• Existing system models — used in requirements engineering to clarify current behaviour and identify
weaknesses
• New system models — used to explain proposed requirements and discuss design; can even generate
code automatically (MDE)

2. The 4 System Perspectives

Perspective What It Models Example

External Context / environment of the system. What lies Context diagram showing MHC-PMS
outside system boundaries? and other hospital systems around it.

Interaction Interactions between the system & its Use case & sequence diagrams for
environment, or between internal components. 'Transfer Data'.

Structural Organisation and architecture of the system or Class diagrams for patient/prescription
data. objects.

Page 1 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

Behavioral Dynamic behaviour — how the system State diagrams for a microwave oven.
responds to events.

3. UML Diagram Types Covered in This Chapter

Diagram Type Shows Perspective

Activity Diagram Activities in a process or data flow Behavioral / Process

Use Case Diagram Interactions between system and environment Interaction / External
(actors)

Sequence Diagram Ordered message exchanges between actors Interaction

and objects

Class Diagram Object classes and associations Structural

State Diagram System states and transitions triggered by events Behavioral

4. Context Models
Context models show what lies OUTSIDE the system — i.e. what other systems and processes surround it.
They establish the system boundary.

Key Points about Context Models

• Show other systems in the environment, NOT how the system is used
• System boundaries are a POLITICAL judgment (who owns which data/function?)
• Boundary position profoundly affects system requirements
• Architectural models show the system and its relationships
• Process models (UML Activity Diagrams) reveal how the system fits into broader business
processes

■ DIAGRAM — MHC-PMS Context Diagram (Slide 10 — Fig 5.1)

Purpose: Shows what external systems the Mental Health Care Patient Management System
(MHC-PMS) connects to — establishing its boundary. Key components: • Central box: MHC-PMS
(the system being built) • External boxes: Prescription System, Patient Records System,
Appointments System, Pharmacy System, etc. • Arrows/lines show data flow / relationships
between systems What it does NOT show: How doctors actually use the system day-to-day.

■ DIAGRAM — Process Model of Involuntary Detention (Slide 12 — Fig 5.2)

Purpose: Shows the broader BUSINESS PROCESS in which the MHC-PMS is used (specifically,
the legal/medical process for detaining a patient involuntarily). Diagram type: UML Activity
Diagram. Key components: • Activities (rounded rectangles): e.g. 'Assess patient', 'Obtain warrant'
• Decision diamonds: branching points • Swimlanes: show which role (doctor, judge, police)
performs each activity • Arrows: flow of control between activities

Page 2 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

■ REAL-WORLD EXAMPLE — Context Model — Food Delivery App

The FoodApp context diagram shows: FoodApp in the centre, connected to Payment Gateway,
Restaurant POS System, Delivery Driver App, and Customer Notification Service. The boundary
shows that FoodApp owns order management but NOT payment processing or driver GPS —
those are external systems.

5. Interaction Models — Use Cases

Interaction models capture how users (or other systems) interact with the system being built. Two main tools:
Use Case Diagrams and Sequence Diagrams.

Use Cases:
• Originally developed to support requirements elicitation; now part of UML
• Each use case = a discrete task involving external interaction with the system
• Actors may be people OR other systems
• Represented as a diagram (overview) AND a detailed textual table

■ DIAGRAM — Transfer-Data Use Case Diagram (Slide 15 — Fig 5.3)

Purpose: Shows the 'Transfer Data' interaction between external actors and MHC-PMS. Key
components: • Oval (use case): 'Transfer Data' • Stick figures (actors): 'Medical Receptionist' and
'Patient Records System (PRS)' • Lines connecting actors to the use case (participation
relationships) • System boundary rectangle surrounding all use cases The diagram gives a quick
overview; the detailed table (Fig 5.4) fills in actors, description, data, stimulus, response, and
comments.

■ DIAGRAM — Use Cases for Medical Receptionist (Slide 17 — Fig 5.5)

Purpose: Shows ALL use cases involving the Medical Receptionist role in one diagram. Key
components: • One actor (Medical Receptionist stick figure) • Multiple use case ovals (e.g.
Transfer Data, Make Appointment, View Patient Record) • Lines from actor to each use case they
participate in Useful for: Identifying the full scope of a role's interactions with the system.

■ REAL-WORLD EXAMPLE — Use Case — ATM

Actor: Bank Customer. Use cases connected: 'Withdraw Cash', 'Check Balance', 'Deposit
Cheque', 'Change PIN'. Actor: Bank System (external). Use case: 'Verify Account'. The diagram
instantly shows the customer's scope of interaction.

6. Sequence Diagrams
Sequence diagrams model the ordered messages between actors and objects within a system during a
specific use case.

Page 3 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

Key Components of a Sequence Diagram

• Actors and objects listed along the TOP (each with a vertical dotted 'lifeline')
• Horizontal arrows = messages sent between actors/objects (labelled with the operation name)
• Time flows DOWNWARDS along the lifelines
• Activation boxes (rectangles on lifelines) show when an object is active/processing
• Return arrows (often dashed) show a response being returned

■ DIAGRAM — Sequence Diagram — View Patient Information (Slide 19 — Fig 5.6)

Purpose: Shows the exact message sequence when a doctor views patient info. Actors/Objects:
Doctor (actor), UI System, Patient Database Sequence of messages: 1. Doctor → UI:
requestPatientInfo(patientID) 2. UI → Database: fetchRecord(patientID) 3. Database → UI:
returnRecord(data) 4. UI → Doctor: displayPatientInfo(data)

■ DIAGRAM — Sequence Diagram — Transfer Data (Slide 20 — Fig 5.7)

Purpose: Shows message sequence when a receptionist transfers patient data to PRS.
Actors/Objects: Medical Receptionist, MHC-PMS UI, MHC-PMS Logic, Patient Records System
Key messages: 1. Receptionist → UI: selectTransfer() 2. UI → Logic: prepareData() 3. Logic →
PRS: sendData(patientRecord) 4. PRS → Logic: confirmUpdate() 5. Logic → UI:
showConfirmation() 6. UI → Receptionist: 'Update confirmed'

■ REAL-WORLD EXAMPLE — Sequence Diagram — Online Login

Objects: User, Browser, Auth Server, User Database 1. User → Browser: enterCredentials(email,
pwd) 2. Browser → Auth Server: login(email, pwd) 3. Auth Server → Database:
validateUser(email) 4. Database → Auth Server: userRecord 5. Auth Server checks password
hash → Browser: authToken 6. Browser → User: redirect to dashboard

7. Structural Models — Class Diagrams

Structural models show the ORGANISATION of a system — the building blocks and how they relate. Class
diagrams are the primary tool.

Class Diagram Concepts

• Object Class: A general definition of a type of system object — its attributes and operations
• Association: A link between classes indicating a relationship
• Attribute: A data property of a class (e.g. patientName, dateOfBirth)
• Operation: A behaviour/function of a class (e.g. getRecord(), prescribeMedication())
• Multiplicity: How many instances are involved in a relationship (e.g. 1..*, 0..1)

■ DIAGRAM — UML Classes and Association (Slide 23 — Fig 5.8)

Purpose: Shows the basic notation for a UML class and association. Class box has 3 sections: •
Top: Class name (e.g. Patient) • Middle: Attributes (e.g. patientID, name, address) • Bottom:
Operations (e.g. addRecord(), deleteRecord()) Association: line between two classes with a label
(e.g. 'is treated by') and multiplicity notation at each end (e.g. 1 patient — * consultations).

Page 4 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

■ DIAGRAM — Classes and Associations in MHC-PMS (Slide 24 — Fig 5.9)

Purpose: Shows the full set of classes in the MHC-PMS and how they relate. Key classes: Patient,
Consultation, Doctor, Prescription, Treatment Key associations: • Patient 'has' Consultations (1 to
many) • Consultation 'involves' Doctor (many to 1) • Consultation 'may result in' Prescription (0 or
1) This diagram gives developers the complete data/object model for the system.

■ DIAGRAM — The Consultation Class (Slide 25 — Fig 5.10)

Purpose: Shows a detailed single class with full attributes and operations. Class: Consultation
Attributes: consultationDate, consultationNotes, consultationSummary Operations: addNotes(),
getSummary(), linkPrescription() This level of detail is used when designing the actual
implementation.

■ REAL-WORLD EXAMPLE — Class Diagram — Library System

Classes: Book (title, ISBN, copies), Member (name, memberID, email), Loan (dueDate,
returnDate) Associations: Member 'borrows' Book through Loan (1 member → many Loans, 1
Loan → 1 Book). A quick class diagram shows the developer exactly what database tables to
create.

■ JARGON DECODER
Abstract model: A simplified representation that hides unnecessary detail to focus on what
matters.
UML (Unified Modeling Language): The international standard graphical language for describing
software systems.
Actor: An external entity (person or system) that interacts with the system being modelled.
Lifeline: The vertical dashed line in a sequence diagram representing an object's existence over
time.
Multiplicity: A constraint on a relationship specifying how many objects can participate (e.g. 1..*,
0..1).
System boundary: The dividing line between what is inside the system being built and what is
outside it.

Page 5 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

LECTURE 2 · Generalization, Behavioral Models &

Model-Driven Engineering

8. Generalization in Class Models

Generalization = placing entities into more general classes and inheriting shared characteristics. In OO
languages, this is implemented as class inheritance.

Generalization Rules
• Higher-level (superclass) attributes and operations are inherited by lower-level (subclass)
classes
• Subclasses add MORE SPECIFIC attributes and operations
• Benefit: Change management — modify the superclass once, all subclasses update
• In UML: shown by a hollow triangle arrowhead pointing FROM subclass TO superclass

■ DIAGRAM — Generalization Hierarchy (Slides 30-31 — Figs 5.11 & 5.12)

Purpose: Shows inheritance relationships among Patient types in MHC-PMS. Fig 5.11 — Basic
hierarchy: • Superclass: Patient (name, address, dateOfBirth) • Subclasses: InPatient
(wardNumber, admissionDate) and OutPatient (appointmentDate) • Hollow triangle arrow from
each subclass pointing up to Patient Fig 5.12 — Added detail: • Shows additional attributes
specific to each subclass • InPatient inherits all Patient attributes AND adds wardNumber,
admissionDate • OutPatient inherits all Patient attributes AND adds appointmentDate

■ REAL-WORLD EXAMPLE — Generalization — Vehicle Hierarchy

Superclass: Vehicle (speed, fuelType, registration) Subclasses: Car (numDoors, trunkSize),
Motorcycle (hasSidecar), Truck (payloadCapacity) All three inherit speed, fuelType, registration
automatically. Adding a 'colour' attribute to Vehicle instantly gives colour to ALL three subclasses.

9. Object Class Aggregation Models

Aggregation models show how classes that are collections are composed of other classes. Similar to the
'part-of' relationship in data models.

■ DIAGRAM — The Aggregation Association (Slide 33 — Fig 5.13)

Purpose: Shows that one class is made up of (aggregates) other classes. Key components: •
Diamond shape at the 'whole' end of the association (open diamond = aggregation, filled diamond
= composition) • Example: Patient RECORD aggregates Consultations, Prescriptions,
PersonalDetails • Multiplicity shows how many parts make up the whole Aggregation vs
Composition: • Aggregation: parts can exist independently (a doctor can exist without a patient) •
Composition: parts CANNOT exist without the whole (a room cannot exist without a building)

Page 6 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

■ REAL-WORLD EXAMPLE — Aggregation — Shopping Cart

ShoppingCart (whole) aggregates CartItem (parts). A CartItem references a Product. The cart
'has' items. If you delete the cart, the items go with it (composition). But the Product continues to
exist in the catalogue (aggregation).

10. Behavioral Models

Behavioral models show how a system behaves dynamically — when it's actually executing. Two types of
stimulus trigger behaviour:
• Data stimuli — data arrives that needs processing (data-driven)
• Event stimuli — something happens that triggers system processing (event-driven)

Data-Driven Modeling (Activity Diagrams)

Business systems are primarily data-processing systems. Activity diagrams show the sequence of actions
involved in processing data end-to-end.

■ DIAGRAM — Insulin Pump Activity Model (Slide 36 — Fig 5.14)

Diagram type: UML Activity Diagram. Purpose: Shows the full data-processing flow of an insulin
pump controller. Key activities (nodes): • ReadSugar — reads blood glucose from sensor •
CompareWithSafeRange — decision: sugar too high / in range / too low • CalculateDose —
computes insulin dose if high • InjectInsulin — activates the pump • Wait — pauses until next
reading Decision diamonds show branches (e.g. if in safe range → wait, no injection).

■ DIAGRAM — Order Processing Sequence (Slide 37 — Fig 5.15)

Diagram type: UML Sequence Diagram (used as a data-flow model). Purpose: Shows end-to-end
data flow through an order processing system. Key objects: Customer, OrderSystem, Inventory,
Payment, Dispatch Key messages: placeOrder → checkStock → processPayment →
dispatchOrder → confirmDelivery Useful for seeing where data transformation happens and
identifying bottlenecks.

Event-Driven Modeling (State Diagrams)

Real-time systems respond to events. State machine models show how a system moves between a finite
number of STATES in response to events (stimuli).

State Machine / State Diagram Components

• State: A condition the system can be in (shown as a rounded rectangle) — e.g. 'Waiting', 'Full
Power', 'Operation'
• Event/Stimulus: Something that triggers a state change (shown as a labelled arrow)
• Transition: The arrow from one state to another, labelled with the triggering event
• Initial state: Filled black circle — starting point of the diagram
• Final state: Circle inside a circle — end point

Page 7 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

■ DIAGRAM — State Diagram — Microwave Oven (Slide 40 — Fig 5.16)

Purpose: Models all possible states of a microwave oven and how events trigger transitions.
States (7): • Waiting, Half Power, Full Power, Set Time, Disabled, Enabled, Operation Key stimuli
(events) that cause transitions: • Half power button → Waiting → Half Power • Door open → any
cooking state → Disabled • Door closed → Disabled → Enabled • Start button (when Enabled) →
Operation • Cancel → any state → Waiting Why it matters: Ensures the oven CANNOT operate
with the door open (safety).

■ DIAGRAM — Microwave Oven Operation Detail (Slide 43 — Fig 5.18)

Purpose: Zooms into the 'Operation' state to show its internal sub-states. Shows: Timer counting
down → if reaches 0 → buzzer sounds 5 sec → light on → 'Cooking Complete' displayed → return
to Waiting. This level of detail is needed for implementation of the oven controller firmware.

■ REAL-WORLD EXAMPLE — State Diagram — Traffic Light Controller

States: Red, Red-Amber, Green, Amber Events: timer_expired (causes each transition),
emergency_vehicle (jumps to Red) Transitions: Red →(timer)→ Red-Amber →(timer)→ Green
→(timer)→ Amber →(timer)→ Red The state diagram proves the lights can NEVER show Red and
Green simultaneously.

11. Model-Driven Engineering (MDE)

MDE = an approach where models are the primary outputs of development (not programs). Programs are
generated automatically from models.

Pros vs Cons:
Details

Pros • Higher level of abstraction — engineers think in domain terms • Code generation is cheaper to
retarget to new platforms

Cons • Models optimised for abstraction may not be right for implementation • Cost of developing
translators for new platforms may exceed savings • Still early-stage — limited industry adoption

Model-Driven Architecture (MDA)

MDA is the precursor to MDE. Uses a subset of UML. Creates models at different abstraction levels and
transforms them automatically.

Model Type Description

CIM (Computation Models domain abstractions. Also called domain models. Independent of any
Independent Model) computation concern.

PIM (Platform Independent Models system operation WITHOUT reference to implementation platform.
Model) Uses UML.

PSM (Platform Specific Transformation of PIM for a specific platform (e.g. Java EE, .NET). Multiple
Model) PSMs can be generated from one PIM.

Page 8 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

■ DIAGRAM — MDA Transformations (Slide 48 — Fig 5.19)

Purpose: Shows how models are transformed from abstract to concrete. Flow: CIM →
(transformation) → PIM → (transformation) → PSM → (code generation) → Executable Code
Each arrow represents an automated transformation. Key point: The PIM is platform-neutral; the
PSM adds platform-specific details.

■ DIAGRAM — Multiple Platform-Specific Models (Slide 49 — Fig 5.20)

Purpose: Shows that ONE PIM can generate MULTIPLE PSMs for different platforms. Example: A
single PIM for a booking system generates: • PSM for Java web application • PSM for mobile
(Android/iOS) • PSM for legacy COBOL mainframe This is the key economic argument for MDA:
write once, deploy anywhere.

Executable UML (xUML)

A subset of UML 2 that can be fully automatically transformed to code. Uses only 3 model types:
• Domain models — principal concerns using class diagrams (objects, attributes, associations)
• Class models — classes with attributes and operations defined in detail
• State models — a state diagram for each class describing its life cycle
Behaviour specified using OCL (Object Constraint Language) or UML's action language.

■ REAL-WORLD EXAMPLE — MDE in Practice — Banking Platform

A bank creates one PIM describing its account management system in pure UML. The MDA tool
generates: a Java EE PSM for the web portal, a Swift PSM for the iOS app, and a COBOL PSM
for the mainframe. When regulations change, they update the PIM once and regenerate all three
— in theory.

Page 9 • Good luck on your midterm!

Chapter 5 – System Modeling Software Engineering • Quick Study Guide

■ JARGON DECODER
Generalization: The OOP concept of creating a broader parent class whose attributes/operations
are inherited by more specific child classes.
Inheritance: The mechanism by which a subclass automatically receives all attributes and
operations of its superclass.
Aggregation: A 'whole-part' relationship between classes where the parts can exist independently
of the whole.
Composition: A stronger aggregation where parts CANNOT exist without the whole (lifecycle
dependency).
State machine: A computational model with a finite set of states and rules for transitioning
between them based on events.
Statechart: UML's notation for state machine models — states as nodes, events as labelled
arrows.
MDA (Model-Driven Architecture): An OMG standard for building systems by transforming
abstract models automatically down to executable code.
PIM (Platform Independent Model): A UML model describing system behaviour with no
reference to the deployment technology.
PSM (Platform Specific Model): A model derived from a PIM that adds the implementation
details for a specific platform.
OCL (Object Constraint Language): A formal language for specifying constraints and behaviour
on UML models without writing code.

■ QUICK MEMORY TRICKS

• 5 UML diagram types: A-U-S-C-S: Activity, Use Case, Sequence, Class, State
• 4 System Perspectives: E-I-S-B: External, Interaction, Structural, Behavioral
• Use Case vs Sequence: Use Case = WHO interacts (actors + ovals) | Sequence = WHAT order
(arrows + lifelines)
• Class diagram sections: Name / Attributes / Operations (top to bottom)
• Generalization arrow: Points FROM subclass TO superclass (child → parent)
• Aggregation diamond: Open = aggregation (parts survive alone) | Filled = composition (parts die
with whole)
• MDA model levels: CIM (domain) → PIM (logic) → PSM (platform) → Code
• Behavioral models: Data-driven = Activity Diagrams | Event-driven = State Diagrams

Chapter 5 Study Guide • Software Engineering • Good luck on your midterm!

Page 10 • Good luck on your midterm!