System Modeling
convince stake holders that the design you have come up with will be viable for the use case & users
graph TD Stakeholders --> Time Stakeholders --> Money Design --> Money
different types of models will explain different aspects of the new system
- depends on scale & scope
- “explain the system”
UML diagram types
- Activity diagrams: the activities involved in a process or in data processing
- Use case diagrams: the interactions between a system and its environment
- Sequence diagrams: the interactions between actors and the system and between system components
- Class diagrams: the object classes in the system and the associations between these classes
- State diagrams: how the system reacts to internal and external events
Context models
in what context will the system/subsystem be used in?
- what is external to the system
- some systems will be a core part of a larger system
example: Mentcare system
- illustrates operational context and system boundaries
- shows external systems that interact (e.g., patient records system, other health authority databases)
graph TD Mentcare[ Mentcare System ] Receptionist --> Mentcare Mentcare --> PRS[ Patient Records System ] Mentcare --> HA[ Health Authority DB ]
Interaction models
- user requirement for interfacing with the new system
- use case diagrams and sequence diagrams
example: Transfer data use case
| Element | Description |
|---|---|
| Actors | medical receptionist, patient records system (PRS) |
| Description | receptionist transfers data from Mentcare to PRS |
| Data | patient info (address, phone, treatment summary) |
| Stimulus | user command issued by receptionist |
| Response | confirmation PRS updated |
| Comments | receptionist must have security permissions |
sequenceDiagram actor Receptionist participant Mentcare participant PRS as Patient Records System Receptionist->>Mentcare: Transfer data command Mentcare->>PRS: Send patient info PRS-->>Mentcare: Acknowledge update Mentcare-->>Receptionist: Confirm success
Structural models
define objects and relationships between those objects
- effectively class diagrams
- similar to CRC (class resource card)
- define memory objects & (in some cases) behaviour
- hierarchy → inheritance → sub objects
- limit the amount of info duplication (limit redundancy)
everything above essentially improves maintainability
example: MHC-PMS classes
classDiagram class Patient { +id +name +address } class Consultation { +date +notes } class Doctor { +id +specialty } Patient --> Consultation Doctor --> Consultation
- generalization: shared attributes can be moved to a superclass
- aggregation: classes can be composed of other classes
Behavioural models
behaviour is triggered by the arrival of some data (cognitive complexity theory)
- common in data processing (databases)
- linear layout (start → end)
example: Microwave oven states
| State | Description |
|---|---|
| Waiting | idle, display shows time |
| Half power | set to 300W |
| Full power | set to 600W |
| Set time | user sets cooking time |
| Enabled | ready to cook |
| Operation | cooking, light on, timer countdown |
stateDiagram-v2 [*] --> Waiting Waiting --> HalfPower: press half power Waiting --> FullPower: press full power HalfPower --> SetTime: set timer FullPower --> SetTime: set timer SetTime --> Enabled: door closed Enabled --> Operation: press start Operation --> Waiting: cooking complete