Systems Modeling

This lecture is about modeling software systems: how graphical models are used to represent a system, why several different types of models are needed to represent it fully, and how those models are produced as part of requirements engineering and then refined during design. You will look at the four perspectives from which a system can be modeled — the context of the system, the interaction between its components, the structure of the system, and its behavior — and at the main diagram types of the Unified Modeling Language (UML) that express those perspectives.

What you will build here. The lecture is a complete tour of the modeling toolkit, arranged in the same order you will use it in a real project:

1. Why model at all — what an abstract model is, how modeling fits inside requirements engineering, and the four perspectives that force you to draw several different diagrams (section 4.1).
2. How models get used — models built for discussion, models built for documentation, and models built to generate code; each use sets a different bar for completeness and correctness (section 4.2).
3. Context models — deciding where the system ends and its environment begins, and drawing the context diagram that shows the other systems it depends on (section 4.3).
4. Activity diagrams — modeling a business process as a flow of activities, with decision guards, joins, and parallel forks (section 4.4).
5. Interaction models — use case diagrams and sequence diagrams that show who talks to whom, in what order (section 4.5).
6. Structural models — class diagrams with associations, multiplicity, generalization, and aggregation (section 4.6).
7. Behavioral models — state diagrams that show how a system responds to events (section 4.7).

The running example. Throughout the lecture, one realistic system ties every diagram type together: a mental health care patient information system that manages information about patients attending mental health clinics and the treatments prescribed for them. The same system is examined with context, activity, use case, sequence, and class diagrams, so you can see how the different perspectives fit together — and how the same real-world facts look different in each picture.

The two final sections collect the exam guidance the professor gave during the lecture (section 8) and the real-world industry applications of each modeling technique (section 9).

4.1 System Modeling: What It Is and Why We Do It

4.1.1 What System Modeling Is and Where It Fits

System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. In most software projects, system modeling means representing the system using some kind of graphical notation based on the various diagram types in the Unified Modeling Language (UML). It is also possible to develop formal models — mathematical models that accompany a detailed system specification — but the graphical route is the one we focus on here. The whole point of building these representations is to understand the system from several different perspectives that no single picture could provide.

The UML is the standard notation for this work, so it is worth knowing where it comes from. The Unified Modeling Language (a set of diagram types used to model software systems) grew out of object-oriented modeling work in the 1990s, when several similar object-oriented notations were merged into one. A major revision, UML 2, was finalized in 2004, and the language is now universally accepted as the standard way to develop models of software systems. The UML defines 13 diagram types in total — but, as the lecture will show, a handful of them cover the essentials of most systems, and those are the ones examined here. Variants such as SysML adapt the notation for modeling entire systems (including hardware), which shows how flexible the core idea is.

The models are developed as part of the requirements engineering process and are then elaborated during the design process. To position system modeling, recall what was covered in the previous lecture on requirements engineering: the requirements engineering process has three important activities — requirements elicitation and analysis, requirements specification, and requirements validation. During requirements elicitation and analysis you develop a variety of descriptions of the system, which may be graphical models, descriptive models, or mathematical models. These become part of the requirements specification, also called the requirements document, both at the user-requirements level and at the system-requirements level. So a class diagram of the mental health care system sitting inside its requirements document is not a decoration — it is one of the deliverables of the elicitation and analysis activity, and it is validated together with the rest of the document.

Models are used at three points in the life of a project, and the audience differs at each point:

1. During requirements engineering — models help derive the detailed requirements for a system. This is where the models carry the analysis: what must the system do, and what must it not do?
2. During design — models describe the system to the engineers who will implement it. The design models are refinements of the requirements models: more detail, more structure, closer to code.
3. After implementation — models document the system's structure as well as its operation, so that people who did not build the system — maintainers, auditors, future teams — can understand it.

4.1.2 Models of the Existing System and the New System

You may develop models of both the existing system and the system to be developed, and the two serve different purposes.

Models of the existing system are built during requirements engineering. You create them to showcase what you understood of the requirements gathered through interviewing, ethnography, user stories, scenarios, and the other elicitation techniques. They help clarify what the existing system does, and they can be used to focus a stakeholder discussion on its strengths and weaknesses. Suppose a clinic currently records patient consultations on paper forms. A model of that existing process — an activity diagram of the paper workflow — makes it concrete where the current system is slow (forms wait in trays) or risky (records misfiled), so the discussion about the new system starts from agreed facts rather than opinions.

Models of the new system are also created during requirements engineering, but their job is different: they help explain the proposed requirements to the various stakeholders. Later, software engineers use these models to discuss design proposals among themselves and to document the system for implementation.

The two kinds of model differ along every practical dimension, so keep them distinct:

There is an important direction here: the existing-system model is a starting point for analysis, and the new-system model is a commitment about what will be built. Mixing them up — drawing the new system in the shape of the old one without noticing — is one of the most common sources of "we automated our paper forms" projects that reproduce every old inefficiency.

4.1.3 An Abstraction, Not an Alternative Representation

A key distinction to hold on to: a system model is not a complete representation of the system. It is abstract, and it deliberately leaves out details so that the system is easier to understand from a particular perspective. In other words, the model is an abstraction of the system, not an alternative representation of it.

The difference matters. An alternative representation of a system should maintain all the information about the system being represented — nothing may be lost. An abstraction, by contrast, deliberately simplifies a representation or a design and selects the most salient characteristics, dropping the rest on purpose.

A familiar example: the slide deck used to teach this topic is essentially a representation of the entire topic of systems modeling, which is also covered by the courseware and the corresponding chapters of the textbooks and other sources. The slides for a particular topic are an abstraction — they capture the key points of the chapter, not the chapter itself. But if that chapter were to be translated into another language, the translation would be an alternative representation: it must maintain all the information exactly as it is presented in the original. That is the test that separates the two ideas.

If the distinction still feels abstract, here is a second picture. A tourist map of a city is an abstraction: it shows the castle, the river, and the main squares, and it leaves out most side streets, because a visitor needs landmarks, not every alley. A photocopy of the complete street atlas is an alternative representation: every street appears, because a courier needs every route. Both are "the city" — but the map exists to make the city easy to grasp, while the atlas exists to make it fully recoverable. Where the analogy ends: a system model is not just a smaller copy of the system — it is a different kind of object (a picture in a notation) that stands in for the system for a limited purpose. You never mistake the map for the city, and you should never mistake the class diagram for the system.

4.1.4 The Four Modeling Perspectives

While performing the system modeling exercise you can develop models that represent the system from four different perspectives:

• External perspective — the context or environment of the system: the various other systems and subsystems that the system interacts with. This perspective answers "what is around the system, and what does it depend on?"
• Interaction perspective — the interactions between the system and its environment, or between the components of the system. This answers "who talks to whom, and in what order?"
• Structural perspective — the organization of the system, or the structure of the data processed by the system. This answers "what are the parts, and how are they connected?"
• Behavioral perspective — the dynamic behavior of the system and how it responds to events. This answers "what does the system do when an event occurs?"

Each perspective is expressed in the lecture by specific diagram types, which section 4.2.5 introduces in full:

All four perspectives get covered in this lecture, with the structural and behavioral ones receiving the most attention — a choice that reflects practice: most projects draw class diagrams and state diagrams as the core of their design, and use the other perspectives to check the system against its environment and its users.

Real-world connection. System models in the UML are the working language of requirements documents in regulated industries: health-care information systems, banking platforms, and embedded systems in cars and medical devices all ship with context, interaction, structural, and behavioral diagrams as part of their specifications. Regulators and auditors read these models, not the source code — the diagrams are often the only artifact that survives in human-readable form from early analysis. Where models are used to generate code (model-driven engineering, section 4.2.4), the same diagrams become the actual production input, which is why notation discipline stops being optional there.

4.2 How Graphical Models Are Used

4.2.1 Notation Can Be Used Flexibly

When you develop system models you can often be flexible in the way the graphical notation is used — you do not always have to stick rigidly to the details of the notation, and you can use it informally. The amount of detail and rigor in a graphical model depends on how you intend to use it. There are three common ways graphical models are used in practice, and each one sets a different bar for completeness and correctness. It helps to keep repeating the underlying fact from the previous section: the model is not an alternative representation of the system; it is an abstraction of the system from a particular perspective.

Think of the three uses as three different contracts, summarized here and developed in the rest of this section:

The progression is one-way in practice: a discussion model may grow into documentation, and documentation may be refined into an implementation model — but never the reverse. The more formal the use, the more care every symbol needs.

4.2.2 Use 1: Stimulating and Focusing Discussion

The first use of a graphical model is as a way to stimulate and focus discussion about an existing or proposed system, among the software engineers and the stakeholders. Models used this way may be incomplete as long as they cover the key points of the discussion, and they may use the modeling notation informally — a box-and-line diagram, or even UML models that are incomplete. This is how models are normally used in agile methods: as a means of discussion and clarification, building shared understanding between the developers and the system stakeholders, or between the developers themselves.

The value of the discussion model is not its accuracy but its sharedness. When the clinic's receptionists point at a box on a whiteboard and say "no, the appointment system does that first," the model has done its job — it has made the disagreement visible. Because the model is a means to a conversation, drawing it wrong is not a disaster; the conversation repairs it. What would defeat the purpose is a diagram so cluttered with detail that nobody can react to it, or a drawing session so slow that the discussion dies while the notation is being perfected.

4.2.3 Use 2: Documenting the System

The second use is to document an existing system — one you have observed and collected information about during requirements elicitation and analysis. Documentation models do not have to be complete either, because you may need models only for the parts of the system where discussion and clarification were required. But documentation models do have to be correct: they should use the notation properly and be an accurate description of the particular part of the system they cover. Incomplete is acceptable; inaccurate is not.

4.2.4 Use 3: Model-Driven Engineering

The third use is as a detailed system description that can be used to generate a system implementation. This is called model-driven engineering (MDE), and it is part of the model-based development process: you convert the UML models into certain skeleton code, generating code from precise UML models that are both complete and correct. Because the models now feed code generation, you have to be very careful with the symbols and the notation — there is a big difference between a simple connector (a line between two entities) and a line with an arrow between two entities, and the two carry different meanings in a UML model, as you saw with the use case diagram in the previous lecture. What is informal fun in the discussion use becomes a compile-time contract in this use.

The shift in mental model is the important part. In the first two uses, the diagram is about the system — it describes something that exists or will exist. In MDE, the diagram becomes the system: the UML models are the principal output of the development process, and the programs that run on a hardware or software platform are generated automatically from them. Proponents of MDE argue that this raises the level of abstraction in software engineering, so engineers no longer have to worry about programming-language details or the specifics of execution platforms. In practice, MDE is built on the idea of model-driven architecture (MDA), proposed by the Object Management Group (OMG): you create a high-level platform-independent model (PIM) of the system's operation, and transform it into platform-specific models (PSMs), one per target platform (for example, one PSM for a Java application server and another for an embedded controller), from which the implementation is generated.

This is why notation discipline is absolute in this use. In the UML, a plain line and an arrowed line are different facts: in a use case diagram, for example, a plain line says "this actor is involved in this use case," while arrowheads would claim a one-way direction of message flow. A generator has no judgment — it will faithfully produce whatever the symbols say, including the wrong thing. When the model is the contract, every symbol is a compiler directive.

4.2.5 The UML Diagrams Covered in This Lecture

A handful of UML diagram types are enough to cover the four perspectives from section 4.1.4, and these are the diagrams examined in this lecture:

• Activity diagrams — show the activities involved in a process or in data processing: from the input to the output of a process, with all the transformations in between.
• Use case diagrams — show the interaction between a system and the entities in its environment, or the other systems in its environment (these were introduced in the previous lecture).
• Sequence diagrams — show the interactions between the actors and the system, and also between the system components.
• Class diagrams — show the object classes in the system and the associations between these classes.
• State diagrams — show how the system reacts to internal and external events.
• Context diagrams — show the system within the context of the other systems in its environment.

The lecture proceeds through these in the same order: context models first, then interaction models, then structural models, then behavioral models.

Real-world connection. Discussion models are the daily currency of agile teams — whiteboard sketches, index cards, and informal box-and-line diagrams that build shared understanding without ceremony. Documentation models are what keep regulated systems maintainable: avionics and medical-device projects are required to keep system documents that accurately describe the implemented system, even when they describe only parts of it. Model-driven engineering is used where code volume is enormous or platforms change quickly — for example, in the automotive industry, where platform-specific code for different car models is generated from shared platform-independent models.

4.3 Context Models

4.3.1 Deciding the System Boundary

At an early stage in the requirements specification of a system you should decide on the system boundaries: what will be part of the system to be developed and what will not, what will be done manually and what will be done by other systems. This involves working with the system stakeholders to decide what functionality should be included in the system and what processing and operation should be carried out in the system's operational environment. You may decide, for example, that automated support for some business process should be implemented in the software being developed, but that other processes should stay manual or be supported by different systems.

During this process you should also look for possible overlaps in functionality with existing systems and decide where new functionality should be implemented. These decisions should be made early in the process, because they limit the system costs and the time needed for understanding the system requirements and design.

Why "early"? Because the boundary is the single most expensive decision in the project. If the boundary is drawn too small, the system misses functionality the stakeholders need, and the project must later integrate other systems — or worse, extend the boundary mid-design, when the requirements and architecture have already been organized around the smaller scope. If the boundary is drawn too large, the system must own functionality that already exists elsewhere, duplicating it and doubling maintenance. The boundary decision is also what bounds the requirements understanding: the smaller the system, the less of the organization's operation you must analyze and specify.

In some cases the boundary between the system and its environment is relatively clear. If you are building a banking system that automates the customer-facing operations, for example, then certain backend operations are simply not part of the current system. And when an automated system is replacing an existing manual — or even computer — system, the environment of the new system is usually the same as the environment of the existing system. The new system steps into the shoes of the old one: the same banks, the same reporting agencies, the same customers — only the automation inside the boundary changes.

In other cases there could be various changes, and you have to decide what constitutes the boundary between the system and its environment, especially when you are developing a new system during the requirements engineering process. A completely new system, unlike a replacement, has no existing environment to inherit — every connection to another system is a decision, not a fact.

4.3.2 The Mental Health Care System Example

Consider the running example used throughout this lecture: a mental health care patient information system, intended to manage information about patients attending mental health clinics and the treatments that have been prescribed for them. In developing the specification for this system you have to decide whether the system should focus exclusively on collecting information about consultations, using other systems to collect personal information about patients — or whether it should collect personal patient information by itself.

There is a real trade-off here. The advantage of relying on other systems is that you avoid duplicating data: the patient's personal details live in one place, maintained by one owner. The major disadvantage is that other systems may make access to information slower, and if those systems are not available, it may be difficult or even impossible to use the system you are designing.

Let the trade-off breathe, because it is the template for almost every boundary decision. On one side: no duplication. If the patient's name, address, and phone number live only in the general patient record system, then they are maintained once, by the team that owns that system, and every other system reads them from there. The mental health care system never has to worry about stale or conflicting personal data. On the other side: dependency. Every request for patient information now involves a call to another system — slower than a local lookup, and if the other system is down, the mental health care system cannot do its own core work. Notice that the trade-off is not about features; it is about where the truth lives and who depends on whom.

4.3.3 Boundaries Are a Judgment, Not an Objective Fact

Here is a point worth sitting with: the definition of a system boundary is not an objective, value-free judgment. Various social and organizational concerns influence where the boundary is placed, and the choice carries social and organizational consequences. It can even be a political judgment: there may be pressures to develop boundaries that increase or decrease the influence — or even the workload — of different people in different parts of the organization. When you draw the boundary, someone's job changes; expect that to be a negotiation, not a technical computation.

This is not cynicism; it is a warning about where boundary pressures actually come from. A boundary may be deliberately positioned so that the complete analysis process can be carried out on one site (keeping control in one place); it may be chosen so that a particularly difficult manager need not be consulted (excluding a stakeholder's scope of work); and it may even be positioned so that the system cost is increased and the development division must then expand to design and implement it. All of these are real behaviors observed in organizations — the boundary is a decision about work and power, and the people whose work or power it affects will push back.

4.3.4 Context Diagrams

Once you have made some decision on the boundaries of the system, part of the analysis activities is the definition of the context and of the dependencies the system has on the other systems and entities in its environment. The first step of this activity is normally a simple context diagram — a box-and-line diagram. In the mental health care example, the context diagram shows the mental health care system interacting with a set of other systems: the patient record system, the admission system, the prescription system, the appointment system, the health care statistics system, and the management reporting system.

The drawing itself is simple: a box for the system being developed, a box for each system in its environment, and lines between them. The UML shows each system box with a stereotype — the kind of entity written between chevrons, for example «system» — so that a reader can tell at a glance that these are systems rather than, say, classes or components. In the mental health care context diagram, the mental health care system is connected to an appointments system and a more general patient record system with which it shares data, to systems for management reporting and hospital admissions, to a statistics system that collects information for research, and to a prescription system used to generate prescriptions for patients' medication.

Context models normally show that the environment includes several other automated systems, but they do not show the type of relationships between the system being specified and the systems in its environment. Those relationships matter, and they come in many forms. External systems might produce data for the system, take data from the system and consume it, or share data with the system. They might be connected directly, connected through a network, or not connected at all — functioning independently and transferring information as and when required. And these systems may be located together, or they may be geographically distributed, in different buildings or different places. All of these relations can affect the requirements and design of the system being designed, so the context of the system must be taken into account.

To make the "what the context diagram does not say" concrete, consider the relationship inventory for the mental health care system:

Every row of this inventory is a requirements question in disguise. If the statistics system only receives a nightly file, that is a batch interface; if it must reflect current treatments, that is a real-time interface. The context diagram opens the conversation; the relationship inventory is what the conversation must cover.

4.3.5 Business Process Models

A simple context model is often complemented by business process models — process models that show the end-to-end flow of the various activities in the system. A business process model describes both the manual and the automated processes in which a particular software system may be used, so it extends the static snapshot of the context diagram into a picture of how work actually moves.

The context diagram answers "which systems are involved?"; the business process model answers "what actually happens, step by step, and where does the software fit into the human process?" The involuntary detention process of section 4.4 is exactly such a model: it shows the manual decision-making (assessing danger), the automated steps (recording the detention, updating registers), and the handoffs between people and systems — all things a context diagram cannot show because it has no time and no sequence. In UML, activity diagrams are the standard notation for business process models, which is why the two sections sit together: the context model names the players, and the activity diagram choreographs the play.

Real-world connection. Boundary decisions and context diagrams are where enterprise integration is born. In hospital systems, national health IT programs, and bank platforms, the context diagram is effectively the map of which legacy systems must be interfaced — and the boundary decision determines whether a new system becomes an integrated hub or an isolated island. The iLearn-style configurable boundary also appears in commercial enterprise software, which ships with configuration options that effectively let each customer draw their own system boundary at deployment time.

4.4 Activity Diagrams

4.4.1 What Activity Diagrams Show

An activity diagram shows the activities in a process and the flow of control from one activity to another — the specific sub-processes that must be carried out and the order in which they happen. It captures the path from the input of a process to its output, including every transformation in between. In the mental health care system, the example used here is an activity diagram for one particular scenario, built for a business process called involuntary detention.

The scenario works like this. A patient affected by a mental health issue who is considered harmful to others — or to himself — may be detained in a hospital so that treatment can be administered, or even taken to the police station to be taken into custody, depending on the condition of his mental health. Detention against the patient's will is a serious step, so the decision to detain a patient must be reviewed: people cannot be held indefinitely in custody or in a hospital without sufficient reasons. One of the critical requirements of the mental health care system is to ensure that such safeguards are implemented and that the rights of the patients are respected. The activity diagram is how the system expresses that requirement: the diagram itself forces the detention process to pass through the review steps and to notify the parties that protect the patient's rights.

4.4.2 The Notation of an Activity Diagram

The notation of an activity diagram, as used in this example:

• The start of the process is indicated by a solid circle — a filled circle.
• The end is indicated by a filled circle inside another circle.
• Rectangles with rounded corners represent activities: the specific sub-processes that must be carried out.
• Systems used to support the sub-processes can be included as objects in the diagram, shown as separate systems using the UML stereotype feature, where the type of the entity in the box is shown between special symbols — for example, the admission system and the mental health care system itself appear as separate systems in the involuntary detention diagram.
• Arrows represent the flow of work from one activity to another.
• A solid bar (vertical or horizontal) indicates activity coordination. When the flow from more than one activity leads into a solid bar, all those activities must be complete before progress is possible — the bar is a join. When the flow from a solid bar leads out to a number of activities, those activities may be executed in parallel — the bar is a fork.
• Arrows may be annotated with guards, written in square brackets, which indicate under what condition a particular flow is followed.

Two notational details deserve care, because they carry the meaning of the whole diagram type:

• Join versus fork is direction, not shape. A solid bar has two behaviors that look identical and mean opposite things. Trace the arrows into the bar: many arrows in, one arrow out — a join, waiting for all inputs. One arrow in, many arrows out — a fork, enabling all outputs in parallel. Drawing the arrows the wrong way turns a synchronization point into a parallel split, and the requirement changes meaning completely.
• A stereotype names the kind of thing in a box. Writing «system» Admissions system tells the reader that this box is not an activity and not a class, but a separate system participating in the process. Stereotypes are the UML's mechanism for extending the notation: between chevrons (the special symbols « »), you state the type of the entity, and the diagram remains within the language's rules.

4.4.3 Worked Example: The Involuntary Detention Process

Working through the involuntary detention activity diagram: the process starts at the solid circle and first decides, on the basis of the patient's condition, which of the detention paths applies. The guards on the outgoing flows — written in square brackets — distinguish two categories of patient: those who are dangerous to society and those who are not. Dangerous patients may be transferred to a police station or to a secure hospital, where they can be kept under supervision; other patients may be admitted to a hospital. These three transfers (to the police station, to a secure hospital, or into hospital admission) are alternative flows, so exactly one of them is followed.

The flows from these activities then lead into a solid bar — the join. Only when the chosen transfer has completed can progress continue. From the bar, the flow forks out again into several activities that may all be executed concurrently: informing health care, informing the patient's relatives, uploading the register for social care, and updating the system, which includes updating the patient's record and the retention register. The point of the fork is that these notifications and updates do not depend on each other and can happen at the same time.

Read as a whole, the diagram says: choose the detention path by danger category, complete the transfer, then fan out all the safeguarding notifications and record updates in parallel. Every element — the join forcing completion of the transfer, the guards selecting the path, the fork running the notifications concurrently — corresponds to a requirement the system must honor.

  ● start
    │
    ▼
  ( Decide detention path )          ← activity, supported by the system
    │
    ├──[dangerous]────► ( Transfer to secure facility )   │
    │                        e.g. police station           │  exactly one
    ├──[dangerous]────► ( Transfer to secure hospital )   │  path is
    │                                                      │  followed
    └──[not dangerous]► ( Admit to hospital )             │
    │                                                      │
    ▼                                                      │
  ═══════════════  JOIN (solid bar)  ═══════════════◄──────┘
    │  ← progress possible only after the chosen transfer completes
    ▼
  ═══════════════  FORK (solid bar)  ═══════════════
    │    │        │        │
    ▼    ▼        ▼        ▼
 (Inform (Inform  (Update  (Upload register
  health  patient's  system:  for social
  care)   relatives) patient  care)
                    record +
                    retention
                    register)
    │    │        │        │
    ▼    ▼        ▼        ▼
  ○ end

The professor's own reading of the diagram captures the whole picture in one line: choose the detention path by danger category, complete the transfer, then fan out all the safeguarding notifications and record updates in parallel.

Real-world connection. Activity diagrams (and their business-process cousins) are the standard notation for documenting processes that mix people and systems — hospital admission and discharge processes, bank loan approvals, insurance claim handling. In business process management, activity models are often the blueprint from which workflow engines are configured, so the same diagram that documents the process can drive the system that executes it. For safety-critical processes like involuntary detention, the diagram doubles as an audit artifact: regulators can verify from the model alone that the safeguards exist.

4.5 Interaction Models

4.5.1 Three Kinds of Interaction

All systems involve interaction of some kind, and modeling interaction matters for three different reasons depending on the kind of interaction:

• User interaction — interaction with users, involving user inputs and outputs. Modeling this is important because it helps identify user requirements.
• System-to-system or subsystem-to-subsystem interaction — interaction between the software being developed and other systems in its environment, or between subsystems. Modeling this highlights the communication problems that may arise and the coordination issues between the various systems and subsystems.
• Component interaction — interaction between the components of the software system. Modeling this helps you understand whether a proposed system structure is likely to deliver the required system performance and dependability.

Each kind of interaction is modeled for a different reason, and the reason decides what you look for in the model:

Notice the escalation in stakes: user interaction shapes what the system must do, system-to-system interaction shapes whether it can work with its neighbors, and component interaction shapes whether it can be fast and reliable enough. A system whose components make too many chatty calls between servers, for example, will miss its response-time target — a problem visible in the interaction model long before the code exists.

To model these interactions you can use use case modeling complemented by sequence diagrams. The two present interactions at different levels of detail, and so they may be used together: the details of the interactions involved in a high-level use case can be documented in a set of sequence diagrams showing the various interaction scenarios in detail.

4.5.2 Use Case Diagrams

Use case modeling is a technique you will already be using in regular work: you describe use cases and then create use case models. It is commonly used in UML to describe what a user expects from a system in a given interaction. We saw use cases used for requirements elicitation in the previous lecture; use case models are also useful in the early stages of system design, where you describe the interaction between the user and the system.

Each use case represents a discrete task that involves external interaction with the system. In its simplest form, a use case is drawn as an ellipse containing a verb and a noun — the action and the thing the action is performed on. The actors are drawn as stick figures, either providing inputs to the system or receiving outputs from it. Actors may be human, or they may be other systems; the stick-figure notation, which was originally developed to represent human interaction only, is now also used to represent other external systems and even hardware.

One notational warning before we go on: formally, use case diagrams should use lines without arrows. Arrowheads indicate the direction of message flow, and in a use case, messages pass in both directions, so arrows would be misleading. In the transfer data example the arrows are used informally, purely to indicate that the medical receptionist initiates the transaction and that the data is transferred to the patient record system.

A use case diagram gives only a simple overview of an interaction scenario. For a complete description of the interaction you need to add more detail, and there is a menu of formats to choose from: a text description, a structured description in a table, a decision table for documenting the details of computations or other activities, or a sequence diagram showing the sequence of interactions. You pick the most appropriate format for the model you are building.

4.5.3 Worked Example: The Transfer Data Use Case and Its Tabular Description

The transfer data use case in the mental health care system performs the task of transferring data from the mental health system to the more general patient record system. The patient record system maintains summary data about the patient, whereas the mental health system records data about each consultation. There are two actors in this use case: the medical receptionist, who is transferring the data, and the patient record system, which receives it.

Notice the two levels of detail living side by side in this one use case: the mental health system holds consultation-level records (every visit, every prescription), while the general patient record system holds only summary data — a condensed picture of the patient (personal information, diagnosis and treatment summary). The transfer data use case bridges the two levels: it moves selected information from the fine-grained system to the coarse-grained one.

A typical standard tabular format is most useful for accompanying the use case diagram. The table for transfer data has these elements:

• Actors — the medical receptionist and the patient record system.
• Description — what the use case does: transferring consultation data from the mental health system to the patient record system.
• Data to be transferred — the patient data that moves between the systems.
• Stimulus — what initiates the scenario: a command issued by the medical receptionist.
• Response — the post-condition of the scenario: a confirmation that the patient record system has been updated.
• Remarks — more constraints, such as that the receptionist must have appropriate permissions to access patient information as well as the patient record system.

So the simple use case diagram is complemented with a structured, tabular description of what happens in the scenario: who the actors are, what data is transferred, what stimulus triggers the transaction, what response you get at the end, and what constraints apply.

4.5.4 Composite Use Case Diagrams

A composite use case diagram can show a number of use cases together. The various roles of a user — the medical receptionist, say — map to several use cases: register patient, unregister patient, view patient information, transfer data, and contact patient. Notice the naming convention: each use case has a clear, simple verb followed by a noun — the action, then the object the action is performed on.

It is sometimes possible to include all the interactions within a system in a single composite use case diagram, but the diagram may become complex because of the number of use case scenarios and actors involved. In that case you develop several diagrams, each showing a set of related use cases — for example, a diagram with all the use cases related to the medical receptionist, separate from the ones for the manager or the health care system. The recommended practice is to take one actor and the set of use cases associated with that actor at a time, and then elaborate the activities within each use case in a tabular description.

The UML includes a number of constructs for sharing all or part of a use case between other use cases, letting you structure diagrams at multiple levels of detail. While these constructs can be helpful for designers, generally end users find them difficult to understand. The details of these constructs are not covered in this course: at best, you keep the use case diagram simple and complement it with a sequence diagram. Exam note: you will not be examined on the include/extend-style sharing constructs of use case notation.

4.5.5 Worked Example: The View Patient Information Sequence Diagram

A sequence diagram is primarily used in UML to model interactions between the actors and the objects in the system, and between the objects themselves. The UML has a rich syntax for sequence diagrams that allows many different kinds of interactions to be modeled, but this lecture focuses on the basic sequence diagram type — you will meet the full notation in other courses such as object-oriented programming, where you need to create such models initially.

As the name implies, the sequence diagram shows the sequence of interactions that take place during a particular use case — or an instance of a use case. Take the view patient information use case, one of the medical receptionist's use cases from section 4.5.4. Its sequence diagram looks like this.

The objects and actors involved are listed at the top of the diagram: the software objects, which include the patient information server, the mental care database, and the authorization server, plus the human entity, the medical receptionist. A dotted line is drawn vertically down from each object, and the rectangle on the dotted line indicates the lifeline of the object — the time during which that object instance is involved in the computation.

You read the sequence of interactions from top to bottom. First the medical receptionist places a request to view patient information by giving the patient ID. The patient information server then checks with the authorization server, sending it the information requested, the patient ID, and the user ID of the medical receptionist. Once the authorization comes back, one of two scenarios unfolds, shown inside a box — a choice box: only one of the constrained interactions will be executed, and the condition that selects the choice is shown in square brackets. If the authorization is okay, the patient information is returned and displayed on the user's screen; if the authorization fails, an error message is shown.

There is also a sequence diagram for the transfer data use case, but its details are not gone through here. The general guidance on level of detail: unless you are using sequence diagrams for actual code generation or for detailed documentation, you do not have to include every single interaction. If you develop system models early in the development process to support requirements engineering and high-level design, there will be many interactions that depend on design and implementation decisions that have not been made yet — so do not put too much detail into sequence diagrams at the requirements engineering stage.

Real-world connection. Interaction modeling is the everyday language of API and service design: a use case diagram is effectively the contract list of an integration ("who may call what"), and a sequence diagram is the protocol walkthrough ("what messages, in what order, with what alternatives"). When the mental health care system talks to the patient record system, the sequence of calls, the authorization check, and the two outcome branches are precisely the kind of detail that integration teams negotiate — and that later appears, almost unchanged, as the interface specification.

4.6 Structural Models: Class Diagrams

4.6.1 Classes, Associations, and Static versus Dynamic Models

Structural models display the organization of the system in terms of the components that make it up and the relationships between them. Structural models may be static models, which show the planned organization of the system, or dynamic models, which show the organization of the system while it is executing — and these two are not the same thing. The organization of a system as a set of interacting threads during runtime is quite different from the static, structural representation of its components and their interconnections. This lecture focuses on class diagrams for the static structural aspect, and on state models for the dynamic behavior of the system in execution.

Class diagram notation is used when developing an object-oriented system model, to show the classes in the system and the associations between these classes. An object class can be thought of as a general definition of one kind of system object. An association is a link between classes indicating that some relationship exists between them — and so each class may have to have some knowledge of its associated class.

When you develop models during the early stages of the software engineering process, especially during requirements engineering, objects may represent something in the real world: a patient, a doctor, a prescription, an appointment, and so on. When you develop an implementation, by contrast, you define implementation objects to represent the data manipulated by the system. The focus here is on real-world objects, because that is the right level for requirements and the early stages of software design.

The distinction between real-world objects and implementation objects is worth making precise, because it explains what the class diagrams in this lecture are for. At the requirements level, a Patient class represents the real-world thing — a person attending a clinic — with the attributes and associations that matter to the health care process. At the implementation level, a patient may be a PatientRecord data structure, a PatientService object, and a stored row — several implementation objects that together implement the one real-world object. Mixing the two levels in one diagram produces classes that are neither good requirements nor good planning.

4.6.2 Worked Example: The Mental Health Care Class Diagram

Class diagrams in UML can be expressed at different levels of detail, and the first stage is usually to look at the world, identify the essential objects, and represent them as classes. The simplest way to write a class diagram is to put the class name in a box, and to note the existence of an association between classes by drawing a line between them.

A simple class diagram shows two classes, patient and patient record, connected by an association line. At this preliminary stage you do not have to say what the association is called or what type it is. But the diagram does carry a cardinality: one to one (1..1), which means each patient has one — and only one — patient record, and each patient record is associated with one, and only one, patient. It is a cardinality you will recognize from modeling semantic data models between various entities.

Elaborating the diagram, the objects of the class patient are also involved with a number of other classes: the medical consultant, the general practitioner who referred the patient to the mental health care system, the condition the patient has, the consultation the patient attends, the medication and treatment prescribed, and the hospital doctor who runs the consultation. Each association is described by a term, and you read them as sentences:

• Patient is diagnosed with condition.
• Patient is referred by general practitioner.
• Patient is referred to consultant.
• Patient attends the consultation.
• Consultation prescribes a medication.
• Consultation also prescribes a treatment.
• Hospital doctor runs the consultation.

Cardinality is the ability to show how many objects are involved in each association. The patient–patient record association is one to one, as above. Multiplicity extends this to a range, or to an exact number of objects. The notations: 1..1 for one to one, and 1..* (spoken as "one to many") for one to many. Applying multiplicity to the mental health care diagram:

• Many patients may be referred to a single consultant, and many patients may be referred by a single general practitioner.
• Many patients may be diagnosed with multiple conditions, and a single condition can be found in many patients — a many-to-many relationship.
• A patient may attend many consultations, and a consultation may treat a number of patients.
• A consultation may prescribe many medicines, and the same medication may be prescribed by many consultations; the same holds for treatments.
• A specific limitation appears on the hospital doctor association: up to four doctors may be associated with one consultation, written 1..4.

┌──────────────┐          ┌──────────────────┐
│   Patient    │  1..1    │  Patient record  │
│ (class name) │──────────│   (class name)   │
└──────────────┘  1..1    └──────────────────┘

4.6.3 Class Diagrams as Semantic Data Models and ER Diagrams

At this level of detail, a class diagram looks like an ER diagram — you will be familiar with ER diagrams from database design. These class diagrams are essentially ER diagrams without the attributes: only the entities appear, with no attribute columns. Similarly, they resemble semantic data models, which are used in database design and show the data entities, their associated attributes, and the relationships between the entities.

The UML does not have an ER diagram notation of its own, and it does not have a semantic data model notation, because in UML you model data using objects and relationships. However, you can use UML to represent a semantic data model: draw a class diagram with the associations and the cardinality of each association, using simplified object classes that have no operations and no attributes, where the relations are just named associations between the object classes. So when showing associations between classes, it is best to represent the classes in the simplest possible way — without attributes or operations.

4.6.4 Adding Attributes and Operations

To define objects in more detail you add information about their attributes — the object's characteristics — and their operations — the object's functions. A class is then represented by a rectangle with three parts: the class name in the top section, the class attributes in the middle section, and the operations in the lower section, shown as verbs with parentheses.

Take the consultation class: consultation is essentially an activity carried out by the doctor, who consults a patient and prescribes medications and treatments. Its operations include initiate a new consultation, prescribe medication, record notes, and transcribe. You may include the types of the attributes in the middle section, but the example does not show them — data types are required only when you are doing object-oriented programming. The operations are what object-oriented programming calls methods. Three dots may be used in the attribute and operation sections to show that there are many more of each.

Two practical details from the domain: doctors may record voice notes that are transcribed, to record the details of the consultation, and to prescribe medication the doctor must use the prescribed method to generate an electronic prescription.

To make the three-part rectangle concrete, the consultation class looks like this:

┌──────────────────────────────────┐
│ Consultation                    │ ← class name (top section)
├──────────────────────────────────┤
│ Doctors                         │ ← attributes (middle section)
│ Date                            │   (types omitted here)
│ Time                            │
│ Clinic                          │
│ Reason                          │
│ Medication prescribed           │
│ Treatment prescribed            │
│ Voice notes                     │
│ Transcription                  │
│ ...                             │ ← three dots: many more attributes
├──────────────────────────────────┤
│ New()                           │ ← operations (lower section),
│ Prescribe()                     │   shown as verbs with parentheses
│ RecordNotes()                   │   (methods in object-oriented
│ Transcribe()                    │   programming)
│ ...                             │
└──────────────────────────────────┘

Each operation is an action the consultation supports: New() initiates a new consultation, Prescribe() prescribes medication (and, in the domain, generates an electronic prescription through the prescribed method), RecordNotes() records the consultation notes, and Transcribe() turns the recorded voice notes into a written transcription. Attribute types are optional at this modeling stage — you write them only when you are moving into object-oriented programming, where they become the declared types of the implementation.

4.6.5 Generalization

Generalization is the concept used to structure information in a hierarchical format to manage complexity. Rather than learn the detailed characteristics of everything we experience, we learn about general classes and their characteristics; we then reuse knowledge by classifying things and focusing on the difference between them and their class. For example, you may have a variety of cars, but all of them belong to the general class of car.

When modeling a system, generalization is often used to examine the classes in the system and see whether there is scope for creating generalized classes. The benefit is that common information is maintained in one place only — a good design practice, because if changes are proposed you do not have to look through all the classes in the system to see whether they are affected; you make the change at the most general level and every subclass picks it up.

The UML has a specific association to denote generalization: a triangle pointing towards the generalized class — a small arrowhead pointing up to the general class. In the mental health care example, general practitioners and hospital doctors both belong to the class of doctors and can be generalized as such. Within hospital doctor there may be a consultant and a team doctor; and a team doctor may be either a trainee doctor — a resident or intern who needs supervision — or a qualified doctor who can work unsupervised as part of the consultancy.

The rule of inheritance: the attributes and operations associated with the higher-level classes are also associated with the lower-level classes. The lower-level classes are subclasses that inherit the attributes and operations from their superclasses, and they may add more detail to the attributes or operations they derive from the parent classes.

In the doctor generalization hierarchy: all doctors — hospital doctors and general practitioners alike — have common attributes such as name, phone number, and email, and the operations register and deregister apply to every doctor in the patient health care system. Only hospital doctors also have a staff ID number, and some may be consultants with a mobile number or pager number. General practitioners do not share that information, because they work independently: they have their own independent practice and an address that is not part of the hospital. The diagram shows only part of the hierarchy — you can always extend it further.

The doctor hierarchy shows the pattern completely:

                ┌──────────────┐
                │    Doctor    │ ← superclass: Name, Phone #, Email,
                └──────▲───────┘   register(), deregister()
                       │  (triangle/arrowhead points UP to the
                       │   more general class)
        ┌──────────────┴───────────────┐
┌───────┴────────┐           ┌─────────┴─────────┐
│ General        │           │  Hospital doctor  │ ← adds Staff #,
│ practitioner   │           └─────────▲─────────┘   Pager #
└────────────────┘                     │
                    ┌──────────────────┴───────────┐
             ┌──────┴──────┐              ┌────────┴────────┐
             │ Consultant  │              │  Team doctor    │
             └─────────────┘              └────────▲────────┘
                                     ┌─────────────┴─────────────┐
                              ┌──────┴────────┐         ┌────────┴────────┐
                              │ Trainee       │         │ Qualified      │
                              │ doctor        │         │ doctor         │
                              │ (supervised)  │         │ (unsupervised) │
                              └───────────────┘         └─────────────────┘

Read the hierarchy top-down as what everyone inherits: every node below Doctor has name, phone number, and email, and supports register and deregister, because those belong to the superclass. Hospital doctor adds a staff ID number (and consultants may add a mobile or pager number), while General practitioner instead has an independent practice with its own address — hospital staff information does not apply, because GPs work independently and are not part of the hospital. Inheritance is one-way: the general class's features flow down; the subclasses only add.

4.6.6 Aggregation

Objects in the real world are often made up of different parts. For example, a study pack for a course on a learning management system (LMS) contains quizzes, assignments, lecture slides, and old question papers. In a system model you need to illustrate this whole-part relationship. For example, a patient record contains patient information and all the consultations that the patient has taken.

This association between classes is called aggregation: one object is composed of other objects. To draw it, a diamond-shaped symbol is added to the link next to the class that represents the whole — the larger thing of which the associated classes are parts. So the patient record is an aggregation of the patient and an indefinite number of consultations: the record maintains the patient's information as well as the individual record for each consultation that has been done with the doctor.

To summarize the structural modeling notation: generalization is shown by an upward-pointing triangle attached to the superclass (the base class), and aggregation is shown by a diamond attached to the class that consists of the subclasses that are parts of the main class. Together with the plain association, these give you the structural models that show the data entities in the system and their relationships.

┌───────────────┐   ◆ (diamond on the WHOLE)
│  Study pack   │◄────┐
└───────────────┘     │   ← the diamond sits next to the class that
                      │     represents the whole (the larger thing)
     ┌───────────────┼──────────────┬──────────────┐
     ▼               ▼              ▼              ▼
┌───────────┐  ┌───────────┐  ┌────────────┐  ┌──────────────┐
│  Quiz     │  │Assignment │  │ Slides     │  │Old question  │
│           │  │           │  │            │  │papers        │
└───────────┘  └───────────┘  └────────────┘  └──────────────┘

┌────────────────┐   ◆
│ Patient record │◄────┐
└────────────────┘     │   aggregation: 1 Patient + 1..* Consultation
     ┌─────────────────┴──────┐
     ▼                        ▼
┌───────────┐          ┌──────────────┐
│  Patient  │   1..*   │ Consultation │
│   (1)     │◄────────►│ (indefinite  │
└───────────┘          │  number)     │
                       └──────────────┘

Real-world connection. Class diagrams are the backbone of object-oriented development: every object-oriented project — from hospital systems to banking platforms — starts from the classes and associations agreed in the requirements stage, and the generalization and aggregation structures carry over directly into the inheritance and composition of the implementation language. In database design, the same entity-level diagram becomes the ER model from which tables and relationships are derived. Learning management systems like the study pack example (quizzes, assignments, slides, papers as parts of a pack) show aggregation in everyday products: a course, an order, and a playlist are all aggregates of their contents.

4.7 Behavioral Models: State Diagrams

4.7.1 From Data-Driven to Event-Driven Modeling

The behavioral models of a system — how the system responds when it is executing — can be approached in two ways, and it is worth noting who finds which one easier. Users of a system often find data flow diagrams more simple and intuitive, because they follow the data from input to output. Software engineers, on the other hand, may prefer sequence diagrams to model the system.

The split is not about taste; it is about what each group knows. A data flow diagram shows the sequence of processing: input data arrives, a transformation acts on it, the result moves to the next transformation, and eventually an output leaves. Nonexperts find this natural because it mirrors how work appears to flow — the same reason activity diagrams in the UML can stand in for data flow diagrams. Software engineers, however, are used to thinking in terms of objects and the calls between them, so they naturally reach for sequence diagrams, which highlight the objects and their message exchanges. Both are valid behavioral views; they just foreground different things — data flow diagrams foreground the operations, sequence diagrams foreground the objects.

Moving on from this data-driven modeling to event-driven modeling: event-driven modeling shows how a system responds to external and internal events. It is based on the assumption that a system has a finite number of states, and that events — also called stimuli — may cause a transition from one state to another. For example, a system controlling a valve in a chemical factory may move from a state called valve open to a state called valve closed when an operator command (a stimulus) is received.

This view of a system is particularly appropriate for real-time systems, where the dynamic view of the various components and which states they are in matters constantly. Event-driven modeling is used extensively while documenting or designing real-time systems.

4.7.2 State Machine Concepts

UML has diagrams specifically suited to real-time systems: state diagrams, which are based on state transition diagrams and show the system states and the events that cause transitions from one state to another. They do not show the sequence of flow of data within the system — that is the job of the data flow diagram — though they may include more information about the computations carried out in each state.

State machine models — also called state models or state charts — model the behavior of the system in response to internal and external events. The system's states are shown as nodes, and the events that cause the transitions between states are shown as lines (arcs) connecting the nodes. When an event occurs, the system moves from one state to another. State diagrams, or state charts, are part of UML and are used to represent state transition diagrams or state machine models.

Three concepts carry the whole diagram type:

• State — a situation in which the system is waiting, drawn as a rounded rectangle with a name. While in a state, the system may perform an action, written after "do" (for example, a state may say "do: display time" — an action performed while the system is in that state).
• Event (stimulus) — something that happens to the system from outside (a button pressed, a door opened) or inside (a timer expiring). Events are the only things that move the system between states.
• Transition — the move from one state to another, drawn as an arc labeled with the event that causes it.

The UML state diagram is based on statecharts, a notation developed by Harel in 1987 precisely to make state-based modeling manageable for large real-time systems — which is why the superstate mechanism of section 4.7.4 is part of the notation from the start.

4.7.3 Worked Example: The Microwave Oven State Diagram

To illustrate event-driven modeling, consider a simple example: a microwave oven. Any electronic equipment is quite complex in reality, but this simplified version exists purely to make the concept of a state diagram clear. And the skill you are expected to build here is the reverse direction: for a given description, you should be able to draw a simple state diagram showing the various states and the events that cause the transitions from one state to another. Exam note: expect to draw a state diagram from a plain description of a device's operation.

The microwave oven has a switch to select either full power or half power, a numeric keypad to set the cooking time, and a start/stop button; an alphanumeric display shows whether the system is waiting or ready. The normal sequence of actions: first select the power level, either full or half; then input the cooking time using the numeric keypad; then press start. For safety reasons the oven should not operate when its door is open, and the simple display is used to show various alerts and warning messages.

In a UML state diagram, rounded rectangles represent the system states, each with a name — waiting, full power, half power, set time, enabled, disabled, operation, and back to waiting. The state name may be complemented by an action to be performed in the state, written in the form "do: display time" — an action that is performed while the system is in that state, such as displaying the time or reading the keypad input for setting the time.

Walking through the diagram from start to finish: the system starts from the waiting state — the start is drawn as a solid circle, as in activity diagrams, and the end as a solid circle inside another circle. From waiting, the system responds to either the full power or the half power button. Users can change their minds after selecting one of these: from full power they may press half power, and from half power they may press full power. Then the time is set: the system moves to the setting time state, the time is set, and if the door is closed, the system becomes ready. You can then enable the start button, and pressing start begins the oven operation: cooking takes place for the specified time. At the end of the cooking cycle the system returns to the waiting state.

You can read the diagram from left to right, from start to stop. Within each state, a certain action is performed, and from each state you transition to another by responding to an event. This example is simplified — in typical state-based modeling, the number of possible states increases quite rapidly, and for large system models you need to hide detail.

 ● start
 │
 ▼
┌──────────┐   Full power   ┌──────────────┐
│ Waiting  │───────────────►│  Full power  │◄──────────────┐
│ do:      │                │ do: set      │                │
│ display  │◄───────────────│ power = 600  │                │
│ time     │   Half power   └──────┬───────┘                │
└────┬─────┘                      │  Half power            │
     │   Half power               ▼                        │
     └──────────────►┌──────────────┐   Full power         │
                     │  Half power  │──────────────────────┘
                     │ do: set      │
                     │ power = 300  │
                     └──────┬───────┘
                            │  Number (numeric keypad)
                            ▼
                     ┌──────────────┐
                     │  Set time    │
                     │ do: get      │   Timer
                     │ number       │──────► (set → ready when
                     │ exit: set    │         door closed)
                     └──────┬───────┘
                            │  Door closed
                            ▼
                     ┌──────────────┐   Start    ┌──────────────────┐
                     │   Enabled    │───────────►│    Operation     │
                     │ do: display  │            │ (super state —   │
                     │ 'Ready'      │            │  see 4.7.4)      │
                     └──────────────┘            └────────┬─────────┘
                     ▲    Door open                       │
                     │                                    │
                     └─────────────── Door closed ◄───────┘
                       (Door open anywhere → Disabled:
                        do: display 'Not ready')

4.7.4 Super States

One way to hide detail in a large state model is the super state: a state that encapsulates a number of separate states. The super state looks like a single state at a particular level of the high-level model, but it can be expanded to show more detail on a separate diagram.

In the microwave example, the operation state is a super state that expands into a number of substates. The operation starts with a status check: if any problems are discovered — a turntable fault or a microwave emitter fault, for example — an alarm is indicated; if everything is okay, the system moves to the cooking state, where it runs the microwave generator for the specified time, and upon completion sounds a buzzer for five seconds. From within the operation super state, other events can pull the system out of it entirely: if the door is opened during the operation state, the oven goes to the disabled state; if the operation is cancelled, it goes back to the waiting state; and once the operation completes, it automatically goes to the waiting state. In this way the complexity of the state diagram can be managed: the high-level diagram stays readable, and the detail lives in the expansion.

The super state is a viewing mechanism, not a new kind of behavior. The expanded diagram shows the same events the high-level diagram showed — the door-open arc still leaves the whole super state — and the substates exist only inside it. The gain is that the high-level diagram has one box where the detailed diagram would have five, and the five live on their own diagram where they can be studied without noise. Two facts make the super state work:

• Transitions to and from the super state apply to it as a whole. "Door open → Disabled" on the super state means the door-open event exits the super state from any of its substates. The detail diagram does not have to repeat that arc on every substate.
• Entry into the super state always begins at its initial substate. Entering operation means starting with the status check — the substate marked as the initial one inside the expansion.

  ┌───────────────────────────────────────────────┐
  │                 Operation (super state)       │
  │  ● → Checking → [OK] → Cooking → Done         │
  │        │               │          │           │
  │        │ faults        │          ▼           │
  │        ▼               │      (buzzer on      │
  │      Alarm             │       for 5 secs.)   │
  │        │               │          │           │
  │        ▼               │          ▼           │
  │      (Disabled)        │       (→ Waiting)    │
  │  Door open → exits super state entirely       │
  │  Cancel   → back to Waiting                   │
  └───────────────────────────────────────────────┘

4.7.5 Complementing State Diagrams with Tables

State models of a system provide an overview of event processing, but you normally have to extend them with a more detailed description of the stimuli, in a tabular format, together with the states and the events. The table lists the states and the events that stimulate the state transitions, along with a description of each state and event.

For the microwave oven, the various states are: waiting state, half power state, full power state, set time state, disabled state, enabled state, and operation state — and in the operation state you describe what happens during the operation. Apart from the states, you can list the events or stimuli: pressing the button for half power, pressing the button for full power, switching on the timer, entering the number of units of time with the numeric keypad, opening the door, closing the door, pressing the start button, and pressing the cancel button.

This is behavioral modeling, and it is different from data flow modeling: data flow diagrams show the sequence of processing and the inputs and outputs, whereas the state view shows only the states and the corresponding events that trigger the transition from one state to another — including the transition that sends the system back to the waiting state from start to finish of a given scenario. Together, static and dynamic modeling — structural modeling and behavioral modeling — give you the two halves of how the system is organized and how it behaves.

Real-world connection. Event-driven modeling is the working method for real-time systems — chemical plant valve controllers, aircraft systems, phone switching systems, and the embedded controllers in domestic appliances. The microwave example scales directly: the same states-and-stimuli pattern (with super states hiding detail) is how the control software of an insulin pump, a car's engine management, or a factory robot is specified and documented, and the state/event tables become the acceptance tests the device must pass.

Exam Guidance Summary

This section collects every exam-related statement the professor made during the lecture, with pointers to the sections where each topic is developed.

• Drawing state diagrams from a description: the core practical skill of the behavioral modeling section is to take a plain-language description of a device and produce a simple state diagram showing the states and the events that cause the transitions between them. Expect this on the exam: given a paragraph describing a device's operation (like the microwave oven), you must extract the states (waiting, full power, half power, set time, enabled, disabled, operation), the events that cause the transitions (power buttons, numeric keypad, door open and closed, start, cancel), and the arcs between them — including the change-of-mind paths and the safety behavior (section 4.7.3).
• State and event tables: state models should be extended with a tabular description listing the states, the events (stimuli) that trigger transitions, and what happens in each state. A state diagram alone is an overview; the tables carry the precise meaning of each state (what the display shows, what power is set, when the buzzer sounds) and each stimulus (what pressing the key physically means), so the model is unambiguous (section 4.7.5).
• Use case notation scope: the UML constructs for sharing all or part of a use case (the include/extend-style mechanisms) are not covered in this course; keep use case diagrams simple and complement them with sequence diagrams. You will not be examined on these sharing constructs (section 4.5.4).
• Sequence diagram depth: the basic sequence diagram type is what matters here; the full rich syntax is covered in other courses such as object-oriented programming, and at the requirements stage you should not include every interaction. For the exam, know the basics: participants with lifelines at the top, interactions read top to bottom, and the choice box (alt) with square-bracket conditions (section 4.5.5).
• Modeling levels in requirements engineering: know that models are built at both the user-requirements level and the system-requirements level, and that they may be graphical, descriptive, or mathematical. The requirements document collects these models from the elicitation and analysis activity, and they are validated with the rest of the specification (section 4.1.1).
• Textbook and courseware: the topic is covered in the courseware and in the textbook chapters announced for this lecture — refer to the announced chapters and courseware modules when studying. The systems modeling chapter (context models, interaction models, structural models, behavioral models, model-driven engineering) matches the lecture's order and notation exactly.

Key Industry Applications

Every modeling technique in this lecture is used in real systems today. This section collects the named applications from the lecture, tied to the sections where each technique is developed.

• Mental health care patient information system — the running example throughout the lecture: a real system that manages information about patients attending mental health clinics and their prescribed treatments, including the legally sensitive involuntary detention process, which motivates context models, business process models, activity diagrams, use case models, sequence diagrams, and class diagrams. It is a genuine domain for the whole modeling toolkit: an organization with many interacting systems (patient record, admissions, prescriptions, appointments, statistics, management reporting), legally enforced process safeguards, and fine-grained clinical data that must be summarized for other systems (sections 4.3–4.6).
• Banking systems — an example of a case where the system boundary is relatively clear: automating customer-facing operations while backend operations stay outside the new system. When the boundary is obvious, the context model is quick to draw and the project concentrates its analysis inside the line (section 4.3.1).
• Chemical factory valve control — a canonical real-time example of event-driven modeling: a controller moves a valve from open to closed on an operator command. The valve is the purest illustration of states and stimuli, and the same pattern governs plant-wide control systems (section 4.7.1).
• Real-time systems — event-driven modeling and state diagrams are used extensively when documenting or designing systems whose dynamic state matters continuously: process control, switching systems, and embedded controllers. For these systems, the state diagram is not a documentation extra — it is the specification of the control logic (section 4.7.1).
• Microwave ovens (and electronic equipment generally) — state diagrams are used to capture the states and events of embedded device operation, from power selection to safety interlock behavior with the door. Any appliance or device with buttons, a display, and safety constraints is specified this way, and the states-and-stimuli tables double as the device's acceptance tests (sections 4.7.3–4.7.5).
• Model-driven engineering — in model-based development, complete and correct UML models are converted into skeleton code, so notation discipline (line versus arrow) becomes a code-generation contract. Where platforms change quickly or code volume is large — for example, generating platform-specific code for different car models from shared platform-independent models — MDE turns the models themselves into the production artifacts (section 4.2.4).
• Agile methods — graphical models, including informal box-and-line diagrams and incomplete UML models, are used as a means of discussion and clarification between developers and stakeholders. The whiteboard sketch is the agile project's working model: fast to draw, easy to argue about, and deliberately disposable once the understanding is shared (section 4.2.2).
• Object-oriented programming — class diagrams (classes, attributes, operations, generalization, aggregation) are the structural backbone of object-oriented development, and sequence diagrams reappear in OOP courses, where the full notation is covered. The hierarchy structures drawn here (the doctor generalization, the patient record aggregation) map directly onto inheritance and composition in the implementation language (sections 4.5.5, 4.6).
• Database design — class diagrams at the entity level double as ER diagrams and semantic data models, connecting UML to the data modeling world. A requirements-stage class diagram of patients, consultations, medications, and treatments is the starting point of the database schema that stores them (section 4.6.3).
• Learning management systems (LMS) — the study pack example (quizzes, assignments, lecture slides, old question papers) illustrates aggregation as a whole-part structure: a course pack is composed of its contents, and the aggregation diamond records that relationship in the system model (section 4.6.6).