System Analysis & Design (SAD): DFD (Level 0, 1, 2), ER Diagrams & Use Case Modeling Guide for TU BCA
Author: Bhuban Subedi | Subject: System Analysis and Design (CACS202) | Semester: Third / Fourth Semester
In the Tribhuvan University (TU) BCA curriculum, System Analysis and Design (SAD – CACS202) bridges abstract business problems and technical software architectures.
Whether answering 10-mark long questions in your theoretical board examinations or writing your Minor and Major Project System Documentation reports, mastering visual modeling techniques is non-negotiable.
In this guide, we will master the three most critical system modeling diagrams: Data Flow Diagrams (DFD Levels 0, 1, 2), Entity-Relationship (ER) Diagrams, and UML Use Case Diagrams, complete with symbols, rules, and an end-to-end case study.
1. Data Flow Diagrams (DFD): Principles & Notation
A Data Flow Diagram (DFD) graphically illustrates the flow of data through an information system, detailing inputs, processing transformations, and permanent data stores.
Standard DFD Symbols (Gane & Sarson / Yourdon & DeMarco):
+-------------------+---------------------------+--------------------------------------+
| Element | Yourdon & DeMarco Symbol | Meaning / Description |
+-------------------+---------------------------+--------------------------------------+
| External Entity | Rectangle [ ] | Source or destination of data outside|
| | | the system boundaries (e.g. Student).|
+-------------------+---------------------------+--------------------------------------+
| Process | Circle (O) or Round Rect | Transforms incoming data into output.|
| | | Labeled with a strong verb-noun. |
+-------------------+---------------------------+--------------------------------------+
| Data Store | Open-ended parallel lines | File or database repository storing |
| | === or [D1 | ...] | data at rest (e.g. D1: Student_DB). |
+-------------------+---------------------------+--------------------------------------+
| Data Flow | Labeled Arrow (----->) | Directional path of moving data. |
+-------------------+---------------------------+--------------------------------------+
2. The DFD Hierarchy: Context (Level 0) to Level 1
+-------------------------------------------------------------+
| Context Diagram (Level 0): |
| High-level abstraction showing the entire system as a single|
| central process interacting with external entities. |
+-------------------------------------------------------------+
| Decompose Process 0
v
+-------------------------------------------------------------+
| Level 1 DFD: |
| Decomposes the single system into major sub-processes |
| (e.g. 1.0 Auth, 2.0 Registration, 3.0 Report Generation) |
| and reveals data stores. |
+-------------------------------------------------------------+
Case Study: University Online Library Management System
A. Context Diagram (Level 0 DFD):
+----------------+
| Student |
+-------+--------+
| Book Request / Search Query
v
+--------------------+
| 0.0 |
| Online Library MS | <=====> [ Librarian / Admin ]
+--------------------+
| Book Issue Status / Fine Notice
v
+----------------+
| Student |
+----------------+
B. Level 1 DFD Decomposition:
[ Student ] ---> ( 1.0 User Authentication ) <---> [ D1: User_Credentials ]
|
v (Valid User Token)
( 2.0 Search & Reserve Book ) <---> [ D2: Book_Catalog ]
|
v (Reservation Details)
( 3.0 Issue / Return Processing ) <---> [ D3: Borrow_Records ]
^
| (Approval & Check-in)
[ Librarian / Admin ]
3. Entity-Relationship (ER) Diagrams
An ER Diagram models the logical database structure by defining entity types, their attributes, and relationships.
ER Diagram Notation (Chen Notation):
- Entity: Rectangle (
[ Student ]). - Weak Entity: Double Rectangle.
- Attribute: Ellipse (
( Name )). - Key Attribute (Primary Key): Ellipse with underlined text (
( Student_ID )). - Multivalued Attribute: Double Ellipse (
(( Phone_Numbers ))). - Derived Attribute: Dashed Ellipse (
( Age )derived fromDOB). - Relationship: Diamond shape (
< Borrows >).
+-----------+ < Borrows > +-----------+
| Student | (1) ----------- < (Issue Date) > ---------- (N)| Book |
+-----+-----+ +-----+-----+
| |
(StudentID) (ISBN / Title)
Relationship Cardinalities:
- 1 : 1 (One-to-One): E.g., One Student has One ID Card.
- 1 : N (One-to-Many): E.g., One Department has Many Students.
- M : N (Many-to-Many): E.g., Many Students enroll in Many Courses (resolved into an associative table).
4. UML Use Case Modeling
In Object-Oriented Analysis, a Use Case Diagram captures functional requirements from the end-user’s perspective.
Core Elements:
- Actor (Stick figure): An external user role interacting with the system.
- Use Case (Horizontal Ellipse): A specific action or business goal performed by an actor.
<<include>>Relationship: Mandatory sub-step that always runs as part of the base use case.<<extend>>Relationship: Optional behavior that executes only under specific conditional circumstances.
[ Actor: Student ]
|
+----> ( Login ) <------- <<include>> ------- ( Validate Credentials )
|
+----> ( Borrow Book ) <-- <<extend>> ------- ( Pay Overdue Fine )
|
+----> ( View Results )
Frequently Asked Questions (FAQ)
Q1: What is the Golden Rule of DFD balancing?
All incoming and outgoing data flows present in a parent DFD process (e.g., Level 0) must be precisely accounted for and balanced in the decomposed child DFD (Level 1). Data cannot magically appear or disappear across decomposition levels.
Q2: What is the difference between <<include>> and <<extend>> in Use Case Diagrams?
<<include>>represents a dependency where the base use case cannot complete without the included use case (e.g., Checkout<<include>>Process Payment).<<extend>>represents optional/conditional behavior that runs only if a specific condition is met (e.g., Apply Coupon Code extends Checkout).
 for TU BCA. Step-by-step Data Flow Diagrams (DFD Level 0, 1, 2), ER Diagrams, Use Cases, and project documentation.){kind=link}