EXPERIMENT-3

AIM: DESIGN A USE CASE DIAGRAM FOR RAILWAY COMMODITY RESERVATION SYSTEM.
THEORY: Use-case diagrams describe the high-level functions and scope of a system. These
diagrams also identify the interactions between the system and its actors. The use cases and
actors in use-case diagrams describe what the system does and how the actors use it, but not
how the system operates internally. Use-case diagrams illustrate and define the context and
requirements of either an entire system or the important parts of the system. You can model
a complex system with a single use-case diagram, or create many use-case diagrams to
model the components of the system. You would typically develop use-case diagrams in the
early phases of a project and refer to them throughout the development process.
 EXPERIMENT-4
AIM: WRITE A USE CASE DESCRIPTION FOR RAILWAY COMMODITY RESERVATION SYSTEM.
DESCRIPTION:-
WHAT IS A USE CASE DIAGRAM?
A use case diagram is used to represent the dynamic behaviour of a system. It encapsulates
the system's functionality by incorporating use cases, actors, and their relationships. It
models the tasks, services, and functions required by a system/subsystem of an application.
It depicts the high-level functionality of a system and also tells how the user handles a
system.
PURPOSE OF A USE CASE DIAGRAM:-

Use case diagrams are typically developed in the early stage of development and people.
often apply use case modeling for the following purposes:
 Specify the context of a system.
 Capture the requirements of a system.
 Validate a systems architecture.
 Drive implementation and generate test cases.
 Developed by analysts together with domain experts.

The following components are used to design a use case approach:-

Actor:

 Someone interacts with use case (system function).

 Actors represent entities, which can be people, other systems, or external
components that interact with the system.
 Actors initiate actions or perform tasks within the system to achieve their goals.
 Actors play specific roles in relation to the system's functionality.
 They are not part of the system itself but engage with it to achieve specific goals or
tasks.
 Actor triggers use case(s).
 Actor has a responsibility toward the system (inputs), and Actor has expectations
from the system (outputs).
Use Cases:-

 A use case in a use case diagram is a visual representation.

 Each use case describes a specific interaction between one or more actors.
 Use cases includes information about the goals of the user.
 Use cases provide a clear and understandable way to communicate the expected
system behaviour.
Use Case Templates:-

 A unique identifier or name for the use case.

 A statement that defines the scope or context of the use case.
 Information about how often the use case is expected to be executed.
 Information about optional or conditional functionality that can be triggered during
the execution of the use case.
 Use case templates provide a structured approach to documenting system
behaviour.
Use case Boundary:-

 The system boundary in a use case represents the line that separates the system
from its external environment.
 The system boundary is an essential concept in use case modeling and helps clarify
the scope of a particular use case.
 It indicates which parts of the system are relevant to the use case and which parts
are not.
 EXPERIMENT-5
AIM: DESIGN A DATA FLOW DIAGRAM LEVEL 0 AND LEVEL 1 FOR RAILWAY COMMODITY
RESERVATION SYSTEM

THEORY: Data Flow Diagram (DFD) is a graphical representation of data flow in any system.
It is capable of illustrating incoming data flow, outgoing data flow and store data. Data flow
diagram describes anything about how data flows through the system.
Sometimes people get confused between data flow diagram and flowchart. There is a major
difference between data flow diagram and flowchart. The flowchart illustrates flow of
control in program modules. Data flow diagrams illustrate flow of data in the system at
various levels. Data flow diagram does not have any control or branch elements.
TYPES OF DFD:-
 LOGICAL DFD: Logical data flow diagram mainly focuses on the system process. It
illustrates how data flows in the system. Logical DFD is used in various organizations
for the smooth running of system. Like in a Banking software system, it is used to
describe how data is moved from one entity to another.

 PHYSICAL DFD: Physical data flow diagram shows how the data flow is actually
implemented in the system. Physical DFD is more specific and close to
implementation.

Components of Data flow Diagrams:-

 External Entity: Entities include source and destination of the data. Entities are
represented by rectangle with their corresponding names.

 Process: The tasks performed on the data is known as process. Process is

represented by circle. Somewhere round edge rectangles are also used to represent
process.

Data Storage: Data storage includes the database of the system. It is represented by
rectangle with both smaller sides missing or in other words within two parallel lines.

 Data Flow: The movement of data in the system is known as data flow. It is
represented with the help of arrow. The tail of the arrow is source and the head of
the arrow is destination.
DATA FLOW DIAGRAM LEVEL 0: -
 This is the highest-level DFD, which provides an overview of the entire system.
 It shows the major processes, data flows, and data stores in the system.
 without providing any details about the internal workings of these processes.

DATA FLOW DIAGRAM LEVEL 1: -

 This level provides a more detailed view of the system
 by breaking down the major processes identified in the level 0 DFD into sub-
processes.
 Each sub-process is depicted as a separate process on the level 1 DFD.
 The data flows and data stores associated with each sub-process are also shown.
 EXPERIMENT-6
AIM: DESIGN ENTITY RELATIONSHIP DIAGRAM FOR RAILWAY COMMODITY RESERVATION
SYSTEM.
THEORY: An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how
“entities” such as people, objects or concepts relate to each other within a system. ER
Diagrams are most often used to design or debug relational databases in the fields of
software engineering, business information systems, education and research. Also known as
ERDs or ER Models, they use a defined set of symbols such as rectangles, diamonds, ovals
and connecting lines to depict the interconnectedness of entities, relationships and their
attributes.

The components and features of an ER diagram:-

Entity: A definable thing—such as a person, object, concept or event—that can have data
stored about it. Think of entities as nouns. Examples: a customer, student, car or product.
Typically shown as a rectangle.

 Entity type: A group of definable things, such as students or athletes, whereas the
entity would be the specific student or athlete. Other examples: customers, cars or
products.

 Entity set: Same as an entity type, but defined at a particular point in time, such as
students enrolled in a class on the first day. Other examples: Customers who
purchased last month, cars currently registered in Florida. A related term is instance,
in which the specific person or car would be an instance of the entity set.

 Entity categories: Entities are categorized as strong, weak or associative. A strong

entity can be defined solely by its own attributes, while a weak entity cannot.

Relationship: How entities act upon each other or are associated with each other. For
example, the named student might register for a course. The two entities would be the
student and the course, and the relationship depicted is the act of enrolling, connecting the
two entities in that way. Relationships are typically shown as diamonds or labels directly on
the connecting lines.

Attribute: A property or characteristic of an entity. Often shown as an oval or circle.

 Descriptive attribute: A property or characteristic of a relationship

 Attribute categories: Attributes are categorized as simple, composite, derived, as
well as single-value or multi-value. Simple: Means the attribute value is atomic and
can’t be further divided, such as a phone number. Composite: Sub-attributes spring
 from an attribute. Derived: Attributed is calculated or otherwise derived from
another attribute, such as age from a birthdate.
 Multi-value: More than one attribute value is denoted, such as multiple phone
numbers for a person.
 Single-value: Just one attribute value. The types can be combined, such as: simple
single-value attributes or composite multi-value attributes.
Limitations of ER diagrams and models

 Only for relational data: Understand that the purpose is to show relationships. ER
diagrams show only that relational structure.

 Not for unstructured data: Unless the data is cleanly delineated into different fields,
rows or columns, ER diagrams are probably of limited use. The same is true of
semi-structured data, because only some of the data will be useful.

 Difficulty integrating with an existing database: Using ER Models to integrate with

an existing database can be a challenge because of the different architectures.
Uses of entity relationship diagrams

 Database design: ER diagrams are used to model and design relational databases, in
terms of logic and business rules (in a logical data model) and in terms of the
specific technology to be implemented (in a physical data model.) In software
engineering, an ER diagram is often an initial step in determining requirements for
an information systems project. It’s also later used to model a particular database
or databases. A relational database has an equivalent relational table and can
potentially be expressed that way as needed.

 Database troubleshooting: ER diagrams are used to analyze existing databases to

find and resolve problems in logic or deployment. Drawing the diagram should
reveal where it’s going wrong.

 Business information systems: The diagrams are used to design or analyze relational
databases used in business processes. Any business process that uses fielded data
involving entities, actions and interplay can potentially benefit from a relational
database. It can streamline processes, uncover information more easily and
improve results.

 Business process re-engineering (BPR): ER diagrams help in analyzing databases

used in business process re-engineering and in modeling a new database setup.

 Databases are today’s method of storing relational information for educational

purposes and later retrieval, so ER Diagrams can be valuable in planning those
data structures.

 Research: Since so much research focuses on structured data, ER diagrams can play a
key role in setting up useful databases to analyze the data.