0% found this document useful (0 votes)
21 views5 pages

Flowchart and UML

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views5 pages

Flowchart and UML

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Flowcharts in DSA

A flowchart is a diagram that represents the flow of an algorithm using symbols to depict
steps, decisions, inputs, and outputs. It visually outlines the sequence of operations required

Common Symbols in Flowcharts:


to solve a problem, making complex processes easier to understand.

What is UML?
Unified Modeling Language (UML) is a standardized way to visualize, specify, and document the
design of a system using diagrams. It is widely used in software engineering to model complex
systems by representing their structure and behavior.
Categories of UML Diagrams:
UML diagrams are categorized into two main types:
1. Structural Diagrams: Describe the static aspects of a system.
2. Behavioral Diagrams: Describe the dynamic aspects of a system.

1. Structural Diagrams:
These diagrams show the physical and conceptual structure of a system.
 Class Diagram
Represents the classes in a system, their attributes, methods, and relationships
(inheritance, association, aggregation, composition).
Example: Modeling entities in an application such as User, Order, Product.
 Object Diagram
Represents instances of classes (objects) at a specific moment. It shows real-world
examples of relationships.
 Component Diagram
Represents the physical components (e.g., modules, libraries) used in a system and
how they interact.
 Deployment Diagram
Shows the physical deployment of artifacts (software) on hardware nodes (servers,
devices).

2. Behavioral Diagrams:
These diagrams focus on how the system behaves over time.
 Use Case Diagram
Describes the interactions between actors (users or external systems) and the system.
Example: In an online shopping system, actors might be Customer and Admin, interacting
with use cases like Place Order and Manage Inventory.
 Sequence Diagram
Models the sequence of messages exchanged between objects to accomplish a specific
task.
Example: A user logging in involves a sequence of messages between User Interface,
Authentication Service, and Database.
 Activity Diagram
Represents the flow of control or data in a process. It’s similar to a flowchart but more
detailed in representing concurrent processes.
 State Diagram
Describes the states an object can be in and how it transitions from one state to another
based on events.
Example: Modeling the lifecycle of an Order in an e-commerce system: New → Processing
→ Shipped → Delivered.

Common UML Notations:


Symbol Meaning
Class Rectangle with class name, attributes, and
methods
Actor Stick figure representing a user or external
system
Use Case Oval representing a use case
Associatio Solid line representing a relationship between
n entities
Inheritanc Solid line with a hollow arrowhead indicating
e inheritance
Aggregati Solid line with a diamond indicating "whole-
on part" relationship
Compositi Solid line with a filled diamond indicating
on "strong" whole-part relationship

Why Use UML?


1. Visualization: Helps in visualizing the architecture and design of a system.
2. Communication: Acts as a common language between developers, designers, and
stakeholders.
3. Documentation: Provides clear documentation of a system for future reference.
4. Design: Assists in designing object-oriented systems by detailing class structures and
interactions.

UML Web Tools:


Entity Relational Diagram:
Entity-Relationship Diagram (ERD) Detailed Guide
An Entity-Relationship Diagram (ERD) is a graphical representation of entities, attributes,
and relationships in a database system. It provides a clear and organized way to design and
understand the data structure by visualizing the data and its connections.

1. Entities
Entities represent real-world objects or concepts that have distinct and independent
existence. In ERD, entities are typically represented as rectangles.
Types of Entities:
 Strong Entity: An entity that can exist independently in the database.
o Example: Student, Course
 Weak Entity: An entity that cannot exist without a related strong entity. It usually has
a partial key and depends on a strong entity for its identification.
o Example: Dependent (depends on Employee)
Notation: Entities are shown as rectangles with the entity name written inside.

2. Attributes
Attributes are properties or characteristics of an entity. They provide more information about
the entity.
Types of Attributes:
 Simple Attribute: Cannot be divided further.
o Example: Name, Age
 Composite Attribute: Can be divided into smaller sub-parts.
o Example: Full Name can be divided into First Name and Last Name.
 Derived Attribute: Can be derived from other attributes.
o Example: Age can be derived from the attribute Date of Birth.
 Multivalued Attribute: Can have multiple values for a single entity.
o Example: Phone Numbers of an employee.
 Key Attribute: Uniquely identifies an entity instance. It is underlined in the ERD.
o Example: Student ID, Employee ID
Notation: Attributes are represented as ovals connected to their respective entity rectangles.

3. Relationships
Relationships define how entities are associated with each other. They are represented by
diamonds in ERDs.
Types of Relationships:
1. One-to-One (1:1): An entity in set A is related to at most one entity in set B, and vice
versa.
o Example: A Person has one Passport.
2. One-to-Many (1:N): An entity in set A can be related to many entities in set B, but an
entity in set B is related to at most one entity in set A.
o Example: A Professor teaches multiple Courses.
3. Many-to-Many (M:N): Entities in set A can be related to multiple entities in set B and
vice versa.
o Example: Students enroll in multiple Courses, and each Course has many Students
enrolled.
Notation: Relationships are shown as diamonds with lines connecting to the related entities.
The name of the relationship is written inside the diamond.
4. Cardinality
Cardinality specifies the number of instances of one entity that can be associated with
instances of another entity.
Types of Cardinality:
 One-to-One (1:1): Each entity in set A is related to one and only one entity in set B.
 One-to-Many (1:N): Each entity in set A can be related to zero or more entities in set B.
 Many-to-Many (M:N): Entities in set A can be related to multiple entities in set B and
vice versa.
Notation Styles for Cardinality:
1. Crow’s Foot Notation:
o Single line for one, crow’s foot for many.
2. Min-Max Notation:
o Specifies the minimum and maximum number of instances involved in the
relationship.

5. Primary Keys and Foreign Keys


 Primary Key: A unique attribute or a set of attributes that uniquely identifies an entity.
o Example: Student ID in Student entity.
 Foreign Key: An attribute in one entity that is a primary key in another entity. It is used to
establish a relationship between two entities.
o Example: Course ID in Enrollment entity refers to Course ID in Course entity.

6. Weak Entities and Identifying Relationships


A weak entity depends on a strong entity for its identification. It has a partial key that, when
combined with the primary key of the related strong entity, uniquely identifies its instances.
Identifying Relationship:
 A relationship between a weak entity and a strong entity. Represented by a double
diamond.
 Example: Dependent (weak entity) depends on Employee (strong entity) for
identification.

7. Example ERD: Library Management System


Entities:
 Book: Attributes – Book ID, Title, Author, Publisher
 Member: Attributes – Member ID, Name, Address, Phone Number
 Loan: Attributes – Loan ID, Issue Date, Return Date
Relationships:
 Loan connects Member and Book with cardinality (1:N) from Member to Loan and (1:N)
from Book to Loan.
Primary Keys:
 Book ID for Book
 Member ID for Member
 Loan ID for Loan
Foreign Keys:
 Member ID in Loan refers to Member ID in Member.
 Book ID in Loan refers to Book ID in Book.

8. Steps to Create an ERD


1. Identify Entities: Find the key objects (entities) in the system.
2. Identify Relationships: Determine how the entities are related.
3. Identify Attributes: List the properties of each entity and relationship.
4. Define Keys: Identify primary and foreign keys.
5. Determine Cardinality: Specify the number of instances involved in relationships.
6. Draw the ERD: Use appropriate notation for entities, attributes, and relationships.

You might also like