Software Modeling

UNIT : 04
 Introduction
“Software Modeling is the designing of software
applications before coding”.

“ Software modeling involves creating representation of

software systems to analyze, design, and visualize their
architecture, components and behavior”

“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 may represent a system using graphical

notation e.g DFD, ERD, UML etc.
 Types of Software Modeling
1. Structural Modeling: Represents software structure ,
also called static modeling

2. Behavioral Modeling : Describe software behavior,

also called dynamic modeling

3. Functional Modeling : Focuses on software

functionality using Data flow diagram(DFD)

Techniques:
1. Data Flow Diagram (DFD)
2. Entity Relationship Diagram (ERD)
3. Unified Modeling Language(UML)
 Principles of Modeling
1. Model the essentials: Good models do not represent every minor
feature for all scenarios. Modeling involves the most salient aspects
needed to address the specific issues or questions. Trivial details are
abstracted away to keep the model understandable. This focuses on
key characteristics for informed decision making.

2. Provide perspective: Modeling constructs different views using

defined rules to express each within the chosen modeling language
and tools. For example, models may provide structural, behavioral,
temporal or organizational views. Organizing into separate views
focuses on modeling for each view on specific concerns.

3. Enable effective communication: Diligent and uniform modeling

facilitates straightforward conveying software information to
stakeholders. Careful use of domain terminology and modeling
language semantics enables articulation in a familiar vocabulary.
Strict syntactic and semantic adherence also improves expression.
Explicit notation contributes to communicative models, while
modeling pragmatics helps share unambiguous meaning.
 Properties of Software Models
1. Completeness: This property conveys the degree to which all
specified requirements, features, and elements have been fully
implemented and sufficiently verified or validated within the model
representation of the software. A complete model incorporates all
the relevant requirements exhaustively.

2. Consistency: This characteristic demonstrates the degree to which

the software model contains no contradictory, conflicting, or
mutually exclusive requirements, assertions, constraints, functions,
behaviors, or component descriptions. A consistent model is one in
which all parts are cohesive and compatible

3. Correctness: This attribute expresses the degree to which the

software model accurately satisfies and implements all specified
software requirements and design specifications. A correct model is
free of any defects and misrepresentations, and ultimately meets
the needs of its stakeholders as intended.
 Benefits of Software Modeling
1. Improved communication among
stakeholders
2. Enhanced system understanding
3. Early detection of errors
4. Reduced development time
5. Increased maintainability
6. Better scalability
 Analysis Modeling
• An analysis model is a technical representation of a
system's structure, functions, and behaviors

• It's used to describe the requirements of a customer and to

establish a way to create the software design

• It acts as a link between the system description and the

design model.

• In Analysis Modeling, information, behavior, and functions

of the system are defined and translated into the
architecture, component, and interface level design in the
design modeling.
 Types of Analysis Modeling
1. Functional Models: Describe what system does
e.g Data flow diagram (DFD)
2. Object Oriented Models: Represents system
components and relationship e.g class diagram
3. Dynamic models: Describe system behaviors e.g
use case diagram
4. Data models: Represents systems data structure
e.g entity relationship diagram (ERD)
 Techniques of Analysis Modeling
1. Use case diagram: Identify system interactions
2. Class diagram: Define system components and
their relationship
3. Sequence diagram: Describe system behavior
over the period of time
4. State machine diagram: Model overall system
behavior
5. Activity diagram: Describe system workflows
6. Data flow diagram: Represents system data flow
7. Entity relationship diagram : Model system data
structure
 Benefits of Analysis Modeling

1. Clarifies system requirements

2. Identifies potential issues
3. Enhance communication among stakeholders
4. Reduces development time
5. Improves system maintainability
 Data Modeling
Data modeling is the process of creating a visual representation of either a
whole information system or parts of it to communicate connections between
data points and structures.
 Types of Data Model
1. Conceptual data model.
• This is a high-level visualization of the business or
analytics processes that a system supports.

• It maps out the kinds of data that are needed, how

different business entities interrelate and associated
business rules.

• Business executives are the main audience for

conceptual data models, which help them see how a
system works and ensure that it meets business needs.

• Conceptual models aren't tied to specific databases or

application technologies.
 Types of Data Models
2. Logical data model.
Once a conceptual data model is done, it can be used to
create a less abstract logical one.

Logical data models show how data entities are related

and describe the data from a technical perspective.

For example, they define data structures and provide

details on attributes, keys, data types and other
characteristics.

Logical data models are used in specific projects, as they

create a technical plot of data structures and rules.
 Types of Data Model
3. Physical data model.
• A logical model serves as the basis for the creation of a physical
data model.

• It describes how data is stored in a physical database. Physical

models are specific to the database management system (DBMS) or
application software that will be implemented.

• They define the structures that the database or a file system use to
store and manage the data.

• That includes tables, columns, fields, indexes, constraints, triggers

and other DBMS elements.

• Database designers use physical data sources to create designs and

generate schema for databases.
 Techniques of Data Modeling
1. Hierarchical Data Model : Hierarchical data models organize data in a
treelike arrangement of parent and child records.

2. Network Data Models: expanded on hierarchical ones by allowing

child records to be connected to multiple parent records. This model
enables node relationships to be connected in a many-to-many
format.

3. Relational Data Models: The relational data model was created as a

more flexible alternative to hierarchical and network ones.

4. Entity Relationship Model : A variation of the relational model that

can also be used with other types of databases, ER models visually
map entities, their attributes and the relationships between different
entities.
5. Dimensional Data Modeling: Dimensional data models are primarily
used in data warehouses and data marts that support BI applications.
They were designed to improve data retrieval speeds for analytics.
 Techniques for Data Modeling
6. The object-oriented approach: It is similar to the
ER method in how it represents data, attributes and
relationships, but it abstracts entities into objects.
Different objects that have the same attributes and
behaviors can be grouped into classes, and new
classes can inherit the attributes and behaviors of
existing ones.

7. Graph Modeling :The graph data model is a more

modern offshoot of network and hierarchical
models. Typically paired with graph databases, it's
often used to describe data sets that contain
complex relationships.
 Benefits of Data Modeling
1. Improved data consistency and quality

2. Enhanced data sharing and integration

3. Better data governance and compliance

4. Increased data security

5. Optimized database performance

Example of Data Modeling
 Data Flow Diagram (DFD)
• Data Flow Diagrams (DFD) provide a graphical
representation of the data flow of a system that can
be understood by both technical and non-technical
users.

• The models enable software engineers, customers,

and users to work together effectively during the
analysis and specification of requirements.

• It is not a Flow chart

 Levels in Data Flow Diagram
DFDs can be divided into different levels, which provide varying
degrees of detail about the system. The following are the four levels of
DFDs:
• Level 0 DFD
• Level 1 DFD
• Level 2 DFD
• Level 3 DFD

The choice of DFD level depends on the complexity of the system and
the level of detail required to understand the system.

Higher levels of DFD provide a broad overview of the system, while

lower levels provide more detail about the system’s processes, data
flows, and data stores.

A combination of different levels of DFD can provide a complete

understanding of the system.
 Level: 0 DFD

Level 0 is the highest-level Data Flow Diagram (DFD), which provides an

overview of the entire system.

It is also known as a context diagram.

It’s designed to be an abstraction view, showing the system as a single

process with its relationship to external entities.

It represents the entire system as a single bubble with input and output
data indicated by incoming/outgoing arrows.
 Level : 1 DFD

1-Level provides a more detailed view of the system by breaking down the
major processes identified in the level 0 Data Flow Diagram (DFD) into sub-
processes.
Each sub-process is depicted as a separate process on the level 1 Data Flow
Diagram (DFD).

In level -1 Data Flow Diagram (DFD), the context diagram is decomposed

into multiple bubbles/processes.
 Level: 2 DFD

Level 2 provides an even more detailed view of the system by breaking

down the sub-processes identified in the level 1 Data Flow Diagram (DFD)
into further sub-processes.
Each sub-process is depicted as a separate process on the level 2 DFD.
2-Level Data Flow Diagram (DFD) goes one step deeper into parts of level 1
DFD.
It can be used to plan or record the specific/necessary detail about the
system’s functioning.
 Level: 3 DFD
Level 3 is the most detailed level of Data Flow
Diagram (DFDs), which provides a detailed view of the
processes, data flows, and data stores in the system.

This level is typically used for complex systems, where

a high level of detail is required to understand the
system.

Each process on the level 3 DFD is depicted with a

detailed description of its input, processing, and
output.
 Advantages of DFD
• Easy to understand: DFDs are graphical representations that are easy to
understand and communicate, making them useful for non-technical
stakeholders and team members.

• Improves system analysis: DFDs are useful for analyzing a system’s

processes and data flow, which can help identify inefficiencies,
redundancies, and other problems that may exist in the system.

• Supports system design: DFDs can be used to design a system’s architecture

and structure, which can help ensure that the system is designed to meet
the requirements of the stakeholders.

• Enables testing and verification: DFDs can be used to identify the inputs and
outputs of a system, which can help in the testing and verification of the
system’s functionality.

• Facilitates documentation: DFDs provide a visual representation of a system,

making it easier to document and maintain the system over time.
 Control Flow Modeling
• A control flow diagram/ Graph (CFD/ CFG) is a very helpful
tool for both systems developers and stakeholders that shows
where control begins and ends and where it branches on all
points in between.

• Control flow graphs are mostly used in static analysis as well

as compiler applications, as they can accurately represent the
flow inside a program unit.

Significance of CFD/ CFG

i. Visualizing program logic
ii. Identifying the control structure (Loops, statements)
iii. Analyzing the program flow
iv. Detect potential errors or inefficiencies
v. Improve code readability & maintainability
 Components of CFG
i. Nodes (Rectangle): Represents actions, decisions,
processes

ii. Edges (Arrow) : Indicates control flow between the

nodes

iii. Decision nodes ( Diamond): Represents conditional

statement

iv. Loop Nodes(Circle) : Represent repetitive processes

v. Terminal nodes( Oval): Represent flow termination

 Types of Control Flow Diagram
1. Structured CFD: Uses standardized symbols
and notations
2. Unstructured CFD: Does not follows
standards
3. High Level CFD: Focuses on overall program
logic/ flow
4. Detailed CFD: Shows detailed program flow
Characteristics of Control Flow Graph
• The control flow graph is process-oriented.
• The control flow graph shows all the paths
that can be traversed during a program
execution.
• A control flow graph is a directed graph.
• Edges in CFG portray control flow paths and
the nodes in CFG portray basic blocks.
Examples
 Unified Modeling Language (UML)
• Unified Modeling Language (UML) is a general-purpose modeling
language.

• The main aim of UML is to define a standard way to visualize the way a
system has been designed.

• We use UML diagrams to portray the behavior and structure of a system

• UML is not a programming language , it is rather a visual language.

• UML can significantly improve the quality and clarity of your software
designs.
• It was invented by Grady Booch & Rambaugh

• The Object Management Group (OMG) adopted Unified Modeling

Language as a standard in 1997. It’s been managed by OMG ever since

• The International Organization for Standardization (ISO) published UML as

an approved standard in 2005. UML has been revised over the years and is
reviewed periodically.
 Significance of UML
• Complex applications need collaboration and
planning from multiple teams and hence require
a clear and concise way to communicate amongst
them.

• Businessmen do not understand code. So UML

becomes essential to communicate with non-
programmers about essential requirements,
functionalities, and processes of the system.

• A lot of time is saved down the line when teams

can visualize processes, user interactions, and the
static structure of the system.
Types of UML Diagram
 Structural UML Diagram
• Emphasize the static structure of a System
• Show relationship between objects
• Focus on architecture and design
1. Class Diagrams: Describe classes, attributes, and
relationships.
2. Object Diagrams: Illustrate objects and their
relationships.
3. Component Diagrams: Depict system
components and interactions.
4. Deployment Diagrams: Show hardware and
software deployment.
5. Package Diagrams: Organize model elements
into packages.
 Behavioral UML Diagram
• Emphasize dynamic behavior and interactions.
• Show how objects interact and change over time.
• Focus on system behavior and functionality

1. Use Case Diagrams: Model system interactions and

user roles.
2. Sequence Diagrams: Illustrate message passing
between objects.
3. Collaboration Diagrams: Show object interactions and
relationships.
4. State Machine Diagrams: Model object states and
transitions.
5. Activity Diagrams: Describe system workflows and
activities.
 Use case Diagram
Use case:
A use case is a description of the ways in which a
user interacts with a system or product.
A use case may establish the success scenarios,
the failure scenarios, and any critical variations or
exceptions.

Use case diagram:

A use case diagram is a graphical depiction of a
user's possible interactions with a system
Use Case Notations
 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.
 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.

 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.
 Relationship in Use case diagram
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.
 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.
• 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
• 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
• Both “Rent Car” and “Rent Bike” are specialized versions of the general
use case “Rent Vehicle.”
 How to Draw Use Case Diagram
Step 1: Identify Actors
Determine who or what interacts with the system. They can be users, other systems, or
external entities.
Step 2: Identify Use Cases
Identify the main functionalities or actions the system must perform. 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.
 Example: Online Shopping System
1. Actors:
Customer
Admin
2. Use Cases:
Browse Products
Add to Cart
Checkout
Manage Inventory (Admin)
3. Relations:
The Customer can browse products, add to the
cart, and complete the checkout.
The Admin can manage the inventory.
Use case Diagram : Online Shopping