Software Verification & Validation
CSI3014
Module 2 – System Modelling
Dr. Naveenkumar Jayakumar
[Link]@[Link]
PRP-217-4
System Modelling
❖ The process of creating abstract, visual representations of a system
to understand, define, and communicate its requirements before
implementation.
❖ It acts as a bridge between vague user needs and precise technical
specifications, ensuring that stakeholders and developers share a
common understanding of what is to be built.
System Modelling - Purpose
❖It simplifies complex systems into abstract, visual representations (like diagrams), making it
easier to understand structure, behavior, and interactions than text alone.
❖It helps clarify vague or incomplete requirements by detailing system behavior, user
interactions, and data flow, which reduces ambiguity and miscommunication.
❖It provides a common visual language for all stakeholders (developers, designers, clients,
testers) to effectively communicate ideas and validate understanding.
❖It enables tracking of requirements from initial definition to final implementation and helps
manage changes by showing how updates impact the overall system.
❖It allows for the identification of potential design flaws, risks, and missing requirements
early in the process (during analysis and design) rather than during costly implementation.
❖Models can be used to automatically generate test cases, quality assurance scenarios, and
system documentation, streamlining verification and validation.
❖It enables engineers to filter out unnecessary details and focus on specific perspectives
(e.g., interaction, structure, context) relevant to the current analysis.
System Modelling - Perspective
System Modelling - Techniques
Context Models
❖A Visual representation of the system that models the
system as a single process interacting with external
entities, defining system boundaries, scope, and major
inputs/outputs without internal details.
Data Flow Diagram (DFDs)
❖ A Data Flow Diagram (DFD) visually represents the flow of
data through a system, using standardized symbols for
processes, data stores, external entities, and data flows to
illustrate inputs, outputs, transformations, and storage
without detailing implementation.
Data Flow Diagram (DFDs)
❖ DFDs consist of four main elements-
❖ They employ hierarchical levels, starting from a high-level overview.
Data Flow Diagram (DFDs) – Level 0 - Context
❖The Level 0 DFD, known as the Context Diagram, models the system
as a single process interacting with external entities, defining system
boundaries, scope, and major inputs/outputs without internal details.
❖In Requirements Engineering, it serves as a context model by
providing a broad, stakeholder-friendly view to clarify requirements,
identify interfaces, and prevent scope creep early.
Data Flow Diagram (DFDs) – Level 0 - Context
❖Example of Level 0
Data Flow Diagram (DFDs) – Level 1
❖ Decomposes the single process from Level 0 into 3-7 main sub-
processes, adding data stores and detailed data flows while
preserving inputs/outputs for balance.
❖ This level highlights primary functions, such as breaking a payment
system into processing, invoicing, and confirmation.
Data Flow Diagram (DFDs) – Level 2 & 3
❖ Level 2 further refines specific Level 1 sub-processes into granular
steps (e.g., payment verification and funds deduction), with associated
flows and stores.
❖Level 3 provides exhaustive detail for complex systems, mapping
every input-process-output for implementation. Levels ensure
consistency through balancing.
DFD Creation Process
Rules to be followed for DFD creation
DFD Example – Lemonade System
❖Lemonade System
❖The Lemonade System involves the following processes:
❖Customer Orders: A customer places an order for lemonade.
❖Make Lemonade: The lemonade stand owner makes the
lemonade according to the customer's request.
❖Payment: The customer pays for the lemonade.
❖Serve Lemonade: The lemonade stand owner serves the
lemonade to the customer.
DFD Example – Level 0
DFD Example – Decomposing Level 0
DFD Example – Level 1
DFD Example – Overall Decomposition
Unified Modelling Language (UML)
❖ The Unified Modeling Language (UML) is a standardized, general-
purpose modeling language used to visualize, specify, construct, and
document the artifacts of a software-intensive system.
❖ It provides a set of best engineering practices for modeling large and
complex systems, acting essentially as a blueprint for software
construction.
UML Models
❖A UML Model is a collection of diagrams and model elements that
describe a system from different perspectives.
❖ It is more than just a drawing; it is a formal representation of the
system's architecture, structure, and behavior.
❖A complete model allows different stakeholders—such as
developers, technical writers, and business analysts—to understand
the system at the level of detail relevant to them
UML Models
UML Models
UML Models
Feature Structural Diagrams Behavioral Diagrams
Static system elements and Dynamic system behavior and
Focus
their relationships. interactions over time.
To illustrate the architecture To capture workflows,
Purpose
and organization. processes, and interactions.
Represents the "nouns" Represents the "verbs"
Analogy
(classes, objects). (actions, events).
Perspective System blueprint. Interaction or process-centric.
Time Focuses on events over a
Irrespective of time.
Factor duration.
Planning and documenting Analyzing user interactions
Typical use
architecture. and runtime behavior.
UML Models - Structural
• Describes the system's structure by showing its
Class Diagram classes, attributes, methods, and their relationships.
• Shows a "snapshot" of instances of classes and their
Object Diagram relationships at a specific point in time.
• Illustrates how the system is divided into modular,
Component Diagram physical components and their dependencies.
• Represents the hardware nodes and the software
Deployment Diagram artifacts deployed on them.
• Organizes model elements into logical groups
Package Diagram (packages) to manage complexity in large systems.
• Shows the internal structure of a class or
Composite Structure component, including its parts and ports.
UML Models - Behavioural
• Captures the high-level functional requirements by showing
Use Case Diagram interactions between external "actors" (users or other systems) and
the system's "use cases" (goals).
• Acts like a flowchart to model the step-by-step workflow of
Activity Diagram
business processes or system operations.
• Models the lifecycle of a single object by showing the various states
State Machine Diagram it can occupy and the events that trigger transitions between
them.
Sequence Diagram (Interaction
• illustrates how objects interact in a chronological order.
Diagram)
• Also known as a Collaboration Diagram in earlier UML versions, it
Communication Diagram
shows the same information as a sequence diagram but focuses on
(Interaction Diagram) the structural organization of objects rather than timing.
Interaction Overview Diagram • A hybrid of an activity diagram and sequence diagrams, it provides
(Interaction Diagram) a high-level view of the flow of control.
Timing Diagram (Interaction • Focuses on the precise timing of state changes within objects
Diagram) along a linear time axis.
Structural Category - Class Diagram
❖ A class diagram is a UML (Unified Modeling Language) structural
diagram that visualizes the static design of a system by showing:
❖ Classes (with attributes and methods)
❖ Relationships between classes
❖ Constraints and multiplicities (e.g., "one-to-many")
❖It serves as a blueprint for object-oriented systems, clarifying how
components interact before implementation.
Structural Category - Class Diagram - Relationship
Relationship Symbol Description Example
General "uses" relationship
Association Solid line → Student enrolls in Course
between classes.
"Whole-part" relationship where
Aggregation Hollow diamond parts can exist independently Department has Professors
of the whole.
Strong "whole-part" relationship
Composition Filled diamond where parts cannot exist House has Rooms
without the whole.
"Is-a" relationship (subclass
Generalization Hollow triangle ──▷ Electric Car is a Car
inherits from superclass).
Temporary relationship where
Dependency Dashed arrow one class uses another (e.g., as Report Generator uses Data
a parameter).
Dashed line + hollow Payment Processor
Realization Class implements an interface.
triangle implements Payment Gateway
Structural Category - Class Diagram - Example
Structural Category - Component Diagram
Terminology Definition Symbol
A modular, replaceable, encapsulated unit with
provided/required interfaces. Represents physical
Component artifacts (JARs, DLLs, containers) or logical
services.
Contract defining operations a component offers
Interface (provided) or needs (required). Interfaces decouple
dependencies.
Boundary enclosing related components (e.g.,
Frame subsystem, package, entire system)
Structural Category - Component Diagram - Relationship
Terminology Definition Symbol
Usage relationship where a change in target may Dashed arrow (⇢)
affect source.
Dependency
Component implements an interface's operations. Dashed line + hollow
Interface Critical for polymorphism. triangle (⇢▷)
Realization
Component is physically built from other artifacts Dashed arrow +
Component (source files, libraries). Rarely used in high-level stereotype (⇢ «build»)
Realization diagrams.
Structural Category - Component Diagram - Example
Structural Category - Deployment Diagram
Term Symbol/Notation Definition Example in Library System
Physical/virtual computational
resource. Two types:<br>-
3D box (cube) or rectangle with Device Node: Hardware
WebServer (EC2), JVM
Node «device»/«executionEnvironment» (server, mobile)<br>-
(OpenJDK 17)
stereotype Execution Environment Node
(EEN): Software container
(JVM, Docker, OS)
Rectangle with «artifact» + file Physical file/deliverable
Artifact [Link], [Link]
icon ( ) deployed to a node.
Dashed arrow (⇢) from artifact to Shows where an artifact is [Link] ⇢
Deployment Relationship
node deployed. ApplicationServer
Network connection enabling
Communication Path Solid line between nodes node interaction. Labeled with HTTPS, JDBC, Consul API
protocol/tech.
Configuration parameters for
Note attached to deployment MAX_HEAP_SIZE=512m,
Deployment Specification artifact execution (env vars,
relationship STUDENT_MAX_LOANS=2
memory limits).
Represents hierarchical
DockerContainerinside
Node Nesting Node inside another node execution environments (e.g.,
EC2Instance
container in VM).
Structural Category - Deployment Diagram - Example
Behavioral Category - Use Case Diagram
❖ A use case diagram is a visual representation in UML (Unified Modeling
Language) that illustrates how users (actors) interact with a system to achieve
specific goals.
❖ It captures:
❖Actors: Roles that interact with the system (e.g., users, external systems).
❖Use Cases: Functionalities or actions the system performs (e.g., "Borrow Book").
❖Relationships: How actors and use cases connect (e.g., associations, includes, extends).
❖ It focuses on user goals, system boundaries, and high-level functionality without
technical details.
❖ Use case diagrams are used early in software design to clarify requirements.
Behavioral Category - Use Case Diagram - Relationship
❖ <<include>> Relationship
❖ A mandatory dependency where the base use case cannot complete without executing the
included use case.
❖ The included use case is always triggered as part of the base use case’s workflow.
❖ Notation: Dashed arrow with <<include>> pointing from base → included use case.
❖ <<extend>> Relationship
❖A conditional dependency where the extending use case only executes if a specific condition is
met during the base use case.
❖The base use case can complete successfully without the extension.
❖Notation: Dashed arrow with <<extend>> pointing from extending → base use case, with the
condition documented.
Behavioral Category - Use Case Diagram - example
Behavioral Category - Sequence Diagram
❖ A sequence diagram is a type of interaction diagram that shows how
objects interact with each other over time.
❖ It emphasizes the chronological order of messages exchanged
between objects to achieve a specific behavior or functionality.
❖ Sequence diagrams are commonly used to model dynamic aspects of
a system, such as workflows, processes, or interactions between
components.
Behavioral Category - Sequence Diagram - Elements
❖ Lifelines: Represent objects or participants involved in the interaction. Lifelines are depicted as
vertical dashed lines.
❖ Messages: Show communication between lifelines. Messages are represented as arrows pointing
from one lifeline to another.
❖ Activation Bars: Indicate when an object is actively processing a message. They are shown as
narrow rectangles along the lifeline.
❖ Return Messages: Optional arrows that indicate the response or return value from a message.
❖ Combined Fragments: Used to represent conditional logic, loops, or parallel execution. Examples
include alt (alternative), loop, and opt (optional).
❖ Actors: External entities that interact with the system (e.g., users or external systems).
Behavioral Category - Sequence Diagram - Example
Behavioral Category - Collaboration Diagram
❖A communication diagram (also known as a collaboration
diagram) is another type of interaction diagram in UML.
❖ It emphasizes the relationships and interactions between
objects, focusing on how messages are exchanged within a
specific context.
❖ Unlike sequence diagrams, communication diagrams do not
explicitly show time or sequence but instead focus on the
structural organization of objects and their connections.
Behavioral Category - Collaboration Diagram
❖Objects and Links
❖ Objects are represented as rectangles labeled with their class names (e.g., Student
Member, Library).
❖ Links are shown as lines connecting objects, indicating associations between them.
❖Messages
❖ Messages are labeled with numbers to indicate the order of interactions (e.g., 1:
SearchBook, 2: CheckAvailability).
❖Notifications
❖ Each message includes a notification to describe the action taking place. These
notifications provide context and clarity about the interaction.
Behavioral Category - Collaboration Diagram
Behavioral Category - Activity Diagram
❖An activity diagram in UML (Unified Modeling Language) is a
behavioral diagram that represents the flow of activities or actions
within a system.
❖ It is used to model workflows, processes, or operations, showing
how tasks are performed in a sequential or concurrent manner.
❖ Activity diagrams are particularly useful for visualizing complex
business processes, algorithms, or use cases.
Behavioral Category - Activity Diagram
❖ Start Node: ❖ Also represented as a diamond shape.
❖ Represented by a solid circle. ❖ Combines multiple flows into one after branching.
❖ Indicates the beginning of the activity. ❖ Fork and Join Nodes:
❖ End Node: ❖ Represented as thick horizontal or vertical bars.
❖ Represented by a solid circle with a border. ❖ Fork: Splits a single flow into multiple concurrent flows.
❖ Indicates the termination of the activity. ❖ Join: Merges multiple concurrent flows back into one.
❖ Action: ❖ Flow (Arrow):
❖ Represented as a rounded rectangle. ❖ Represented as arrows connecting nodes.
❖ Represents a specific task or step in the process. ❖ Shows the direction of the flow between actions or
decisions.
❖ Decision Node:
❖ Swimlanes:
❖ Represented as a diamond shape.
❖ Represented as vertical or horizontal partitions.
❖ Used to represent a conditional check or branching point.
❖ Used to group activities based on responsibilities (e.g.,
❖ Merge Node: actors or systems).
Behavioral Category - Activity Diagram
Behavioral Category - Activity Diagram
Behavioral Category – State Chart Diagram
❖ A state chart diagram (also known as a state machine diagram) in
UML is used to model the dynamic behavior of an object or system.
❖ It shows how an object transitions between different states in
response to events or conditions.
❖ A state represents a condition or situation during the lifetime of an
object, and transitions represent changes from one state to another.
Behavioral Category – State Chart Diagram - Notations
❖ States: ❖ Example: SearchBook, ConfirmBorrow.
❖ Represented as rounded rectangles. ❖ Guard Conditions:
❖ Each state represents a specific condition or status of the object. ❖ Boolean conditions written in square brackets [ ] next to transitions.
❖ Initial State: ❖ Example: [BookAvailable], [BookUnavailable].
❖ Represented by a solid circle. ❖ Actions:
❖ Indicates the starting point of the state machine. ❖ Actions performed during a transition or while in a state.
❖ Final State: ❖ Example: /UpdateStatus, /GenerateReceipt.
❖ Represented by a solid circle with a border. ❖ Composite States:
❖ Indicates the termination point of the state machine. ❖ States that contain substates, represented as nested rounded
rectangles.
❖ Transitions:
❖ Used to group related states.
❖ Represented as arrows connecting states.
❖ Show how the object moves from one state to another in ❖ History State:
response to events or conditions. ❖ Represented by a circle with an "H" inside.
❖ Indicates that the system should return to the last active substate
❖ Events:
when re-entering a composite state.
❖ Labeled on transitions to indicate the trigger for the state change.
Behavioral Category – State Chart Diagram - Example
