SOFTWARE ENGINEERING

Complete Study Notes

Use Case Models · Class Diagrams · Activity Diagrams Sequence Diagrams

· DFDs · Software V&V;

TABLE OF CONTENTS

1. Use Case Model pg 2

2. UML Class Diagram pg 4

3. Activity Diagrams pg 6

4. Sequence Diagrams pg 8

5. Data Flow Diagrams (DFD) pg 11

6. Software Verification & Validation pg 14

 0 Use Case Model Use Case Diagrams, Relationships & Elaborated Use
1 Cases

What is a Use Case Model?

Definition: A Use Case Model captures the functional requirements of a system from the user's perspective. It
shows what the system does (not how) and who interacts with it. It consists of use cases, actors, and their
relationships.

Key Components
Use Case A specific functionality/task the system performs. Represented by an ellipse. Placed
inside the system boundary rectangle.

Actor Anyone or anything outside the system that interacts with it. Shown as a stick figure.
Name appears below the figure.

System Boundary A rectangle enclosing all use cases. Separates inside the system from the outside
world.

Association Line Connects an actor to a use case. Represents communication between them.

Initiating Actor Actor who starts/triggers the use case. Placed on the LEFT side.

Receiving Actor Actor who receives value from the use case. Placed on the RIGHT side.

Important Rules to Remember

• Actors are always OUTSIDE the system boundary; use cases are INSIDE.
• Never draw an arrow directly between two actors.
• Never draw a direct arrow between two use cases (except for include/extend/generalization).
• The diagram shows WHAT use cases exist, NOT the order they execute in.
• Every use case must be initiated by an actor (has an association line from actor).
• The use case name appears inside the ellipse or just below it.

Relationships in Use Case Diagrams

Relationship Symbol Meaning

Uses / Include <> dashed One use case ALWAYS uses the functionality of another. Models
arrow reusable common functionality shared by two or more use cases.

Extends <> dashed One use case OPTIONALLY extends the functionality of another. The
arrow extension only occurs under certain conditions.
Actor Hollow triangle Several actors share commonality. Example: Corporate Customer and
Generalization arrow Individual Customer are both types of Customer.
(inheritance)

■ Exam Key difference: Include = ALWAYS happens. Extend = OPTIONALLY happens. Lecturers love
Tip asking this distinction!

Elaborated Use Case — Structure

An Elaborated Use Case adds detailed interaction between actor and system. Components:
Use Case Name | Priority (implementation priority) | Actors | Summary (brief description) | Preconditions
(what must be true BEFORE) | Post-Conditions (state AFTER completion) | Uses/Include | Extends |
Normal Course of Events (step-by-step happy path) | Alternative Path (deviations) | Exceptions (error
conditions) | Assumptions

Limitations of Use Cases

• Use cases alone are NOT sufficient for capturing all requirements.
• Non-functional requirements (performance, reliability, portability, usability) are NOT documented in
use cases.
• Domain/business rules and legal issues are not captured.
• System is treated as a black box — internal details hidden.
• Example non-functional: "System must support 7×24 operation", "Authorization within 1 minute 90%
of the time".

How to Draw a Use Case Diagram — Step by Step

Step
Identify the system boundary — draw a rectangle, name the system inside it.
1

Step Identify all actors — people, organizations, external systems that interact with the system. Draw as
2 stick figures outside the rectangle.

Step Identify all use cases — each major function the system performs. Draw as ellipses inside the
3 rectangle.

Step
Draw association lines between actors and the use cases they participate in.
4

Step Identify relationships between use cases (include/extend) and between actors (generalization). Add
5 with dashed arrows and labels.

Step
Place initiating actors on the LEFT, receiving actors on the RIGHT.
6

■ Exam Conceptual question: "What is the difference between an Actor and a Use Case?" — Actor is
Tip OUTSIDE the system, does things. Use Case is INSIDE the system, represents a function/service
provided by the system.
 0 UML Class Diagram Static structure of classes, attributes, operations &
2 relationships

What is a Class Diagram?

Definition: A class diagram shows the static structure of all classes in a system — their attributes (data),
operations (methods), and the static relationships between them (associations and subtypes). It is NOT about
behaviour or time sequence.

Uses of Class Diagrams

Analysis Build a conceptual domain model with semantic associations between concepts.

Design Structural model of the design in terms of class interfaces.

Implementation Source code documentation — exposing the implementation structure.

Anatomy of a Class
A class is drawn as a rectangle divided into 3 sections:
Top section: Class Name (starts with capital letter)
Middle section: Attributes — properties each object holds. Format: attributeName: DataType. Example:
number: String, price: Money
Bottom section: Operations — services/methods the class can perform. Format: methodName(parameters):
returnType. Example: Send(), Close()
A class can have 0 to n attributes and 0 to n operations.

Key Concepts
Class A set of objects sharing the same properties, behaviour and semantics.

Object An instance of a class. In a diagram, object name is underlined. Format: objectName:

ClassName

Attribute A named property of a class. Each object of the class takes a specific value for it.

Operation A service that can be requested from objects of the class. Has a signature:
return-type, name, parameters.

Signature The combination of return-type + name + parameters of an operation. Describes

everything needed to use it.

Association A relationship/link between two classes. Drawn as a line between them.

Inheritance Called Generalisation in UML. Shown with an upward hollow triangle arrow (child →
parent).

Aggregation vs Composition
Feature Aggregation Composition

Symbol Hollow diamond Filled diamond

Relationship Whole-part (weak) Whole-part (strong ownership)

Part lifespan Part can exist independently Parts live and die with the whole

Example Department has Employees Bike has Wheel & Frame (from slides)

Object Diagram

Object Diagram: Shows a SET of objects and their relationships at a specific POINT IN TIME. Like a
snapshot of the system. An object is shown like a class rectangle but with the name underlined. Format:
objectName: ClassName (object name is optional — can show just : ClassName).

CRC Cards

CRC (Class-Responsibility-Collaboration) Card: A simple index card used to identify classes during
object-oriented design. Contains: Class name, its Responsibilities (what it knows/does), and its Collaborations
(other classes it works with).

How to Draw a Class Diagram — Step by Step

• Step 1: Identify classes from the problem domain (nouns in the requirements).
• Step 2: Draw each class as a 3-section rectangle (Name | Attributes | Operations).
• Step 3: Define attributes for each class with type: name: Type.
• Step 4: Define operations (methods) for each class.
• Step 5: Identify relationships — draw association lines between related classes.
• Step 6: Add multiplicity to associations (1, *, 0..1, 1..*).
• Step 7: Identify inheritance hierarchies — draw with hollow triangle arrow pointing to parent.
• Step 8: Mark aggregation (hollow diamond) and composition (filled diamond) where applicable.

■ Exam Common question: "What is the difference between Aggregation and Composition?" Remember:
Tip Composition = STRONG ownership, parts cannot exist without the whole. Aggregation = WEAK
ownership, parts can exist independently.
 0 Activity Diagrams Procedural logic, workflows & business processes
3
What is an Activity Diagram?
"Activity diagrams are a technique to describe procedural logic, business processes, and work flows." — M.
Fowler. It models the DYNAMIC aspects of a system and serves the same function as a flowchart. It shows
the flow from action to action.

Uses of Activity Diagrams

• Model business workflows.
• Identify candidate use cases through examination of business workflows.
• Identify pre- and post-conditions for use cases.
• Model workflows between/within use cases.
• Model complex workflows in operations on objects.
• Provide pictorial description of a use case (from USE_CASE slides).
• Express the dynamic aspect of the system.

Elements of an Activity Diagram

Element Symbol Description

Initial Node Solid filled circle Starting point of the activity. There can be multiple initial nodes.

Activity / Action Rounded A step or task performed. Labelled with a verb phrase.
rectangle

Decision Node Diamond shape A point where a choice must be made. Outgoing arrows labelled with
guard conditions [condition]. Shows alternate flows of control.

Merge Node Diamond shape Joins multiple flows back into one (no synchronization needed).

Fork Thick horizontal/ Splits one flow of control into TWO or MORE parallel (concurrent) flows.
vertical bar

Join Thick horizontal/ Merges two or more parallel flows into ONE. All flows must arrive before
vertical bar continuing. Called a synchronization bar.

Activity Final Bull's eye (circle Terminates THE ENTIRE activity. All concurrent flows stop.
Node in circle)

Flow Final Circle with X Terminates ONE PATH only. Other flows in the activity continue.
Node inside
Swimlane Vertical solid Groups actions by responsible class/actor/use case. An activity belongs
(Partition) lines dividing to only ONE partition, but transitions can cross lanes.
diagram

Send Signal Convex polygon Activity sends a message to an external participant.

(pointing right)

Receive Signal Concave Activity receives a message from outside. Has effect of waking up an
polygon (notch action.
on left)

Tokens — Key Concept

Token: Conceptually, UML models information moving along an edge as a token (real data, object, or focus of
control). The start node creates a token → it travels to the next action → a Fork creates one token per
outbound flow → a Join produces one outbound token once ALL inbound tokens arrive. Edges can have a
weight (how many tokens needed) and a guard condition.

Swimlanes (Partitions) — Key Details

• Can be partitioned by: the CLASS/ACTOR doing the activity, OR the USE CASE the activity belongs
to.
• Partitioning by class/actor can help identify NEW associations not yet in the class model.
• Partitioning by use cases helps document how use cases interact.
• Transitions BETWEEN actions may cross partition lines.

How to Draw an Activity Diagram — Step by Step

• Step 1: Place the Initial Node (solid black circle) at the top.
• Step 2: Identify all activities/actions — draw as rounded rectangles with verb labels.
• Step 3: Connect activities with arrows (transitions) showing flow direction.
• Step 4: Add Decision nodes (diamonds) where choices occur. Label outgoing arrows with [guard
conditions].
• Step 5: Add Fork bars for parallel activities and Join bars to reunite parallel flows.
• Step 6: If different actors/classes are responsible for different actions, add Swimlanes (vertical solid
lines).
• Step 7: Add Send/Receive signal shapes where the activity interacts with external processes.
• Step 8: Place Activity Final Node (bull's eye) at the end.

■ Exam Key distinction: Fork vs Decision — Fork splits into CONCURRENT (parallel) flows; Decision
Tip splits based on a CONDITION (only one path taken). Also: Activity Final kills everything; Flow
Final kills only one path.
 0 Sequence Diagrams Object interactions, message flows & combined
4 fragments

What is a Sequence Diagram?

Definition: A sequence diagram models the interactions between objects in a SINGLE USE CASE. It shows
how different parts of a system interact and the ORDER in which interactions occur when a use case is
executed. Time flows TOP to BOTTOM. It is one of 3 types of Interaction Diagrams in UML (alongside
Communication Diagrams and Timing Diagrams).

Key Components
Lifeline Represents an object/participant. Drawn as a rectangle at the top with a dashed
vertical line below it. Arranged HORIZONTALLY across the top. No two lifelines
should overlap. If owned by a use case, an actor symbol (stick figure) is used.

Activation Bar A narrow rectangle ON the lifeline. Indicates the object is active/executing during that
period. Length = duration of activation.

Message Arrow An arrow from caller (sender) to receiver. The message description goes ON the
arrow. Can flow left-to-right, right-to-left, or back to itself.

Message Signature attribute = message_name(arguments): return_type (all parts except message_name

are optional)

Types of Messages
Message Arrow Style Meaning
Type

Synchronou Filled arrowhead Sender WAITS for receiver to process and return before continuing.
s Blocking call.

Asynchrono Open/stick Sender does NOT wait. Continues sending other messages immediately.
us arrowhead

Return Dashed arrow Receiver is done processing. Returns control to caller. Tip: minimize return
messages — return value can be written on the initial arrow.

Reflexive Arrow looping Object sends a message to ITSELF. Starts and ends at the same lifeline.
back to same
lifeline

Creation Dashed arrow to Creates a new object mid-sequence. The participant box appears below
dropped box the top of the diagram (dropped position).
Destruction X at end of Deletes a participant. An X is placed at the end of the lifeline of the
lifeline participant being destroyed.

Combined Fragments — Handling Complex Logic

Combined Fragments are boxes (frames) drawn around sections of a sequence diagram to show complex
interactions like loops and alternatives. The fragment type (operator) is written in the TOP-LEFT corner of the
frame.

Fragment Oper Models Notes

ator

Alternative alt if-then-else logic Divided by dashed lines into operands. Each operand has a
[guard] condition.

Option opt if-then (no else) Sequence occurs ONLY under a certain condition. NOT divided
into operands.

Loop loop Repetition Can specify Boolean test, minimum iterations, or maximum
iterations.

Reference ref Reuse part of Name of the referenced sequence diagram is written inside the
another diagram frame.

Communication Diagrams
Communication Diagram (formerly Collaboration Diagram): Another interaction diagram. Shows the SAME
information as a sequence diagram but focuses on OBJECT RELATIONSHIPS rather than time sequence.
Messages are numbered (1:, 2:, 3.1:, 3.2:) to show order. Used to model dynamic behavior with focus on
collaboration between objects.

How to Draw a Sequence Diagram — Step by Step

• Step 1: Start with a use case description — the diagram covers ONE use case.
• Step 2: Identify all objects/participants involved in the use case. Draw as lifelines (rectangles) at the
top. Arrange horizontally.
• Step 3: List all steps in the use case execution.
• Step 4: For each step, identify which message is passed between which objects. Draw message
arrows left-to-right (or right-to-left) with labels.
• Step 5: Draw activation bars on lifelines where objects are active.
• Step 6: Add return messages (dashed arrows) where needed — but minimize them.
• Step 7: If there are conditions, loops, or alternatives — wrap in Combined Fragments (alt/opt/loop).
• Step 8: If an object is created mid-sequence, show it as a dropped participant box.
• Step 9: If an object is destroyed, put X at end of its lifeline.
■ Exam Key question: "What is the difference between a Sequence Diagram and a Communication
Tip Diagram?" Sequence = time-based (vertical timeline). Communication = relationship-based
(network of objects, numbered messages).

■■ Co Common mistakes to avoid: Adding too much detail, not leaving space between arrows and text,
mmon incorrect arrow origins, outdated diagrams inconsistent with actual architecture.
Mistake
s
 0 Data Flow Diagrams (DFD) Structured analysis, context diagrams
5 & levelling

What is a DFD?
Definition: A DFD (Data Flow Diagram) is a graphical tool used to model the flow of data through a system. It
shows WHAT the system does to data — not HOW it does it internally. It is used in structured analysis to
determine logical requirements.

Why Use a DFD?

• Provides overview of: what data is processed, what transformations are performed, what data is
stored, what results are produced and where they flow.
• Graphical nature makes it an excellent communication tool between user and analyst, and between
analyst and system designer.
• Useful for analyzing BOTH existing and proposed systems.
• Relatively simple technique to learn and use.

The 4 DFD Elements

Element Gane & DeMarco & Nami Description
Sarson Yourdon ng
Symbol Symbol Rule

External Square/Rect Square/Rect Noun People or organisations OUTSIDE the system that
Entity (Sour angle angle send data in (source) or receive data from (sink) the
ce/Sink) system. They do NOT process data.

Process Rectangle Circle / Verb Work/action performed on data INSIDE the system.
with Bubble phrase Transforms inputs into outputs. Contains business
rounded logic. Also called a "black box".
corners (or
circle)

Data Store Open Two parallel Noun Repository of permanent data used by the system.
rectangle horizontal (D1, Data can be written (incoming arrow) or read (outgoing
(two lines D2...) arrow). Numbered D1, D2, D3...
horizontal
lines)

Data Flow Labeled Labeled Name Data in motion. Connects processes, external entities
arrow arrow of data and data stores. Generally unidirectional (one
direction).
DFD Levels (Decomposition)
Level Name Contents Rules

Level Context ONE process representing the ENTIRE NO data stores shown. Data stores are
0 Diagram system + external entities + data flows inside the system.

Level Overview All 4 DFD elements. Processes Must BALANCE with Context Diagram.
1 Diagram numbered 1, 2, 3... Data stores shown for first time.

Level Detailed Breakdown of a Level 1 process. Must balance with the Level 1 it
2+ Diagram Sub-processes numbered x.1, x.2... describes. Continue to show data
stores.

Data Flow Rules — CAN and CANNOT

■ Data CAN flow from ■ Data CANNOT flow from

External entity → Process External entity → External entity

Process → External entity External entity → Data store

Process → Data store (write) Data store → External entity

Data store → Process (read) Data store → Data store

Process → Process

Common DFD Errors

Black Hole A process has INPUTS but NO OUTPUTS. Data enters but never leaves.

Miracle A process has OUTPUTS but NO INPUTS. Data appears from nowhere.
(Spontaneous
Generation)

Gray Hole A process has SOME inputs and outputs but the outputs are more than the inputs can
produce. Insufficient input for the outputs generated.

■ Exam Balancing DFDs is critical — every input/output in a level 1 diagram must correspond to an
Tip input/output in the level 0 context diagram. This is called "balancing" and is a common exam
question.

How to Draw a DFD — Step by Step

• Step 1 (Context Diagram): Draw ONE circle/process labeled "0" representing the entire system.
Identify all external entities. Draw data flows between entities and the system.
• Step 2: Identify Use Cases — the ways users most commonly use the system.
• Step 3: Create DFD fragments for each use case.
• Step 4 (Level 0): Combine fragments. Layout top-to-bottom, left-to-right. Minimize crossed lines.
Number processes 1, 2, 3...
• Step 5 (Level 1+): Decompose each Level 0 process. Take use case steps → each becomes a
sub-process. Number as x.1, x.2, x.3...
• Step 6: Validate DFDs with users. Check syntax errors (structure) and semantic errors (accuracy vs
real system).
• When to stop: Stop decomposing when further breakdown is useless (primitive level reached).
Ideally aim for at least 3 levels.
 0 Software Verification & Validation Testing concepts, phases,
6 black-box & white-box testing

V&V; — Core Definitions (Boehm)

Verification Validation

"Does the product meet system specifications?" "Does the product meet user expectations?"

"Have you built the product RIGHT?" "Have you built the RIGHT product?"

Checks against written specifications Checks against actual user needs

Important: A software application can be VERIFIED but NOT VALIDATED. This happens when requirements
were not captured precisely during analysis, or a major stakeholder was missed. The software matches specs
but not actual user needs.

Defect

Defect: A variance from a desired product attribute. Can be in system specifications OR in the software
product. Anything causing customer dissatisfaction is a defect. Must be found and fixed.

Key Testing Philosophy (Popper/Dijkstra)

• The goal of testing is to EXPOSE HIDDEN DEFECTS — not to prove the software works.
• "A test is successful if it discovers an error."
• A software tester tries to BREAK the system.
• Testing shows the PRESENCE of defects, NOT the absence.
• You CANNOT prove a program is completely correct through testing.
• To disprove a theorem: ONE counter-example is enough. To PROVE it correct: infinite examples are
still insufficient — you need a formal proof.
• Testing cannot be exhaustive because: input domain is too large, and too many possible paths
through the program.

Development vs Testing

Development Testing

Creative activity Destructive activity

Goal: Show that the program WORKS Goal: Show that the program DOES NOT WORK
Test Cases vs Test Data
Test Case Corresponds to application functionality. Documents: input/output specification,
function under test, steps to perform, and expected results.

Test Data The actual inputs devised to test the system. Used as input when executing test
cases.

Phases of Testing (in order)

1. Unit Testing Tests individual components INDEPENDENTLY of others.

2. Module Testing Tests a COLLECTION of dependent components (a module). Module can be tested
independently.

3. Subsystem Tests collections of modules together. Discovers INTERFACING PROBLEMS

Testing between modules.

4. System Testing Tests the entire integrated system as a whole.

5. Acceptance Validation against USER EXPECTATIONS. Usually at the CLIENT's premises.

Testing

6. Alpha Testing Acceptance testing for customized projects. In-house testing for products.

7. Beta Testing Field testing with POTENTIAL CUSTOMERS who use the product and report
problems BEFORE general release.

Black Box vs White Box Testing

Black Box (Functional) White Box (Structural)

System treated as a black box. Internal implementation is analyzed.

Tests REQUIRED BEHAVIOR only. Tests INTERNAL STRUCTURE of code.

Tester does NOT know internal implementation. Tester analyzes design, code structure, and
documentation.

Inputs via interface; test output vs expected. Devises test cases that test specific code structures
(sequence, if, case, while).

Flow Graph Notation — White Box Testing

Flow graphs are used in white box testing to model the FLOW OF CONTROL through code. Nodes represent
groups of sequential instructions or decision points. Edges represent control flow.

Sequence Sequential instructions with NO branching. Lumped together in ONE node.

If Statement Two-way branch. Node for "if" → two nodes for true/false branches → merge back.

Case Statement Multi-way branch. One node for switch → multiple nodes for each case → merge.

While Loop Loop guard node → body → back to guard. Exits when condition is false.

■ Exam Critical V&V; question: "What is the difference between Verification and Validation?" — Verification
Tip = RIGHT product built. Validation = Right PRODUCT built. A product can satisfy specs (verified)
but fail user needs (not validated).

■ Testing phases order: Unit → Module → Subsystem → System → Acceptance (Alpha → Beta).
Phases Know the purpose of each — commonly asked as conceptual questions.
to Rem
ember
 Q Quick Reference Summary Diagram comparison & how-to cheat
R sheet

All Diagrams at a Glance

Diagram Type Purpose Key Elements

Use Case Behavioural What the system does Actors, Use Cases (ellipses), system boundary,
from user perspective include/extend arrows

Class Structural Static structure — Classes (3-box rectangles), associations,

Diagram classes, attributes, inheritance (hollow triangle),
operations, aggregation/composition (diamonds)
relationships

Activity Behavioural Flow of activities, Initial node, activities (rounded rect), decisions
Diagram workflows, business (diamond), fork/join (thick bar), swimlanes, final
processes node

Sequence Behavioural Object interactions Lifelines, activation bars, message arrows,

Diagram (Interaction) over time for ONE use combined fragments (alt/opt/loop/ref)
case

DFD Structured Data flow through a External entities (rectangles), processes

Analysis system at different (circles/rounded rect), data stores (open rect), data
abstraction levels flows (arrows)

Communic Behavioural Object relationships + Objects (boxes), association lines, numbered

ation (Interaction) interactions (same as messages (1:, 2:, 3.1:)
Diagram sequence but focus on
relationships)

Most Likely Conceptual Questions

Q
What is the difference between Verification and Validation?
1

Q
What is the difference between Include and Extend relationships in Use Case diagrams?
2

Q
What is the difference between Aggregation and Composition in Class diagrams?
3

Q
What is the difference between a Fork and a Decision node in Activity diagrams?
4
Q
What is the difference between Black Box and White Box testing?
5

Q
What is the difference between Activity Final and Flow Final nodes?
6

Q
What is the difference between a Sequence Diagram and a Communication Diagram?
7

Q
What are the rules for data flow in a DFD (what can and cannot flow where)?
8

Q
What are the 4 elements of a DFD and describe each?
9

Q
1 What are the limitations of Use Cases?
0

Q
1 What is a Black Hole / Miracle in a DFD?
1

Q
1 What are the DFD levels (Context, Level 0, Level 1) and what does each contain?
2

Q
1 What is balancing in DFDs?
3

Q
1 What is a CRC Card?
4

Q
1 What are the phases of software testing in order?
5