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:
Shows what the system does. It focuses on business operations and
functions without considering physical implementation.
2.
Physical
DFD:
Shows how the system will be implemented in the real world. It
includes hardware, software, files, and people involved in performing tasks.
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

Comments
Post a Comment