Unit 5 SEP

 Software analysis and Design tools

Software Analysis and Design Tools are special computer programs that help developers and designers in every stage of making software. These tools make it easier to understand, plan, design, and document a software system so that the final product works well and meets user needs.

They help in collecting requirements by recording what users want, modeling the system using diagrams such as flowcharts and UML, and designing the structure and interface of the software.

These tools also help in creating documentation for clear communication, analyzing the design to find and fix problems early, and supporting teamwork by allowing different people to work together on the same project smoothly.

Introduction of ER Model

The Entity-Relationship (ER) Model is a conceptual model used to design and represent the logical structure of a database.

It shows entities, their attributes, and relationships among them.

Example: A Student enrolls in a Course — here Student and Course are entities, and "enrolls" is a relationship.

Components of ER Diagram

1.      Entity: A real-world object like Student, Course, or Employee.

2.      Attribute: A property of an entity, like StudentID or Name.

3.      Relationship: A link between entities, like a Student enrolls in a Course.

Importance of ER Diagrams

·         Easy to understand and use.

·         Helps in converting concepts into tables.

·         Represents real-world data visually.

·         No technical DBMS knowledge needed.

Relationship in ER Model

A Relationship in the ER Model shows the association or connection between two or more entities.

It defines how entities are related to each other in a database.

Example: A Student enrolls in a Course — “enrolls in” is the relationship.

Types of Relationships

1.      One-to-One (1:1)

o    One entity is related to only one entity of another type.

o    Example: Each person has one passport.

2.      One-to-Many (1:N)

o    One entity of a type is related to many entities of another type.

o    Example: One teacher teaches many students.

3.      Many-to-One (N:1)

o    Many entities are related to one entity of another type.

o    Example: Many students study in one department.

4.      Many-to-Many (M:N)

o    Many entities of one type are related to many entities of another type.

o    Example: Students enroll in many courses, and each course has many students.

Attributes 

·  Attributes are properties that describe an entity.

Example: Student has Roll_No, Name, and DOB.

·  Key Attribute uniquely identifies each entity.

Example: Roll_No of a student.

·  Composite Attribute is made up of smaller attributes.

Example: Address → Street, City, State.

·  Multivalued Attribute holds more than one value.

Example: Phone_No (student may have two numbers).

·  Derived Attribute is calculated from other attributes.

Example: Age from Date of Birth (DOB).

Types of Entities

1.      Strong Entity:

o    Has its own key attribute for identification.

o    Example: Employee (identified by Employee_ID).

o    Symbol: Single rectangle.

2.      Weak Entity:

o    Cannot be identified without another entity.

o    Depends on a Strong Entity for identification.

o    Example: Dependent of an Employee.

o    Symbol: Double rectangle (with double diamond for identifying relationship).

Data Flow Diagram

A Data Flow Diagram (DFD) is a visual tool used to represent how data 

moves within a system. It shows where the data comes from, how it is processed,

 where it is stored, and where it finally goes. DFDs help users, customers, and

 software engineers understand the system clearly, allowing them to work

 together effectively during the analysis and requirement-gathering stages.

They focus only on how data flows, without describing technical or

 implementation details. Because of their simplicity, DFDs are widely used in 

structured analysis and software development.

Characteristics of DFD

• Graphical: DFD uses simple symbols to show how data moves in a system.
• Helps in Analysis: It helps understand the system and find problems easily.
• Abstract: It shows data flow without showing technical details.
• Hierarchical: It is made in levels, where higher levels show a simple overview and lower levels show more details.

Rules of DFD

1.     Every process must have at least one input and one output. A process cannot exist without receiving or producing data.

2.     Every data store should have at least one data flow entering and one data flow leaving it, ensuring that data is both stored and retrieved.

3.     All processes must be connected to other processes, data stores, or external entities. No process should be isolated.

4.     External entities can exchange data only through processes; they cannot directly connect to a data store.

Levels of Data Flow Diagram

a. Level 0 DFD (Context Diagram)

Level 0 is the highest-level diagram, representing the entire system as a single process. It shows the system’s interaction with external entities and presents the overall input and output of the system. It does not provide internal details of processes.

b. Level 1 DFD

Level 1 expands the single process of Level 0 into multiple sub-processes. It shows how the main functions of the system are divided and how data flows between them. It also includes data stores and more detailed data flows.

Types of Data Flow Diagram

There are two major types of DFDs:

1.     Logical DFD:

2.     Physical DFD:

Components of DFD

1. Process: Contains input data that goes into the process and output data that comes out after processing.

2. Data Flow : Contains data being transferred, such as messages, information, or values moving from one part of the system to another.

3. Data Store : Contains stored data, such as records, files, tables, or any information kept for later use.

4. External Entity : Contains data sent by or received from people, other systems, or organizations outside the main system.

 

Symbol of DFD

Structure chart

A Structure Chart shows how a system is broken into smaller parts called modules. Each module acts like a black box, meaning we know what it does but not how it works inside. Inputs are given to modules and outputs are produced. Higher-level modules control and call lower-level modules by passing data. The chart is read from top to bottom and left to right, making the system easy to understand.

Symbols in Structured Chart

1. Module

It represents the process or task of the system. It is of three types:

·         Control Module: A control module branches to more than one submodule.

·         Sub Module: Sub Module is a module which is the part (Child) of another module.

·         Library Module: Library Module are reusable and invokable from any module.

2. Conditional Call

It represents that control module can select any of the sub module on the basis of some condition.

3. Loop (Repetitive call of module)

It represents the repetitive execution of module by the sub module. A curved arrow represents a loop in the module. All the submodules cover by the loop repeat execution of module.

4. Data Flow

It represents the flow of data between the modules. It is represented by a directed arrow with an empty circle at the end.

5. Control Flow

It represents the flow of control between the modules. It is represented by a directed arrow with a filled circle at the end.

6. Physical Storage

It is that where all the information are to be stored.

Example

Structure chart for an Email server

 

Decision Table

A decision table is a simple table used to decide what action to take when different conditions occur.

It is used when a problem has many rules and different situations.

Why Decision Table is Needed

Sometimes rules are confusing when written in sentences.
A decision table:

·         Shows rules clearly

·         Covers all possible cases

·         Avoids missing any situation

Main Parts of a Decision Table

1 Conditions

These are questions with answers like Yes/No.
Example:

·         Is user a member?

·         Is payment done?

2 Actions

These are what the system does.
Example:

·         Allow login

·         Show error message

3 Rules

Each column is one rule (one situation).

 

Decision Tree

A decision tree is a diagram that shows how decisions are made step by step based on conditions.

It looks like a tree, where:

·         Each question is a branch

·         Each answer leads to another branch

·         The final result is an action

Why Decision Tree is Used

·         To show decision logic visually

·         To make decisions easy to follow

·         To break a big problem into small steps

Main Parts of a Decision Tree

1.  Decision Node

·         Shown as a square

·         Represents a question
Example: Is user a member?

2 . Branch

·         Lines coming from a decision node
Example: Yes / No

3. Leaf / Action Node

·         Shown as a circle

·         Shows the final action
Example: Give discount

Advantages

 Easy to understand
Visual and clear
 Good for step-by-step logic

Disadvantages

 Hard to manage if logic is very complex
 Tree becomes large with many conditions  

Use case diagram in UML

A use case diagram is a type of UML diagram that shows how a user interacts with a system. It explains what the system does and who uses it, but it does not show internal details like algorithms or data structures. Use case diagrams are mainly used during the analysis and design phase to understand customer requirements and system functionality. They include the system, actors (users), and use cases (actions performed by users).

What a Use Case Diagram Shows

A use case diagram mainly includes three things:

1.  System

• The software or application being developed
  Example: Library Management System

2.  Actors

• People or systems that use the system
  Example: Student, Librarian

3. Use Cases

• Actions the actor can perform
  Example: Borrow book, Return book

Example

Advantages of Use Case Diagram

·         It is easy to understand for both users and developers.

·         It clearly shows system functionality and user interaction.

·         It helps in understanding customer requirements.

·         It defines the scope of the system.

·         It is useful for writing test cases.

It improves communication between users and developers

Sequence Diagram

What are Sequence Diagrams?

A Sequence Diagram is a type of UML (Unified Modeling Language) diagram used to visualize the interactions between objects or components over time. It shows the order and timing of messages exchanged in a process, making it useful for understanding dynamic system behavior and workflows.

 Why Use Sequence Diagrams?

Sequence diagrams are helpful because they:

·         Show dynamic interactions and message flow in a clear, time-ordered way.

·         Help teams understand complex processes without reading code.

·         Support use case analysis by showing how scenarios unfold.

·         Aid in system design and architecture, especially in distributed systems.

·         Serve as documentation for developers and maintenance teams.

·         Help debug and identify issues in process flow.

3. Key Notations in Sequence Diagrams

Actors

·         Represent external entities interacting with the system (e.g., users, external systems).

·         Always lie outside the system boundary.

·         Shown as a stick figure.

·         Example: A user using a seat-reservation system.

Lifelines

·         Show the existence of an object or participant over time.

·         Displayed as a vertical dashed line under the participant’s name.

·         Format: InstanceName : ClassName.

·         Actors differ from lifelines: actors are external; lifelines are internal system objects.

Messages

Messages represent communication between objects. They appear as arrows between lifelines.

Types of messages:

1.      Synchronous Message

o    Waits for a reply before proceeding.

o    Represented with a solid arrow head.

2.      Asynchronous Message

o    Does not wait for a reply.

o    Shown with a lined arrow head.

Example: