Unit 1: Intro to SE & UML
Learning Objectives
- Define software engineering and explain how it differs from programming
- Explain why modelling is a core activity in software development
- Identify the three main families of UML diagrams and give an example of each
Core Input
Read through each tab. Take notes on the key ideas before moving to the activities below.
Software engineering is the disciplined application of engineering principles to the design, development, testing, and maintenance of software systems. It is not simply writing code — it involves managing complexity, working with stakeholders, and making decisions under constraints.
A software engineer must consider:
- Process — how the team will plan, build, and deliver the system
- Stakeholders — everyone affected by or responsible for the system (users, clients, developers, regulators)
- Constraints — time, budget, hardware, legal requirements, and existing infrastructure
- Quality — the system must not only work, but be maintainable, secure, and usable
A programmer can write a function that works. A software engineer designs a system that works reliably, can be modified safely, and meets the needs of real users in a real context.
Before building a complex system, we create models — simplified representations that help us think, communicate, and plan. Architects draw blueprints before laying foundations; engineers build prototypes before mass production. Software engineers create diagrams before writing code.
Modelling serves three core purposes:
- Abstraction — a model captures what matters for a given question and ignores irrelevant detail. A map is useful precisely because it is not the territory.
- Communication — a shared diagram gives all stakeholders a common language. A developer, a manager, and a client can all look at the same use case diagram and understand the system's goals.
- Planning — modelling exposes problems early, when they are cheap to fix. A contradiction in a diagram costs nothing to correct; the same contradiction found during testing costs days.
A model is not a perfect copy of the system — it is a deliberate simplification. Different models highlight different aspects of the same system.
UML (Unified Modeling Language) is a standardised visual language for describing software systems. It was developed in the 1990s by Grady Booch, Ivar Jacobson, and James Rumbaugh, and is now maintained by the Object Management Group (OMG).
UML diagrams are grouped into three families:
- Structural diagrams — show the static parts of a system (classes, components, objects). Example: Class Diagram.
- Behavioural diagrams — show how the system behaves over time (processes, decisions, state changes). Example: Activity Diagram.
- Interaction diagrams — a subset of behavioural diagrams focusing on how objects communicate. Example: Sequence Diagram.
This course covers four diagram types: Use Case, Class, Sequence, and Activity — enough to describe most systems at a professional level.
Key Concepts: What is Software Engineering?
Expand each item. Think about your answer before reading the explanation.
Programming is one activity within software engineering — writing the code that implements a solution. Software engineering is the broader discipline that encompasses requirements analysis, design, testing, deployment, and maintenance.
A useful analogy: programming is to software engineering what bricklaying is to architecture. Both are essential, but the architect is responsible for the overall system — its structure, its fit to purpose, and its long-term integrity.
The Software Development Life Cycle (SDLC) is a structured sequence of phases that a software system passes through — from initial concept to retirement. It provides a common framework for planning, building, and maintaining software, regardless of which methodology a team follows.
All SDLC models include some version of these core phases:
- Specification — what should the system do? Requirements are gathered and documented.
- Design — how will it be structured? Architecture and detailed design are produced.
- Implementation — the design is translated into working code.
- Validation — does it do what was specified? Testing verifies correctness.
- Deployment — the system is released to its users.
- Evolution — the system is maintained, updated, and extended over time.
UML is used across the SDLC — most heavily during specification, design, and as living documentation during evolution. Different development methodologies organise these phases differently, as explored in the next section.
A software process can be organised in different ways. Three widely used approaches are:
Waterfall
A sequential, linear model in which each phase must be completed before the next begins: requirements → design → implementation → testing → deployment → maintenance. Changes are difficult once a phase is closed. Best suited to projects with stable, well-understood requirements and a fixed scope — for example, safety-critical or regulatory systems where full specification is required upfront.
Agile
An iterative, incremental model built around short development cycles called sprints or iterations (typically 1–4 weeks). Requirements evolve through continuous collaboration between developers and stakeholders. Working software is delivered frequently rather than at the end of a long cycle. Agile prioritises adaptability — making it well-suited to projects where requirements are uncertain or likely to change. Common frameworks include Scrum, Kanban, and Extreme Programming (XP).
Spiral
A risk-driven model that combines iterative development with systematic risk assessment. Each loop of the spiral passes through four phases: planning, risk analysis, engineering, and evaluation. The spiral model is suited to large, complex, high-risk projects where identifying and mitigating risk at each stage is more important than speed of delivery.
UML is methodology-agnostic — it is used across all three approaches. In Waterfall, diagrams are typically produced fully upfront. In Agile, they are produced iteratively and updated as the design evolves.
A stakeholder is anyone who has an interest in the system — whether they use it, fund it, regulate it, or are affected by it. Common stakeholders include:
- End users — the people who interact with the system directly
- Clients — the organisation or individual commissioning the system
- Developers and engineers — those building and maintaining the system
- Regulators — external bodies whose rules the system must comply with
Stakeholders often have conflicting priorities. A user wants simplicity; a regulator wants audit trails; a client wants low cost. Software engineering involves negotiating and balancing these demands.
Software systems do not exist in isolation — they are built under real-world constraints:
- Technical constraints — existing infrastructure, required platforms, performance limits
- Organisational constraints — team size, skills, timescales, budget
- Legal and regulatory constraints — data protection laws, industry standards, accessibility requirements
- Interoperability constraints — the system must integrate with other systems
Identifying constraints early is critical — a design that ignores them will fail in practice, even if it is technically elegant.
Key Concepts: Modelling and UML
Continue with the key concepts below.
A model is a deliberately simplified representation of a system, created for a specific purpose. A city map is a model of a city — it shows roads but not every building. A UML class diagram is a model of software structure — it shows classes and relationships but not the code inside each method.
The key insight: a model is always wrong in some ways, and that is fine. The purpose of a model is not to reproduce the system in full — it is to make a specific aspect of the system easier to think about and communicate.
Building software without models is possible for small, simple systems. For anything complex, it is risky. Models help because:
- They force you to think through the design before committing to code
- They reveal contradictions and gaps early — when fixes are cheap
- They give the whole team a shared understanding of what is being built
- They serve as documentation that outlasts the original development team
The cost of changing a diagram is near zero. The cost of changing production code is not.
UML diagrams are organised into three families, each answering a different question:
- Structural diagrams — "What exists in the system?" These show static elements: classes, objects, components, packages. The most widely used is the Class Diagram.
- Behavioural diagrams — "What does the system do?" These show processes, decisions, and state changes over time. Examples: Activity Diagram, Use Case Diagram.
- Interaction diagrams — "How do the parts communicate?" A subset of behavioural diagrams focused on message exchanges between objects. Example: Sequence Diagram.
A complete system description typically uses all three families together. This course builds up all four diagram types progressively.
No. UML is a toolkit, not a checklist. Professional engineers select the diagrams that are most useful for the task at hand. For a small web application, a class diagram and a few use cases may be sufficient. For a safety-critical system, a much richer set of diagrams is appropriate.
The skill is knowing which diagram to reach for, and when it adds more value than it costs to produce. This course gives you that judgement.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
Which of the following best describes the purpose of UML?
Which UML diagram family is concerned with the static structure of a system?
Activities
Individual task
Choose a system you interact with regularly — for example, a university learning management system, an online booking platform, or a food delivery app.
Write a short structured description (150–200 words) covering:
- The purpose of the system — what problem does it solve?
- The key users — who interacts with it and in what roles?
- The main processes — what are the three or four most important things the system does?
- The system boundary — name two things that are clearly outside the scope of this system
Pair task
Exchange your system descriptions with a partner.
Discuss the following:
- Did you make the same assumptions about the system boundary? Where do they differ?
- Did you identify the same key users? Are there any your partner missed — or vice versa?
- Which description is more precise? Why?
Note: there is no single correct answer. The goal is to see how two people can read the same system differently — and to understand why precision matters before any design work begins.
Group task
As a group, agree on a single system to use for the rest of this course. This will be your shared case study — you will build diagrams for it in Units 3–8.
Produce a shared written definition that includes:
- A one-sentence statement of the system's purpose
- A list of at least three user roles
- Three constraints that would shape the system's design (technical, organisational, or legal)
- A clear statement of two things that are outside the system boundary
Keep this definition — you will refer back to it in every subsequent unit.
Review
- Structural — show what exists in the system at a point in time. Example: Class Diagram.
- Behavioural — show what the system does over time. Examples: Activity Diagram, Use Case Diagram.
- Interaction — show how objects communicate. Example: Sequence Diagram.
A model is a deliberate simplification. It highlights one aspect of a system while omitting others. The same system can have many models — each useful for a different purpose. A model is not wrong for being incomplete; it is only wrong if it misrepresents the aspect it is intended to show.
Proceed to Unit 2: Requirements when ready.