Software Engineering – Module 3

Module 3
SYSTEM MODELING
Context models; Interaction models- Use case modeling, Sequence diagrams; Structural
models- Class diagrams, Generalization, Aggregation; Behavioral models- Data-driven
modeling, Event-driven modeling; Model-driven engineering.

System Modeling:
System modeling is the process of developing abstract models of a system, with each model
presenting a different view or perspective of that system.
➢ System modeling has now come to mean representing a system using some kind of
graphical notation, which is now almost always based on notations in the Unified
Modeling Language (UML).
➢ System modelling helps the analyst to understand the functionality of the system and
models are used to communicate with customers.
➢ In a model-driven engineering process, it is possible to generate a complete or partial
system implementation from the system model.
System perspectives: Models can explain the system from different perspectives:
➢ External perspective: where you model the context or environment of the system.
➢ Interaction perspective: where you model the interactions between a system and its
environment, or between the components of a system.
➢ Structural perspective: where you model the organization of a system or the
structure of the data that is processed by the system.
➢ Behavioral perspective: where you model the dynamic behavior of the system and
how it responds to events.
Engineers use these models to discuss design proposals and to document the system for
implementation. Use of graphical models: Five types of UML diagrams that are the most
useful for
➢ Activity diagrams: which show the activities involved in a process or in data
processing.
➢ Use case diagrams: which show the interactions between a system and its
environment.
Page | 1
Software Engineering – Module 3
➢ Sequence diagrams: which show interactions between actors and the system and
between system components.
➢ Class diagrams: which show the object classes in the system and the associations
between these classes.
➢ State diagrams: which show how the system reacts to internal and external events.
Context Models:
➢ Context Diagrams are high-level visual representations that show the interactions
between a system being developed and its external entities, such as users, other
systems, or processes.
➢ Context models are used to illustrate the operational context of a system - they show
what lies outside the system boundaries.
➢ Context models simply show the other systems in the environment, not how the
system being developed is used in that environment.
➢ Social and organisational concerns may affect the decision on where to position
system boundaries.
➢ System boundaries are established to define what is inside and what is outside the
system.
➢ Architectural models show the system and its relationship with other systems.
Components of Context model:
• System: The central focus of the diagram, representing the software system being
designed or analyzed. It is often shown as a single circle or bubble.
• External Entities: These are anything outside the system boundary that interacts with
it, such as users, other software systems, hardware devices, or physical entities.
• Data Flows: These are the arrows that connect external entities to the system,
indicating the movement of data or information. They show what data is being sent
to or received from the system. They can be unidirectional, showing the flow in a
single direction
Example:
• Student Database: A system or a collection of data related to students, which can
include information such as names, IDs, and academic records.

Page | 2
Software Engineering – Module 3
• Students’ info: Requesting or providing information related to students.
• Staff: People employed by an organization, often having a specific role or
responsibility.
• Library management system: A system used to manage and organize library
resources, such as books, periodicals, and multimedia materials.
• Stock: Inventory or resources available in a system.
• Supplier: An entity that provides goods or services to another entity.
• Book details: Information related to books, such as titles, authors, and publication
dates.
• Availability: The state of being accessible or usable. In the context, it likely refers to
the availability of books or other resources.
• Management: The process of coordinating and controlling resources to achieve
specific goals.

Use Case Diagram

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that
represents the interaction between actors (users or external systems) and a system under
consideration to accomplish specific goals. It provides a high-level view of the system's
functionality by illustrating the various ways users can interact with it.

Page | 3
Software Engineering – Module 3
Purpose of Use Case Diagrams
The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external
influences. It invokes persons, use cases, and several things that invoke the actors and
elements accountable for the implementation of use case diagrams. It represents how an
entity from the external environment can interact with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
Use Case Diagram Notations
UML notations provide a visual language that enables software developers, designers, and
other stakeholders to communicate and document system designs, architectures, and
behaviors in a consistent and understandable manner.
1. Actors: Actors are external entities that interact with the system. These can include users,
other systems, or hardware devices. In the context of a Use Case Diagram, actors initiate
use cases and receive the outcomes. Proper identification and understanding of actors are
crucial for accurately modeling system behavior.

2. Use Cases: Use cases are like scenes in the play. They represent specific things your
system can do. In the online shopping system, examples of use cases could be "Place Order,"
"Track Delivery," or "Update Product Information". Use cases are represented by ovals.

3. System Boundary: The system boundary is a visual representation of the scope or limits
of the system you are modeling. It defines what is inside the system and what is outside. The

Page | 4
Software Engineering – Module 3
boundary helps to establish a clear distinction between the elements that are part of the
system and those that are external to it. The system boundary is typically represented by a
rectangular box that surrounds all the use cases of the system.

Use Case Diagram Relationships

In a Use Case Diagram, relationships play a crucial role in depicting the interactions between
actors and use cases. These relationships provide a comprehensive view of the system's
functionality and its various scenarios.
1. Association Relationship: The Association Relationship represents a communication or
interaction between an actor and a use case. It is depicted by a line connecting the actor to
the use case. This relationship signifies that the actor is involved in the functionality
described by the use case.
Example: Online Banking System
Actor: Customer
Use Case: Transfer Funds
Association: A line connecting the "Customer" actor to the "Transfer Funds" use case,
indicating the customer's involvement in the funds transfer process.

2. Include Relationship: The Include Relationship indicates that a use case includes the
functionality of another use case. It is denoted by a dashed arrow pointing from the including
use case to the included use case. This relationship promotes modular and reusable design.
Example: social media Posting
Use Cases: Compose Post, Add Image

Page | 5
Software Engineering – Module 3
Include Relationship: The "Compose Post" use case includes the functionality of "Add
Image." Therefore, composing a post includes the action of adding an image.

3. Extend Relationship: The Extend Relationship illustrates that a use case can be extended
by another use case under specific conditions. It is represented by a dashed arrow with the
keyword "extend." This relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
Use Cases: Book Flight, Select Seat
Extend Relationship: The "Select Seat" use case may extend the "Book Flight" use case
when the user wants to choose a specific seat, but it is an optional step.

4. Generalization Relationship: The Generalization Relationship establishes an "is-a"

connection between two use cases, indicating that one use case is a specialized version of
another. It is represented by an arrow pointing from the specialized use case to the general
use case.
Example: Vehicle Rental System
Use Cases: Rent Car, Rent Bike
Generalization Relationship: Both "Rent Car" and "Rent Bike" are specialized versions of
the general use case "Rent Vehicle."

Page | 6
Software Engineering – Module 3
How to draw a Use Case diagram in UML?
Step 1: Identify Actors: Determine who or what interacts with the system. These are your
actors. They can be users, other systems, or external entities.
Step 2: Identify Use Cases: Identify the main functionalities or actions the system must
perform. These are your use cases. Each use case should represent a specific piece of
functionality.
Step 3: Connect Actors and Use Cases: Draw lines (associations) between actors and the
use cases they are involved in. This represents the interactions between actors and the
system.
Step 4: Add System Boundary: Draw a box around the actors and use cases to represent the
system boundary. This defines the scope of your system.
Step 5: Define Relationships: If certain use cases are related or if one use case is an
extension of another, you can indicate these relationships with appropriate notations.
Step 6: Review and Refine: Step back and review your diagram. Ensure that it accurately
represents the interactions and relationships in your system. Refine as needed.
Step 7: Validate: Share your use case diagram with stakeholders and gather feedback.
Ensure that it aligns with their understanding of the system's functionality.

Use Case Diagram example (Online Shopping System)

Actors:
• Customer
• Admin
Use Cases:
• Browse Products
• Add to Cart
• Checkout
• Manage Inventory (Admin)
Relations:
• The Customer can browse products, add to the cart, and complete the checkout.
• The Admin can manage the inventory.

Page | 7
Software Engineering – Module 3

Interaction diagrams
• An Interaction Overview Diagram (IOD) is a type of UML (Unified Modeling
Language) diagram that illustrates the flow of interactions between various elements
in a system or process. It provides a high-level overview of how interactions occur,
including the sequence of actions, decisions, and interactions between different
components or objects.
• Interaction diagrams give a general overview of system behavior that stakeholders
can understand without getting bogged down in specifics.
• They help with requirements analysis, documentation, communication, and system
design. Overall, they enable stakeholders to comprehend complicated systems and
make educated decisions.
Notations for Interaction Diagram
1. Initial Node: Represents the starting point of the interaction. It is shown as a small
solid circle with a single outgoing control flow arrow.

2. Interaction Use: An Interaction Use is used to represent a reference to another

interaction or sequence of interactions defined in another diagram or part of the
system. An Interaction Use is represented by a rectangular box. Inside the box, you
can include a label that specifies the name or reference of the interaction being used.

Page | 8
Software Engineering – Module 3
3. Interaction Fragment: Interaction fragments are used to group and organize
interactions within the diagram.

4. Object Lifeline: Represents the lifespan of an object during the interaction. It is a

vertical dashed line that extends from the top of the diagram to the bottom, with the
object's name or class at the top.

5. Message: Represents communication between objects or components in the system.

Messages are shown as arrows between lifelines, indicating the direction of
communication.

6. Control Flow: Represents the flow of control or sequence of actions in the

interaction. It is shown as a solid arrow between elements in the diagram, indicating
the order in which actions are performed.

7. Fork Node/Join Node: Represents a point in the interaction where multiple parallel
actions can occur simultaneously. It is shown as a solid rectangle with multiple
outgoing control flow arrows in case of Fork Node and ingoing control flow arrows
in case of Join Node.

Page | 9
Software Engineering – Module 3
8. Decision Node: Represents a point in the interaction where a decision is made based
on a condition. It is shown as a small diamond shape with incoming and outgoing
control flow arrows representing different paths based on the decision.

9. Receive Signal Node: Represents the receipt of a signal or event during the
interaction. It is shown as a small rectangle with an incoming control flow arrow.

[Link] Node: Represents the ending point of the interaction. It is shown as a small
solid circle with no outgoing control flow arrows.

[Link]: Represents additional information or comments about the diagram. Notes are
shown as a small rectangle with a label indicating the content of the note.

Online shopping interaction diagram

Purpose: The goal is to provide an online shopping UML interaction overview diagram
example.
Summary: The consumer can explore or search the inventory, add or delete goods from their
cart, and complete the checkout process.

Page | 10
Software Engineering – Module 3
Sequence Diagram:
Sequence diagrams are a type of UML (Unified Modeling Language) diagram that visually
represent the interactions between objects or components in a system over time. They focus
on the order and timing of messages or events exchanged between different system elements.
The diagram captures how objects communicate with each other through a series of
messages, providing a clear view of the sequence of operations or processes.
Notations for Sequence Diagram
1. Actors: An actor in a UML diagram represents a type of role where it interacts with
the system and its objects. It is important to note here that an actor is always outside
the scope of the system we aim to model using the UML diagram.

2. Lifelines: A lifeline is a named element which depicts an individual participant in a

sequence diagram.

3. Messages: Communication between objects is depicted using messages. The

messages appear in a sequential order on the lifeline.
4. Call Message: A message defines a particular communication between Lifelines of
an Interaction. Call message is a kind of message that represents an invocation of
operation of target lifeline.

5. Return Message: A message defines a particular communication between Lifelines

of an Interaction. Return message is a kind of message that represents the pass of
information back to the caller of a corresponded former message.

Page | 11
Software Engineering – Module 3
6. Self Message: A message defines a particular communication between Lifelines of
an Interaction. Self message is a kind of message that represents the invocation of
message of the same lifeline.

7. Recursive Message: A message defines a particular communication between

Lifelines of an Interaction. Recursive message is a kind of message that represents
the invocation of message of the same lifeline. It's target points to an activation on
top of the activation where the message was invoked from.

8. Create Message: A message defines a particular communication between Lifelines

of an Interaction. Create message is a kind of message that represents the instantiation
of (target) lifeline.

9. Destroy Message: A message defines a particular communication between Lifelines

of an Interaction. Destroy message is a kind of message that represents the request of
destroying the lifecycle of target lifeline.

[Link] Message: A message defines a particular communication between Lifelines

of an Interaction. Duration message shows the distance between two time instants for
a message invocation.

Page | 12
Software Engineering – Module 3
How to create Sequence Diagrams?
Step 1: Identify the Scenario: Understand the specific scenario or use case that you want to
represent in the sequence diagram. This could be a specific interaction between objects or
the flow of messages in a particular process.
Step 2: List the Participants: Identify the participants (objects or actors) involved in the
scenario. Participants can be users, systems, or external entities.
Step 3: Define Lifelines: Draw a vertical dashed line for each participant, representing the
lifeline of each object over time. The lifeline represents the existence of an object during the
interaction.
Step 4: Arrange Lifelines: Position the lifelines horizontally in the order of their
involvement in the interaction. This helps in visualizing the flow of messages between
participants.
Step 5: Add Activation Bars: For each message, draw an activation bar on the lifeline of the
sending participant. The activation bar represents the duration of time during which the
participant is actively processing the message.
Step 6: Draw Messages: Use arrows to represent messages between participants. Messages
flow horizontally between lifelines, indicating the communication between objects.
Different types of messages include synchronous (solid arrow), asynchronous (dashed
arrow), and self-messages.
Step 7: Include Return Messages: If a participant sends a response message, draw a dashed
arrow returning to the original sender to represent the return message.
Step 8: Indicate Timing and Order: Use numbers to indicate the order of messages in the
sequence. You can also use vertical dashed lines to represent occurrences of events or the
passage of time.
Step 9: Include Conditions and Loops: Use combined fragments to represent conditions
(like if statements) and loops in the interaction. This adds complexity to the sequence
diagram and helps in detailing the control flow.
Step 10: Consider Parallel Execution: If there are parallel activities happening, represent
them by drawing parallel vertical dashed lines and placing the messages accordingly.

Page | 13
Software Engineering – Module 3
Step 11: Review and Refine: Review the sequence diagram for clarity and correctness.
Ensure that it accurately represents the intended interaction. Refine as needed.
Step 12: Add Annotations and Comments: Include any additional information, annotations,
or comments that provide context or clarification for elements in the diagram.
Step 13: Document Assumptions and Constraints: If there are any assumptions or
constraints related to the interaction, document them alongside the diagram.
Step 14: Tools: Use a UML modeling tool or diagramming software to create a neat and
professional-looking sequence diagram. These tools often provide features for easy editing,
collaboration, and documentation.
Example:

Structural Models:
• Structural models of software display the organization of a system in terms of the
components that make up that system and their relationships.
• Structural models may be static models, which show the structure of the system
design, or dynamic models, which show the organization of the system when it is
executing.
• UML class diagrams are used when developing an object-oriented system model to
show the classes in a 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 that indicates that there is some relationship
between these classes.

Page | 14
Software Engineering – Module 3
Class Diagram
Class diagrams are a type of UML (Unified Modeling Language) diagram used in software
engineering to visually represent the structure and relationships of classes within a system
i.e. used to construct and visualize object-oriented systems.
What is a class?
In object-oriented programming (OOP), a class is a blueprint or template for creating
objects. Objects are instances of classes, and each class defines a set of attributes (data
members) and methods (functions or procedures) that the objects created from that class will
possess. The attributes represent the characteristics or properties of the object, while the
methods define the behaviors or actions that the object can perform.
UML Class Notation
class notation is a graphical representation used to depict classes and their relationships in
object-oriented modeling.

1. Class Name: The name of the class is typically written in the top compartment of the
class box and is centered and bold.
2. Attributes: Attributes, also known as properties or fields, represent the data members
of the class. They are listed in the second compartment of the class box and often
include the visibility (e.g., public, private) and the data type of each attribute.
3. Methods: Methods, also known as functions or operations, represent the behavior or
functionality of the class. They are listed in the third compartment of the class box
and include the visibility (e.g., public, private), return type, and parameters of each
method.
4. Visibility Notation: Visibility notations indicate the access level of attributes and
methods. Common visibility notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)

Page | 15
Software Engineering – Module 3
o # for protected (visible to subclasses)
o ~ for package or default visibility (visible to classes in the same package)
Parameter Directionality
In class diagrams, parameter directionality refers to the indication of the flow of information
between classes through method parameters. It helps to specify whether a parameter is an
input, an output, or both. This information is crucial for understanding how data is passed
between objects during method calls.

There are three main parameter directionality notations used in class diagrams:
• In (Input):
• An input parameter is a parameter passed from the calling object (client) to the
called object (server) during a method invocation.
• It is represented by an arrow pointing towards the receiving class (the class that
owns the method).
• Out (Output):
• An output parameter is a parameter passed from the called object (server) back
to the calling object (client) after the method execution.
• It is represented by an arrow pointing away from the receiving class.
• InOut (Input and Output):
• An InOut parameter serves as both input and output. It carries information from
the calling object to the called object and vice versa.
• It is represented by an arrow pointing towards and away from the receiving
class.
Relationships between classes: In class diagrams, relationships between classes describe
how classes are connected or interact with each other within a system. There are several
types of relationships in object-oriented modeling, each serving a specific purpose.

Page | 16
Software Engineering – Module 3
1. Association
An association represents a bi-directional relationship between two classes. It indicates that
instances of one class are connected to instances of another class. Associations are typically
depicted as a solid line connecting the classes, with optional arrows indicating the direction
of the relationship.
Example: The "Library" class can be considered the source class because it contains a
reference to multiple instances of the "Book" class. The "Book" class would be considered
the target class because it belongs to a specific library.

2. Directed Association
A directed association in a UML class diagram represents a relationship between two classes
where the association has a direction, indicating that one class is associated with another in
a specific way.
• In a directed association, an arrowhead is added to the association line to indicate the
direction of the relationship. The arrow points from the class that initiates the
association to the class that is being targeted or affected by the association.
• Directed associations are used when the association has a specific flow or
directionality, such as indicating which class is responsible for initiating the
association or which class has a dependency on another.
Example: Consider a scenario where a "Teacher" class is associated with a "Course" class
in a university system. The directed association arrow may point from the "Teacher" class
to the "Course" class, indicating that a teacher is associated with or teaches a specific course.
• The source class is the "Teacher" class. The "Teacher" class initiates the association
by teaching a specific course.
• The target class is the "Course" class. The "Course" class is affected by the association
as it is being taught by a specific teacher.

Page | 17
Software Engineering – Module 3

3. Aggregation
Aggregation is a specialized form of association that represents a "whole-part"
relationship. It denotes a stronger relationship where one class (the whole) contains or is
composed of another class (the part). Aggregation is represented by a diamond shape on
the side of the whole class. In this kind of relationship, the child class can exist
independently of its parent class.
Example: The company can be considered as the whole, while the employees are the
parts. Employees belong to the company, and the company can have multiple employees.
However, if the company ceases to exist, the employees can still exist independently.

4. Composition
Composition is a stronger form of aggregation, indicating a more significant ownership
or dependency relationship. In composition, the part class cannot exist independently of
the whole class. Composition is represented by a filled diamond shape on the side of the
whole class.
Example: Imagine a digital contact book application. The contact book is the whole, and
each contact entry is a part. Each contact entry is fully owned and managed by the contact
book. If the contact book is deleted or destroyed, all associated contact entries are also
removed.

Page | 18
Software Engineering – Module 3

5. Generalization (Inheritance)
Inheritance represents an "is-a" relationship between classes, where one class (the
subclass or child) inherits the properties and behaviors of another class (the superclass
or parent). Inheritance is depicted by a solid line with a closed, hollow arrowhead
pointing from the subclass to the superclass.
Example: In the example of bank accounts, we can use generalization to represent
different types of accounts such as current accounts, savings accounts, and credit
accounts.

How to draw Class Diagrams

Drawing class diagrams involves visualizing the structure of a system, including classes,
their attributes, methods, and relationships. Here are the steps to draw class diagrams:
Step 1: Identify Classes: Start by identifying the classes in your system. A class represents
a blueprint for objects and should encapsulate related attributes and methods.
Step 2: List Attributes and Methods: For each class, list its attributes (properties, fields)
and methods (functions, operations). Include information such as data types and visibility
(public, private, protected).

Page | 19
Software Engineering – Module 3
Step 3: Identify Relationships: Determine the relationships between classes. Common
relationships include associations, aggregations, compositions, inheritance, and
dependencies. Understand the nature and multiplicity of these relationships.
Step 4: Create Class Boxes: Draw a rectangle (class box) for each class identified. Place
the class name in the top compartment of the box. Divide the box into compartments for
attributes and methods.
Step 5: Add Attributes and Methods: Inside each class box, list the attributes and methods
in their respective compartments. Use visibility notations (+ for public, - for private, # for
protected, ~ for package/default).
Step 6: Draw Relationships: Draw lines to represent relationships between classes. Use
arrows to indicate the direction of associations or dependencies. Different line types or
notations may be used for various relationships.
Step 7: Label Relationships: Label the relationships with multiplicity and role names if
needed. Multiplicity indicates the number of instances involved in the relationship, and role
names clarify the role of each class in the relationship.
Step 8: Review and Refine: Review your class diagram to ensure it accurately represents
the system's structure and relationships. Refine the diagram as needed based on feedback
and requirements.
Example:

Page | 20
Software Engineering – Module 3
Behavioral models:

➢ Behavioral models are models of the dynamic behavior of a system as it is executing.

➢ They show what happens or what is supposed to happen when a system responds to
a stimulus from its environment.
➢ Many business systems are data-processing systems that are primarily driven by data.
➢ They are controlled by the data input to the system, with relatively little external event
processing.

Two types of Behavioral models:

• Data-driven models: Some data arrives that has to be processed by the system.
• Event-driven models: Some event happens that triggers system processing. Events
may have associated data, although this is not always the case.

Data Driven Model:

• Data-driven models: show the sequence of actions involved in processing input data
and generating an associated output.
• They are particularly useful during the analysis of requirements as they can be used
to show
• end-to-end processing in a system.

Data-driven models can be created using UML activity or sequence diagrams:

Page | 21
Software Engineering – Module 3
Event-Driven Models:
• Event-driven models: 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
(stimuli) may cause a transition from one state to another.
• Real-time systems are often event-driven, with minimal data processing.
• For example, a landline phone switching system responds to events such as 'receiver
off hook' by generating a dial tone.

Event-driven models can be created using UML state diagrams:

Model-Driven Engineering:
• Model Driven Engineering (MDE) is a software development methodology that
focuses on creating and exploring domain models, which are conceptual models of
all topics related to a problem-specific domain.
• Model-driven engineering (MDE) is an iterative and incremental software
development process.
• Model-driven engineering (MDE) promotes the development of models at different
levels of abstraction.

Usage of model-driven engineering:

Model-driven engineering is still at an early stage of development, and it is unclear whether

or not it will have a significant effect on software engineering practice.
Page | 22
Software Engineering – Module 3
Pros
• Allows systems to be considered at higher levels of abstraction
• Generating code automatically means that it is cheaper to adapt systems to new
platforms.

Cons
• Models for abstraction and not necessarily right for implementation.
• Savings from generating code may be outweighed by the costs of developing
translators for new platforms.
Types of models:
MDA is a model-focused approach to software design and implementation that uses a subset
of UML models to describe a system.
➢ Computation independent model (CIM): These model the important domain
abstractions used in a system. CIMs are sometimes called domain models.
➢ Platform independent model (PIM): These model the operation of the system
without reference to its implementation. The PIM is usually described using UML
models that show the static system structure and how it responds to external and
internal events.
➢ Platform specific models (PSM): These are transformations of the platform-
independent model with a separate PSM for each application platform. In principle,
there may be layers of PSM, with each layer adding some platform-specific detail.

Page | 23