2.

System Modelling
System Modeling in Software Engineering
System modeling is an important activity in Software Engineering used to represent a system
visually. Models help developers and stakeholders understand, analyze, and design the system
before actual implementation. These models describe the structure, behavior, and interactions
within the system using diagrams.

Unified Modeling Language (UML) is a standardized modeling language used in Software

Engineering to visualize, specify, construct, and document software systems. It provides a set
of graphical notations (diagrams) to represent both the structure and behavior of a system.
UML is not a programming language; it is a design and communication tool. It helps
developers, designers, and stakeholders understand the system clearly before implementation.

Introduction
System modeling is the process of developing abstract representations (models) of a system
to understand, analyze, and design it effectively.
 It helps in visualizing system structure and behavior
 Used during requirement analysis and system design
 Models simplify complex systems
Why System Modeling is Important
 Helps in better understanding of system requirements
 Improves communication between stakeholders
 Identifies errors early
  Provides documentation for future reference
 Supports system design and development
Types of System Models

1) Context Models
Context diagrams serve as a foundational tool, helping designers and stakeholders grasp the
scope and boundaries of a system under consideration. These diagrams provide a high-level
view, illustrating how the system interacts with external entities and the environment.

What are Context Diagrams?

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.
They provide a big-picture view of how the system fits into its environment without diving
into the internal details of the system itself.
 Typically, they consist of a central system surrounded by external entities, with arrows
representing data flow or interactions between them.
 They're useful for understanding system boundaries and dependencies.
Importance of Context Diagrams in Systems Analysis
 Scope Definition:
Context diagrams define the system's boundaries by highlighting its interactions with
external entities, ensuring that the analysis focuses on pertinent components and
processes.
 Requirement Gathering: These diagrams visualize how the system interacts with its
environment, aiding in identifying both functional and non-functional requirements.
They offer clarity on the system's objectives and its external interactions.
 Communication: Acting as a bridge between stakeholders, such as business users,
developers, and project managers, context diagrams foster shared understanding of the
system's scope and context. They streamline discussions and decision-making
throughout the development process.
 Risk Identification: Context diagrams assist in spotting potential risks stemming
from the system's interactions with external entities. They help stakeholders assess the
implications of external factors on the system's performance, security, and reliability.
Components of Context Diagrams
1. System/Product:
This is the primary focus of the diagram, representing the system being analyzed or designed.
2. External Entities
These are entities outside the system boundary that interact with the system. They could be
users, other systems, or processes that provide input to or receive output from the system.

3. Data Flow
These are arrows representing the flow of data or information between the system and
external entities. They illustrate the exchange of data between the system and its
environment.
1. Unidirectional Data Flow
Unidirectional data flow indicates that data moves in only one direction between two
components. For example, data flows from an external entity to a process, or from a process
to a data store, but not in the opposite direction. This type of data flow is represented by a
single arrow indicating the direction of data movement.
2. Bidirectional Data Flow
Bidirectional data flow indicates that data can move in both directions between two
components. For example, data flows between a process and an external entity can be
bidirectional, allowing the process to send data to the external entity and receive data back.
This type of data flow is represented by a double-headed arrow indicating that data can move
in both directions.

Different Types of Relationships and Interactions in Context Diagrams

Below are the different types of relationships and interactions in Context Diagram:
 Input/Output Relationships:
o Input: Data or information flowing into the system from external entities.

o Output: Data or information flowing out of the system to external entities.

 Control Relationships:
o Control: External entities influencing or directing the system's behavior or
processes.
 o Controlled by: The system may be subject to control or influence by external
entities.
 Mechanism Relationships:
o Mechanism: Describes how the system operates or responds to external
stimuli or events.
o Trigger: External events prompting the system to execute specific actions or
behaviors.
Steps to create a Context Diagram
Below are the steps of how to draw Context Diagram:

 Step1: Define the System: Start by clearly defining the system you're analyzing or
designing, outlining its boundaries and objectives.
 Step2: Identify External Entities: Recognize all external entities that interact with
the system, including users, other systems, or processes that exchange data with it.
 Step3: View the Data Flows: Determine how data flows between the system and
external entities, specifying the types of data and their direction (input or output).
 Step4: Sketch the Diagram: Utilize standardized symbols and notation to create the
context diagram. Position the system at the center and surround it with external
entities, using arrows to depict data flow.
 Step5: Label the Components: Ensure each element of the diagram is clearly
labeled, including the system, external entities, and data flows, providing concise
descriptions for clarity.
 Step6: Review and Verify: Collaborate with stakeholders to review the context
diagram, confirming its accuracy and completeness in representing the system's
interactions.
  Step7: Maintain Stage: Regularly update the diagram to reflect changes in the
system or its external environment, ensuring it remains an accurate depiction of the
system's context.
Benefits of using Context Diagram
Below are the benefits of using Context Diagram:
 Clarity: Context diagrams offer a straightforward and clear snapshot of how the
system interacts with its surroundings, aiding stakeholders in grasping its scope and
context with ease.
 Communication: Serving as effective communication aids, these diagrams
streamline discussions and decision-making among stakeholders, fostering
collaboration between business users, developers, and project managers.
 Scope Definition: By delineating the system's boundaries and external entities,
context diagrams assist in defining the project's scope, ensuring that efforts are
focused on pertinent components and processes.
 Dependency Management: Understanding the system's relationships with external
entities facilitates the management of dependencies, empowering stakeholders to
anticipate and prepare for potential impacts of external changes.
 Risk Identification: Context diagrams help pinpoint potential risks stemming from
the system's interactions with external elements, empowering stakeholders to identify,
assess, and mitigate risks effectively.

Tools Used in Context Modelling [Simply Read]

 Microsoft Visio is widely used to create context diagrams and data flow diagrams. It
provides ready-made templates and shapes that help in representing system
boundaries and external entities in a clear and structured way.
 Lucidchart is a web-based tool that allows easy creation of context diagrams using
drag-and-drop features. It supports collaboration, making it useful for teams working
on system analysis.
 [Link] is a free and open-source tool used to design context models and diagrams. It
is simple and widely used by students for academic projects.
 Creately helps in creating context diagrams with real-time collaboration. It provides
templates specifically for system modeling.
 Visual Paradigm is an advanced modeling tool that supports context modeling along
with UML diagrams. It is useful for detailed system analysis and design.
 Edraw Max provides various templates for context diagrams, data flow diagrams,
and system models, making diagram creation quick and efficient.
 SmartDraw is another tool that automatically formats diagrams and is used to create
professional context models easily.
 Gliffy is a simple browser-based tool used for drawing context diagrams and system
interaction diagrams.
 Enterprise Architect is used in large-scale projects to create detailed system models,
including context diagrams, with advanced features like requirement management.
  PlantUML allows users to create context diagrams using text-based scripts, which is
useful for developers who prefer coding approaches.

Challenges of using Context Diagram

Below are the challenges of using Context Diagram:
 Scope Creep: Maintaining focus on relevant external entities and interactions can be
challenging amidst attempts to expand the diagram's scope beyond necessity.
 Complexity Management: Diagrams for intricate systems may become convoluted,
making it difficult to sustain simplicity and clarity.
 Accuracy: Ensuring the diagram faithfully represents the system's interactions
demands rigorous analysis and validation, which can consume significant time and
resources.
 Dependency Identification: Understanding dynamic dependencies between the
system and external entities poses a challenge, especially in environments where
dependencies frequently change.
 Consensus Building: Reaching agreement among stakeholders on the diagram's
content and representation proves challenging, particularly when differing
perspectives and priorities come into play.
 Maintenance: Keeping diagrams current as systems evolve and external factors shift
demands ongoing effort and coordination among stakeholders.

2) Interaction Model:
Interaction Overview Diagrams (IODs) in UML (Unified Modeling Language) provide a

high-level view of the interactions between various components or objects in a system. They

are used to visualize the flow of control and interactions within a system, showing how

different parts of the system communicate and collaborate to achieve a specific goal.

What are Interaction Overview 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 Overview Diagram

Annotations and explanations from the Interaction Overview UML diagrams feature several

fundamental components that help to show control flow and system interactions. Here's a

detailed explanation of these notations:

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 [Link] 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.

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.
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.
10. Final Node
Represents the ending point of the interaction. It is shown as a small solid circle with no
outgoing control flow arrows.

11. Note
Represents additional information or comments about the diagram. Notes are shown as a
small rectangle with a label indicating the content of the note.
Example of Interaction Overview Diagram
1. Online shopping interaction overview diagram
Let's understand interaction overview diagram using an example of online shopping system:
Think about an internet-based shopping platform. The flow of control between different
interactions, including logging in, viewing products, adding items to the basket, and checking
out, may be displayed in the interaction overview diagram. While fragments might depict
concurrent operations like managing inventory updates and creating invoices, decision nodes
could stand in for activities like selecting payment options.
 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.
Benefits of Interaction Overview Diagram
 Clarity and Comprehension: By providing a clear visual representation of the
control flow of the system, these diagrams help stakeholders quickly grasp
complicated systems.
 Simplification: Simplifying complicated systems by displaying interactions at a
higher level helps stakeholders understand them better and lessens their cognitive
burden.
 Effective Communication: Overview of Interactions in Effective Communication
Diagrams improve collaboration and alignment among stakeholders by offering a
comprehensive understanding of system behavior.
 Analysis and Optimization: By allowing analysts to spot faults, inefficiencies, or
bottlenecks in the control flow, they can help stakeholders maximize the dependability
and performance of the system.
 Support for Design Decisions: By giving a high-level overview of system behavior
and dependencies, these diagrams help with well-informed design and architecture
decisions.
 Change Management: Overview of Interaction Diagrams enhance effective change
management by assisting in anticipating the effects of changes to the system's control
flow and reducing risks during updates or revisions.
Use Case Diagram - Unified Modeling Language (UML)
A Use Case Diagram is a visual way to show how users (actors) interact with a system and
what functions (use cases) the system provides. It helps understand the system’s behavior
from the user’s perspective.
 Represents actors (users or external systems) and use cases (system functionalities).
 Shows the relationships between users and system features.
 Helps define system scope, requirements, and interactions clearly.
Use Case Diagram in UML
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.

When to apply Use Case Diagram?

Use case diagrams are useful in several situations. Here’s when you should consider using
them:
 When you need to gather and clarify user requirements, use case diagrams help
visualize how different users interact with the system.
 If you’re working with diverse groups, including non-technical stakeholders, these
diagrams provide a clear and simple way to convey system functionality.
 During the system design phase, use case diagrams help outline user interactions and
plan features, ensuring that the design aligns with user needs.
 When defining what is included in the system versus what is external, use case
diagrams help clarify these boundaries.
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.
(A use case describes what a user wants to do with a system,
product, or idea.)

Examples:
 For a mobile app:
Use case → “A user logs in to check their messages.”
 For a car:
Use case → “Driving to work every day.”
 For software development:
A use case shows step-by-step how a user interacts with the system to achieve a
goal.
👉 Use case = a real-life example of how something is used to achieve a goal

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 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.
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.
Use Case Diagram Relationships
In a Use Case Diagram, relationships play a crucial role in depicting the interactions between
actors and use cases.
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
 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."
Draw a Use Case diagram in UML
Below are the main steps to draw 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)
Let's understand how to draw a Use Case diagram with the help of an Online Shopping
System:
 Actors
 Customer
Use Cases
 Browse Products
 Add to Cart
 Checkout
 Manage Inventory (Admin)
Relations
 The Customer can browse products, add items to the cart, and complete the checkout.
 The Admin can manage the inventory
Below is the use case diagram of an Online Shopping System:
Sequence Diagrams - Unified Modeling Language (UML)
A Sequence Diagram is a key component of Unified Modeling Language (UML) used to
visualize the interaction between objects in a sequential order. They focus on the order and
timing of messages or events exchanged between different system elements.
A sequence diagram shows how objects interact with each other over time in a system. It
helps visualize the order of messages and operations between objects.
 Illustrates interactions and message flows between objects
 Shows the sequence of operations over time
 Helps understand use cases, design system architecture, and document processes
Use of Sequence Diagrams
Sequence diagrams are used because they offer a clear and detailed visualization of the
interactions between objects or components in a system, focusing on the order and timing of
these interactions. Here are some key reasons for using sequence diagrams:
 Visualizing Dynamic Behaviour: Sequence diagrams depict how objects or systems
interact with each other in a sequential manner, making it easier to understand
dynamic processes and workflows.
 Clear Communication: They provide an intuitive way to convey system behavior,
helping teams understand complex interactions without diving into code.
 Use Case Analysis: Sequence diagrams are useful for analyzing and representing use
cases, making it clear how specific processes are executed within a system.
 Designing System Architecture: They assist in defining how various components or
services in a system communicate, which is essential for designing complex,
distributed systems or service-oriented architectures.
  Documenting System Behavior: Sequence diagrams provide an effective way to
document how different parts of a system work together, which can be useful for both
developers and maintenance teams.
 Debugging and Troubleshooting: By modeling the sequence of interactions, they
help identify potential bottlenecks, inefficiencies, or errors in system processes.

Sequence Diagram Notations

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.

We use actors to depict various roles including human users and other external subjects. We
represent an actor in a UML diagram using a stick person notation. We can have multiple
actors in a sequence diagram.
For example:
Here the user in seat reservation system is shown as an actor where it exists outside the
system and is not a part of the system.
2. Lifelines
A lifeline is a named element which depicts an individual participant in a sequence diagram.
So basically, each instance in a sequence diagram is represented by a lifeline. Lifeline
elements are located at the top in a sequence diagram. The standard in UML for naming a
lifeline follows the following format:

We display a lifeline in a rectangle called head with its name and type. The head is located on
top of a vertical dashed line (referred to as the stem) as shown above.
3. Messages
Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline.
 We represent messages using arrows.
 Lifelines and messages form the core of a sequence diagram.

Messages can be broadly classified into the following categories:

1. Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The sender
waits until the receiver has completed the processing of the message. The caller continues
only when it knows that the receiver has processed the previous message i.e. it receives a
reply message.
  A large number of calls in object oriented programming are synchronous.
 We use a solid arrow head to represent a synchronous message.

2. Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction moves
forward irrespective of the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.
4. Create message
We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is represented
with a dotted arrow and create word labelled on it to specify that it is the create Message
symbol.
For example:
The creation of a new order on a e-commerce website would require a new object of Order
class to be created.
5. Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system, we use the Delete Message symbol. It destroys the occurrence of
the object in the system. It is represented by an arrow terminating with a x.
For example:
In the scenario below when the order is received by the user, the object of order class can be
destroyed.

6. Self-Message
Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U-shaped arrow.
7. Reply Message
Reply messages are used to show the message being sent from the receiver to the sender. We
represent a return/reply message using an open arrow head with a dotted line. The interaction
moves forward only when a reply message is sent by the receiver.

8. Found Message
A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an end point.
9. Lost Message
A Lost message is used to represent a scenario where the recipient is not known to the
system. It is represented using an arrow directed towards an end point from a lifeline.
10. Guards
To model conditions, we use guards in UML. They are used when we need to restrict the flow
of messages on the pretext of a condition being met. Guards play an important role in letting
software developers know the constraints attached to a system or a particular process.

Structural Models:
Complex applications need collaboration and planning from multiple teams and hence require
a clear and concise way to communicate amongst them. So UML becomes essential to
communicate with non-programmers about essential requirements, functionalities, and
processes of the system. UML is linked with object-oriented design and analysis. UML
makes use of elements and forms associations between them to form diagrams.
UML Class Diagram
A UML class diagram shows the structure of a system by displaying its classes, their
attributes, methods, and the relationships between them. It helps the team understand how the
system is organized and how components interact.
 Represents classes, attributes, methods, and relationships
 Helps communicate and document the software structure
 Makes it easier for developers and designers to understand the system

UML Class Notation

Classes are depicted as boxes, each containing three compartments for the class name,
attributes, and methods.
 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:
 + for public (visible to all classes)
 - for private (visible only within the class)
 # for protected (visible to subclasses)
 ~ 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)
 A parameter sent from the caller to the method being executed.
Out (Output)
 A parameter sent from the method back to the caller after execution.
InOut (Input and Output)
 A parameter that is sent to the method and also returns back to the caller.
Relationships between classes
In class diagrams, relationships between classes describe how classes are connected or
interact with each other within a system. Here are some common types of relationships in
class diagrams:
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.
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.
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.
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.
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.
6. Realization (Interface Implementation)
Realization indicates that a class implements the features of an interface. It is often used in
cases where a class realizes the operations defined by an interface. Realization is depicted by
a dashed line with an open arrowhead pointing from the implementing class to the interface.
7. Dependency Relationship
A dependency exists between two classes when one class relies on another, but the
relationship is not as strong as association or inheritance. It represents a more loosely coupled
connection between classes.
8. Usage (Dependency) Relationship
A usage dependency relationship in a UML class diagram indicates that one class (the client)
utilizes or depends on another class (the supplier) to perform certain tasks or access certain
functionality. The client class relies on the services provided by the supplier class but does
not own or create instances of it.
 In UML class diagrams, usage dependencies are typically represented by a dashed
arrowed line pointing from the client class to the supplier class.
 The arrow indicates the direction of the dependency, showing that the client class
depends on the services provided by the supplier class.
Purpose of Class Diagrams
The main purpose of using class diagrams is:
 This is the only UML that can appropriately depict various aspects of the OOPs
concept.
 Proper design and analysis of applications can be faster and efficient.
 It is the base for deployment and component diagram.
 It incorporates forward and reverse engineering.
Benefits of Class Diagrams
Below are the benefits of class diagrams:
 Class diagrams represent the system's classes, attributes, methods, and relationships,
providing a clear view of its architecture.
 They shows various relationships between classes, such as associations and
inheritance, helping stakeholders understand component connectivity.
 Class diagrams serve as a visual tool for communication among team members and
stakeholders, bridging gaps between technical and non-technical audiences.
  They guide developers in coding by illustrating the design, ensuring consistency
between the design and actual implementation.
 Many development tools allow for code generation from class diagrams, reducing
manual errors and saving time.

Benefits of using Structural UML diagrams

Structural diagrams are like visual guides that help everyone on a software team see how the
different parts of a program fit together. They make planning, building, and fixing things
much easier.
 Clear Picture for Everyone:
o Structural UML diagrams are like visual maps that show how different parts of
a computer program or system are connected.
o It's a clear picture that helps everyone understand how things fit together.

 Helps Design and Plan:

o These diagrams are like blueprints for building a house.

o They help the people designing the software see how different pieces will
work together.
 Easy to Explain and Share:
o Structural diagrams make it easy to explain how a computer program works
and share ideas with the team.
 Keeps Things Organized:
o These diagrams help organize the different parts of a computer program.

o It keeps everything in order, making it easier to understand and update.

 Saves Time and Fixes Problems Early:

o Before building something big, like a bridge, engineers use drawings to catch
any problems early. Structural diagrams do the same for computer programs.
o They help find and fix issues before spending lots of time writing the actual
code.
Challenges faced in developing Structural UML diagrams
 Abstraction Complexity:
o Abstracting complex systems into simplified diagrams can be challenging.
 o Representing complicated relationships and dependencies between classes or
components may lead to reduced clarity.
 Maintaining Consistency with Code:
o Ensuring that UML diagrams remain consistent with the actual codebase over
time can be challenging.
o Code changes may not always be reflected in the diagrams, leading to
discrepancies.
 Choosing the Right Level of Detail:
o Striking the right balance between providing sufficient detail and avoiding
overwhelming complexity is a common challenge.
o Including too much detail can hinder readability, while too little may lead to
ambiguity.
 Expressing Dynamic Aspects in a Static Diagram:
o Structural diagrams are inherently static, making it challenging to represent
dynamic aspects such as behavior or state transitions.
o Capturing dynamic behavior may require additional diagrams like behavior
diagrams.
 Handling Change Management:
o Structural diagrams may need frequent updates to reflect changes in the
system. Managing and communicating these changes effectively can be
challenging, especially in large projects.
 Balancing Simplicity and Completeness:
o Striking a balance between simplicity and completeness is crucial.

o Over-simplified diagrams may lack necessary details, while overly detailed

diagrams may become overwhelming.
 Ensuring Consistent Notation:
o Inconsistent use of notation and symbols across diagrams can lead to
confusion. Different team members may interpret symbols differently,
affecting the overall understanding.
 Tooling and Accessibility:
o Different team members might be familiar with different tools, and not all
team members may have easy access to specialized UML tools.
Generalization, Specialization and Aggregation in ER Model:

Using the ER model for larger datasets creates a lot of complexity when designing a
database model. To minimize the complexity, Generalization, Specialization, and
Aggregation were introduced in the ER model. These were used for data abstraction. In
which an abstraction

mechanism is used to hide the details of a set of objects.

Generalization
Process of extracting common properties from a set of entities and creating a generalized
entity from it. It is a bottom-up approach in which two or more entities can be generalized
to a higher-level entity if they have some attributes in common.

Fig: Generalization
Example: STUDENT and FACULTY can be generalized to a higher-level entity called
PERSON as shown in diagram below. In this case, common attributes like P_NAME and
P_ADD become part of a higher entity (PERSON) and specialized attributes like S_FEE
become part of a specialized entity (STUDENT).
Specialization
In specialization, an entity is divided into sub-entities based on its characteristics. It is a top-
down approach where the higher-level entity is specialized into two or more lower-
level entities.
 Fig: Specialization

Aggregation
 An ER diagram is not capable of representing the relationship between an entity and a
relationship which may be required in some scenarios.
 In those cases, a relationship with its corresponding entities is aggregated into a
higher-level entity.
 Aggregation is an abstraction through which we can represent relationships as higher-

level entity sets.

Example: an Employee working on a project may require some machinery. So, REQUIRE
relationship is needed between the relationship WORKS_FOR and entity MACHINERY.
Using aggregation, WORKS_FOR relationship with its entities EMPLOYEE and PROJECT
is aggregated into a single entity and relationship REQUIRE is created between the
aggregated entity and MACHINERY.

Representing Aggregation Via Schema

To represent aggregation in a relational schema, follow these steps:
1. Create Schema for the Aggregated Relationship
 This will be treated like an entity set.
 It includes the primary keys of the participating entities in the base relationship.
 It also includes any descriptive attributes of the base relationship.
2. Create Schema for the Higher-Level Relationship (Aggregation)
 This schema includes: The primary key of the aggregated relationship schema.
 The primary key of the associated entity it relates to.
 Any additional descriptive attributes of this higher-level relationship.

Behavioural Model:
Overall behavior of a system can be fully understood by Behavioral model. Behavioral
Model is specially designed to make us understand behavior and factors that influence
behavior of a System. Behavior of a system is explained and represented with the help of a
diagram. This diagram is known as State Transition Diagram. It is a collection of states and
events. It usually describes overall states that a system can have and events which are
responsible for a change in state of a system. So, on some occurrence of a particular event, an
action is taken and what action needs to be taken is represented by State Transition Diagram.
Example : Consider an Elevator. This elevator is for n number of floors and has n number of
buttons one for each floor. Elevator’s working can be explained as follows :
1. Elevator buttons are type of set of buttons which is there on elevator. For reaching a
particular floor you want to visit, “elevator buttons” for that particular floor is
pressed. Pressing, will cause illumination and elevator will start moving towards that
particular floor for which you pressed “elevator buttons”. As soon as elevator reaches
that particular floor, illumination gets canceled.
2. Floor buttons are another type of set of buttons on elevator. If a person is on a
particular floor and he wants to go on another floor, then elevator button for that floor
is pressed. Then, process will be same as given above. Pressing, will cause
illumination and elevator to start moving, and when it reaches on desired floor,
illumination gets cancelled.
3. When there is no request for elevator, it remains closed on current floor.
State Transition Diagram for an elevator system is shown below –

Advantages :
 Behavior and working of a system can easily be understood without any effort.
 Results are more accurate by using this model.
 This model requires less cost for development as cost of resources can be minimal.
 It focuses on behavior of a system rather than theories.
 Disadvantages :
 This model does not have any theory, so trainee is not able to fully understand basic
principle and major concept of modeling.
 This modeling cannot be fully automated.
 Sometimes, it's not easy to understand overall result.
 Does not achieve maximum productivity due to some technical issues or any errors.
Data Driven Modelling:

Data-driven modelling in software engineering is a behavioural modelling approach that

focuses on how data flows through a system and how it is processed to produce meaningful
output. In this approach, the system is viewed as a collection of processes that take input data,
perform operations, and generate output. It helps in understanding system functionality by
emphasizing the movement and transformation of data rather than control logic. This
modelling technique is widely used during system analysis and design to identify
requirements, improve efficiency, and ensure proper data handling.

The most commonly used diagram in data-driven modelling is the Data Flow Diagram
(DFD). A DFD visually represents how data enters the system, gets processed, stored, and
leaves the system. It consists of four main components: processes (which transform data),
data flows (which show movement of data), data stores (which store data), and external
entities (which act as sources or destinations of data). DFDs are developed in different levels,
such as Level 0 (context diagram), Level 1, and Level 2, to provide increasing levels of detail
about the system.
 Fig: Data Driven Modelling
Event-Driven Modelling:
Event-driven modelling is a behavioral modelling approach in software engineering that
describes how a system reacts to different events. An event is any occurrence that triggers a
change in the state of a system, such as a user action, sensor input, or message from another
system. This approach focuses on identifying events, the conditions under which they occur,
and the corresponding system responses. It is widely used in designing interactive and real-
time systems where actions depend on external or internal triggers.

In event-driven modelling, the system is represented in terms of states, events, and

transitions. A system remains in a particular state until an event occurs, which causes it to
transition to another state. The most commonly used diagram for this modelling is the State
Machine Diagram (State Diagram) in UML. This diagram shows different states of the
system, transitions between states, and events that trigger these transitions. Each transition
may also include actions that the system performs in response to an event.
Model-Driven Engineering:

Model-Driven Engineering (MDE) is a software development approach that focuses on

creating and using models as the primary elements in the development process. Instead of
writing code directly, developers first design abstract representations (models) of the system,
which are later transformed into executable code. This approach helps in improving
productivity, reducing errors, and simplifying complex system development.

In MDE, models are created at different levels of abstraction. The most common types
include Computation Independent Model (CIM), Platform Independent Model (PIM),
and Platform Dependent Model (PDM). The CIM represents the system without technical
details and focuses on business requirements. The PIM describes system functionality
without considering the platform, while the PDM includes platform-specific details such as
programming language or database. These models are systematically transformed from one
level to another using automated tools.
Questions

1. Explain Context Models in software engineering. Draw a context diagram and discuss
its importance.

2. What are Interaction Models? Explain with types such as use-case diagrams and
sequence diagrams.

3. Explain Use Case Modeling with a suitable example. Draw a use case diagram and
describe its elements.
4. What is Sequence Modeling? Explain sequence diagrams with an example and
message flow.

5. Explain Structural Modeling. Draw and explain a Class Diagram with relationships.
6. What is Generalization and Aggregation in UML? Explain with examples and
diagrams.
7. Explain Behavioral Modeling in software engineering. Differentiate between data-
driven and event-driven modeling.
8. What is Data-Driven Modeling? Explain Data Flow Diagrams (DFD) with levels and
examples.
9. Explain Event-Driven Modeling with state diagrams and examples.
10. What is Model-Driven Engineering (MDE)? Explain its concepts, advantages, and
applications in software development.