PRANVEER SINGH INSTITUTE OF TECHNOLOGY,

KANPUR

DEPARTMENT OF INFORMATION TECHNOLOGY

Even Semester 2024-25

B. Tech.- Third Year

Semester - VI

Lab File
Software Engineering
(BCS 651)

Submitted To: Submitted By:

Faculty Name :_________________ Name :_________________
Designation :_________________ Roll No. :_________________
Section :_________________

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 Table of Contents
● Vision and Mission Statements of the Institute

● Vision and Mission Statements of the Department

● PEOs, POs, PSOs of the Department

● Course Objective and Outcomes

● List of Experiments

● Index

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 Department Vision Statement
To be recognized, the Department of Computer Science & Engineering produces versatile
computer engineers, capable of adapting to the changing needs of computer and related industry.

Department Mission Statements

The mission of the Department of Computer Science and Engineering is:

i. To provide broad-based education with knowledge and attitude to succeed in Computer

Science & Engineering careers.

ii. To prepare students for emerging trends in computer and related industry.

iii. To develop competence in students by providing them with skills and aptitude to foster
culture of continuous and lifelong learning.

iv. To develop practicing engineers who investigate research, design, and find workable
solutions to complex engineering problems with awareness & concern for society as well as the
environment.

Program Educational Objectives (PEOs)

i. The graduates will be efficient leading professionals with knowledge of computer science &
engineering discipline that enables them to pursue higher education and/or successful careers in
various domains.

ii. Graduates will possess the capability of designing successful innovative solutions to real life
problems that are technically sound, economically viable and socially acceptable.

iii. Graduates will be competent team leaders, effective communicators and capable of working
in multidisciplinary teams following ethical values.

iv. The graduates will be capable of adapting to new technologies/tools and constantly upgrading
their knowledge and skills with an attitude for lifelong learning

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 Department Program Outcomes (POs)

The students of the Computer Science and Engineering Department will be able:

1. Engineering knowledge: Apply the knowledge of mathematics, science, Computer

Science & Engineering fundamentals, and an engineering specialization to the solution
of complex engineering problems.

2. Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and Computer Science & Engineering sciences.

3. Design/development of solutions: Design solutions for complex Computer Science &

Engineering problems and design system components or processes that meet the
specified needs with appropriate consideration for public health and safety, and the
cultural, societal, and environmental considerations.

4. Investigation: Use research-based knowledge and research methods including design of

experiments, analysis and interpretation of data, and synthesis of the information to
provide valid conclusions.

5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modelling to complex
Computer Science & Engineering activities with an understanding of the limitations.

6. Engineering and Society: Apply reasoning informed by contextual knowledge to

assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice in the field of Computer
Science and Engineering.

7. Environment and sustainability: Understand the impact of the professional Computer

Science & Engineering solutions in societal and environmental contexts, and
demonstrate the knowledge of, and need for sustainable development.

8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities
and norms of the Computer Science & Engineering practice.

9. Individual and team work: Function effectively as an individual, and as a member or

leader in diverse teams, and in multidisciplinary settings.

10. Communication: Communicate effectively on complex Computer Science &

Engineering activities with the engineering community and with society at large, such as

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 being able to comprehend and write effective reports and design documentation, making
effective presentations, and giving and receiving clear instructions.

11. Project management and finance: Demonstrate knowledge and understanding of the
Computer Science & Engineering and management principles and apply these to one’s
own work, as a member and leader in a team, to manage projects and in
multidisciplinary environments.

12. Life-long learning: Recognize the need for and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change.

Department Program Specific Outcomes (PSOs)

The students will be able to:

1. Use algorithms, data structures/management, software design, concepts of programming

languages and computer organization and architecture.

2. Understand the processes that support the delivery and management of information
systems within a specific application environment.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 Course Outcomes
*Level of Bloom’s *Level of Bloom’s
Level to be met Level to be met
Taxonomy Taxonomy
L1: Remember 1 L2: Understand 2
L3: Apply 3 L4: Analyze 4
L5: Evaluate 5 L6: Create 6

CO Number Course Outcomes

BCS-651.1
Define [1. Knowledge] the specification standard of IEEE for writing SRS.

BCS-651.2 Discuss [2. Comprehension] the scope of Software Engineering to students where
they can infer small, real-life problems.
Apply [3. Application] the development & design concepts in DFDs, UML
BCS-651.3
Diagrams, others to develop, implement, and demonstrate the learning through a
project that meet stated specifications.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 List of Experiments

Lab No. Lab Experiment Corresponding CO

Prepare a SRS document in line with the IEEE
1 CO1
recommended standards.
Draw the case diagram and specify the role of each of the
2 actors. Also state the precondition, post condition and CO1
function of each use case.
3 Draw the activity diagram. CO1
Identify the classes. Classify them as weak and strong
4 CO3
classes and draw the class diagram.
5 Draw the sequence diagram for any two scenarios. CO1

6 Draw the collaboration diagram. CO2

7 Draw the state chart diagram. CO3

8 Draw the component diagram. CO2

Perform forward engineering in java. (Model to code
9 CO3
conversion)
Perform reverse engineering in java. (Code to Model
10 CO3
conversion)

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 INDEX
Date of Date of Faculty
S No Lab Experiment Marks
Experiment Submission Signature
To Prepare a SRS document in line
1 with the IEEE recommended
Standards
Draw the Use Case diagram and
specify the role of each of the actors.
2 Also state the precondition, post
condition and function of each use
case.
To draw a activity diagram for a real
3
project or system.
Identify the classes. Classify them as
4 weak and strong classes and draw the
class diagram.
Draw the sequence diagram for any
5
two scenarios.
Draw the collaboration diagram using
6
Star UML.
To prepare State Chart diagram for
7
project.
Draw the Component Diagram using
8
Star UML
Draw the Deployment Diagram using
9
Star UML.
To draw a sample E-R diagram of
10
project.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 EXPERIMENT 1
Aim: To Prepare a SRS document in line with the IEEE recommended Standards

Requirements:

Software Requirements:

Star UML, Windows XP,

Theory:

An SRS is basically an organization's understanding (in writing) of a customer or

potential client's system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. It's a two-way insurance policy
that assures that both the client and the organization understand the other's requirements
from that perspective at a given point in time.

SRSs are typically developed during the first stages of "Requirements Development,"
which is the initial product development phase in which information is gathered about
what requirements are needed--and not. This information-gathering stage can include
onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment
(ROI) analysis or needs analysis of the customer or client's current business environment.
The actual specification, then, is written after the requirements have been gathered and
analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:
a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware,
other hardware, and other software?

c) Performance. What is the speed, availability, response time, recovery time of various
software functions, etc.?

d) Attributes. What are the portability, correctness, maintainability, security, etc.

considerations?

e) Design constraints imposed on implementation. Are there any required standards in

effect, language implementation, policies for database integrity, resource limits.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651
 4. System Features
4.1 System feature
5.
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B

5. Other Non-Functional Requirements

5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
7.
Appendix B: To be determined
Conclusion: The SRS was made successfully by following the steps described above.

SRS-

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651
 EXPERIMENT 2
Aim: Draw the use case diagram and specify the role of each of the actors. Also state the
precondition, post condition and function of each use case.

Software Requirements:

Star UML, Windows XP,

Theory:

According to the UML specification a use case diagram is “a diagram that shows the
relationships among actors and use cases within a system.” Use case diagrams are often
used to:

● Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model

● Communicate the scope of a development project

● Model your analysis of your usage requirements in the form of a system use case
model

Use case models should be developed from the point of view of your project stakeholders
and not from the (often technical) point of view of developers. There are guidelines for:

Use Cases

Actors

Relationships

System Boundary Boxes

1. Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor. A
use case is drawn as a horizontal ellipse on a UML use case diagram.

1. Use Case Names Begin with a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases in the Top-Left Corner of The Diagram
4. Imply Timing Considerations by Stacking Use Cases.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 2. Actors

An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use
Case diagrams).

1. Place Your Primary Actor(S) In the Top-Left Corner of the Diagram

2. Draw Actors to the Outside of a Use Case Diagram
3. Name Actors with Singular, Business-Relevant Nouns
4. Associate Each Actor with One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use case diagram:

● An association between an actor and a use case

● An association between two use cases

● A generalization between two actors

● A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional
open-headed arrowhead on one end of the line indicating the direction of the initial
invocation of the relationship. Generalizations are depicted as a close-headed arrow with
the arrow pointing towards the more general modeling element.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651
 4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name
suggests it indicates the scope of your system – the use cases inside the rectangle
represent the functionality that you intend to implement.

1. Indicate Release Scope with a System Boundary Box.

2. Avoid Meaningless System Boundary Boxes.

Creating Use Case Diagrams

We start by identifying as many actors as possible. You should ask how the actors
interact with the system to identify an initial set of use cases. Then, on the diagram, you
connect the actors with the use cases with which they are involved. If actor supplies
information, initiates the use case, or receives any information as a result of the use case,
then there should be an association between them.

Use Case Diagram-

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 EXPERIMENT 3
AIM :- To draw activity diagram for a real project or system.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 Software Requirements: Star UML, Windows XP,

THEORY

UML 2 activity diagrams are typically used for business process modeling, for modeling
the logic captured by a single use case or usage scenario, or for modeling the detailed
logic of a business rule. Although UML activity diagrams could potentially model the
internal logic of a complex operation it would be far better to simply rewrite the
operation so that it is simple enough that you don’t require an activity diagram. In many
ways UML activity diagrams are the object-oriented equivalent of flow charts and data
flow diagrams (DFDs) from structured development.

Basic notation:

● Initial node. The filled in circle is the starting point of the diagram. An initial
node isn’t required although it does make it significantly easier to read the
diagram.

● Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.

● Activity. The rounded rectangles represent activities that occur. An activity may
be physical, such as Inspect Forms, or electronic, such as Display Create Student
Screen.

● Flow/edge. The arrows on the diagram. Although there is a subtle difference

between flows and edges never a practical purpose for the difference.
● Fork. A black bar with one flow going into it and several leaving it. This denotes
the beginning of parallel activity.

● Join. A black bar with several flows entering it and one leaving it. All flows
going into the join must reach it before processing may continue. This denotes the
end of parallel processing.

● Condition. Text such as[Incorrect Form] on a flow, defining a guard which must
evaluate to true to traverse the node.

● Decision. A diamond with one flow entering and several leaving. The flows
leaving include conditions although some modelers will not indicate the
conditions if it is obvious.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 ● Merge. A diamond with several flows entering and one leaving. The implication
is that one or more incoming flows must reach this point until processing
continues, based on any guards on the outgoing flow.

● Partition. If figures are organized into three partitions, it is also called swimlanes,
indicating who/what is performing the activities (either the Applicant, Registrar,
or System).

● Sub-activity indicator. The rake in the bottom corner of an activity, such as in

the Apply to University activity, indicates that the activity is described by a more
finely detailed activity diagram.

● Flow final. The circle with the X through it. This indicates that the process stops
at this point.

GUIDELINES ASSOCIATED FOR DRAWING AN ACTIVITY DIAGRAM

1.General Guidelines

2.Activities

3.Decision Points

4.Guards

5.Parallel Activities

6.Swimlane Guidelines

7.Action-Object Guidelines

Conclusion: The activity diagram was made successfully by following the steps described.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651
Class diagrams show the classes n of operations and attributes of the classes. all at once, to:
● Explore domain concepts in the form of a domain model

● Analyze requirements in the form of a conceptual/analysis model

● Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting specifications
that describe model elements including classes, relationships between classes, and interfaces.
There are guidelines:

1. General issues
Because class diagrams are used for a variety of purposes – from understanding
requirements to describing your detailed design – it is needed to apply a different
style in each circumstance. This section describes style guidelines pertaining to
different types of class diagrams.

2. Classes
A class in the software system is represented by a box with the name of the class written
inside it. A compartment below the class name can show the class's attributes (i.e. its
properties). Each attribute is shown with at least its name, and optionally with its type,
initial value, and other properties

3. Interfaces
An interface is a collection of operation signature and/or attributes definitions that
ideally define a cohesive set of behaviors. Interface a class or component must
implement the operations and attributes defined by the interface. Any given class or
component may implement zero or more interfaces, and one or more classes or
components can implement the same interface.

4. Relationships
A relationship is a general term covering the specific types of logical connections
found in a class and object diagram.
Class diagrams also display relationships such as containment, inheritance,
associations and others.
The association relationship is the most common relationship in a class diagram.
The association shows the relationship between instances of classes.

Another common relationship in class diagrams is generalization. A generalization

is used when two classes are similar but have some differences.

5. Aggregation and Composition

Aggregation is a variant of the "has a" or association relationship; composition is

more specific than aggregation. Aggregation occurs when a class is a collection or
container of other classes, but where the contained classes do not have a strong
life cycle dependency on the container-- essentially, if the container is destroyed,
its contents are not.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 TO DRAW CLASS DIAGRAM

When designing classes the attributes and operations it will have are observed. Then
determining how instances of the classes will interact with each other. These are the very
first steps of many in developing a class diagram. However, using just these basic
steps in the analysis and design of an object oriented system.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651
 EXPERIMENT 5
Aim: Draw the sequence diagram for any two scenarios.
Software Requirements:
Star UML, Windows XP

Theory:
UML sequence diagrams model the flow of logic within the system in a visual manner,
enabling the user both to document and validate the logic, and are commonly used for
both analysis and design purposes. Sequence diagrams are the most popular UML artifact
for dynamic modeling, which focuses on identifying the behavior within your system.
Sequence diagrams, along with class diagrams and physical data models are the most
important design-level models for modern application development.

Sequence diagrams are typically used to model:

1. Usage scenarios. A usage scenario is a description of a potential way the systemis

used. The logic of a usage scenario may be part of a use case, perhaps an alternate
course. It may also be one entire pass through a use case, such as the logic
described by the basic course of action or a portion of the basic course of action,
plus one or more alternate scenarios. The logic of a usage scenario may also be a
pass through the logic contained in several use cases. For example, a student
enrolls in university, and then immediately enrolls in three seminars.

2. The logic of methods. Sequence diagrams can be used to explore the logic of a
complex operation, function, or procedure. One way to think of sequence
diagrams, particularly highly detailed diagrams, is as visual object code.

3. The logic of services. A service is effectively a high-level method, often one that
can be invoked by a wide variety of clients. This includes web-services as well as
business transactions implemented by a variety of technologies such as
CICS/COBOL or CORBA-compliant object request brokers (ORBs).

To Draw Sequence Diagrams

Sequence diagramming really is visual coding, even when you are modeling a usage
scenario via a system-level sequence diagram.

While creating a sequence diagram, start by identifying the scope of what you are trying
to model. You should typically tackle small usage scenarios at the system level or a
single method/service at the detailed object level.

You should then work through the logic with at least one more person, laying out
classifiers across the top as you need them. The heart of the diagram is in the messages,
which you add to the diagram one at a time as you work through the logic. You should
rarely indicate return values, instead you should give messages intelligent names which

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 often make it clear what is being returned.

It is interesting to note that as you sequence diagram you will identify new
responsibilities for classes and objects, and, sometimes, even new classes. The
implication is that you may want to update your class model appropriately, agile
modelers will follow the practice Create Several Models in Parallel, something that
CASE tools will do automatically. Remember, each message sent to a class invokes a
static method/operation on that class each message sent to an object invokes an operation
on that object.

Regarding style issues for sequence diagramming, prefer drawing messages going from
left-to-right and return values from right-to-left, although that doesn’t always work with
complex objects/classes. Justify the label on messages and return values, so they are
closest to the arrowhead. Also prefer to layer the sequence diagrams: from left-to-right.
indicate the actors, then the controller class(es), and then the user interface class(es), and,
finally, the business class(es). During design, you probably need to add system and
persistence classes, which you should usually put on the right-most side of sequence
diagrams. Laying your sequence diagrams in this manner often makes it easier to read
and also makes it easier to find layering logic problems, such as user interface classes
directly accessing persistence.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

Sequence Diagram-

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 EXPERIMENT 6
Aim :- Draw the collaboration diagram using Star UML.

Hardware Requirements:
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard and mouse, colored
monitor.

Software Requirements:
Star UML, Windows XP

THEORY
Collaboration diagrams are also relatively easy to draw. They show the relationship
between objects and the order of messages passed between them. The objects are listed as
icons and arrows indicate the messages being passed between them. The numbers next to
the messages are called sequence numbers. As the name suggests, they show the
sequence of the messages as they are passed between the objects. There are many
acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be used,
as the example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2,
1.2.1... scheme can be used.

The example below shows a simple collaboration diagram for placing an order use case.
This time the names of the objects appear after the colon, such as Order Entry Window
following the object Name: class Name naming convention. This time the class name is
shown to demonstrate that all of objects of that class will behave the same way.

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

Collaboration Diagram-

DEPARTMENT OF INFORMATION TECHNOLOGY BCS-651

 EXPERIMENT 7

AIM: To prepare state chart diagram for project.

REQUIREMENTS:

Software Interfaces

● Any window-based operating system (Windows98/2000/XP/NT)

● IBM Star UML Software

THEORY:
State Chart Diagrams provide a way to model the various states in which an object can exist.
There are two special states: the start state and the stop state.

The Start state is represented by a block dot.

The Stop state is represented by a bull’s eye.

A condition enclosed in square brackets is called a guard condition and controls when
transition can or cannot occur.
Process that occur while an object is in a certain state are called actions.

STEPS TO DRAW STATE CHART DIAGRAM IN STAR UML SOFTWARE

● To insert new state diagram secondary click on Logical View.

● Select---New----State chart Diagram.
● A new diagram will be created, type in a name for the new diagram.

● Now double click on the new diagram to open it on the stage. To begin the diagram click on
the “START STATE” button.
Place a start state icon on the diagram by clicking the mouse once.
Now add states to the diagram, these make up the content of the diagram.
Click on the state button. Place the instances for each state into the diagram and
type in names for them.

● Now arrange the states to fill the diagram better. Drag the states to new positions to make the
easiest layout to work with.
● Add an end state to the diagram by clicking the “END STATE” button. Place an instance into
the diagram. Now add relationships to the diagram.
● Click on the “STATE TRANSITION” button and drag arrows between the appropriate states.
 ● To edit the specification secondary click on the relation lines and select
“OPENSPECIFICATION” button. Add a name for the event in the specification. Then click
on “apply” and then on “OK” button.
● Add details to the specifications of the other relationships in the same way.
● There may be instances on the diagram where a state can join more than one state. In this case
add a relationship in the same way. Then enter the specification for the new state.

Conclusion: The state chart diagram was made successfully by following the steps described
above.

State Chart Diagram-

EXPERIMENT 8
 Aim:
Steps to draw the Component Diagram using Star UML.

Software Requirements:
Star UML, Windows XP

THEORY

A component is something required to execute a stereotyped function. Examples of stereotypes in

components include executables, documents, database tables, files, and library files. Components are
wired together by using an assembly connector to connect the required interface of one component
with the provided interface of another component. This illustrates the service consumer - service
provider relationship between the two components.
An assembly connector is defined as "a connector between two components that defines that one
component provides the services that another component requires. An assembly connector is a
connector that is defined from a required interface or port to a provided interface or port."
When using a component diagram to show the internal structure of a component, the provided and
required interfaces of the encompassing component can delegate to the corresponding interfaces of
the contained components.
A component is represented by a rectangle with either the keyword "component" or a stereotype in
the top right corner: a small rectangle with two even smaller rectangles jutting out on the left.

Example

Deployment diagram is a structure diagram which shows the architecture of the system as the
deployment (distribution) of software artifacts to deployment targets. Artifacts represent concrete
elements in the physical world that are the result of a development process. A deployment target is
usually represented by a node, which is either a hardware device or some software execution
environment. Nodes can be connected through communication paths to create networked systems of
arbitrary complexity.
Deployment diagrams can describe architecture at the specification level (also called type level) or at the
instance level (similar to class diagrams and object diagrams).

Component Diagram-
EXPERIMENT 9
Aim: Steps to draw the Deployment Diagram using Star UML.

Software Requirements:
Star UML, Windows XP

THEORY

Deployment diagram visualizes the topological view of an entire system. It represents the
deployment of a system. A deployment diagram consists of nodes which describe the physical
devices used inside the system. On these nodes, artifacts are deployed. We can also have node
instances on which artifact instances are going to be implemented.

Node and artifacts of a system participate in the final execution of a system. A deployment diagram
plays a critical role during the administrative process, and it must satisfy the following parameters:

● High performance
● Maintainability
● Scalability
● Portability
● Easily understandable

Nodes and artifacts are the essential elements of deployment. Before actually drawing the
deployment diagram, all nodes and the relationship between every node of the system must be
identified.

If all the nodes, relations, and artifacts are known, then it becomes easy to develop a
deployment diagram.

Example of a Deployment diagram

Following deployment diagram represents the working of HTML5 video player in the browser:
Deployment Diagram -
 EXP
ERIMENT 10

Aim :- To draw a sample E-R diagram of project.

Software Requirements:
Star UML, Windows XP,

THEORY
Entity Relationship Diagrams are a major data modelling tool and will help organize the data in
your project into entities and define the relationships between the entities. This process has
proved to enable the analyst to produce a good database structure so that the data can be stored
and retrieved in a most efficient manner.

Entity
A data entity is anything real or abstract about which we want to store data. Entity types fall into
five classes: roles, events, locations, tangible things or concepts. E.g. employee, payment,
campus, book. Specific examples of an entity are called instances. E.g. the employee John Jones,
Mary Smith's payment, etc.

Relationship

A data relationship is a natural association that exists between one or more entities. E.g.
Employees process payments. Cardinality defines the number of occurrences of one entity for a
single occurrence of the related entity. E.g. an employee may process many payments but might
not process any payments depending on the nature of her job.

Attribute
A data attribute is a characteristic common to all or most instances of a particular entity.
Synonyms include property, data element, field. E.g. Name, address, Employee Number, pay rate
are all attributes of the entity employee. An attribute or combination of attributes that uniquely
identifies one and only one instance of an entity is called a primary key or identifier. E.g.
Employee Number is a primary key for Employee.

AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY:

1. Identify Entities Identify the roles, events, locations, tangible things or

concepts about which the end-users want to store data.
2. Find Relationships Find the natural associations between pairs of entities
using a relationship matrix.
3. Draw Rough ERD Put entities in rectangles and relationships on line
segments connecting the entities.
4. Fill in Cardinality Determine the number of occurrences of one entity for a
single occurrence of the related entity.
5. Define Primary Keys Identify the data attribute(s) that uniquely identify one
and only one occurrence of each entity.
6. Draw Key-Based ERD Eliminate Many-to-Many relationships and include
primary and foreign keys in each entity.
7. Identify Attributes Name the information details (fields) which are essential
to the system under development.
8. Map Attributes For each attribute, match it with exactly one entity that it
describes.
9. Draw fully attributed Adjust the ERD from step 6 to account for entities or
ERD relationships discovered in step 8.
10. Check Results Does the final Entity Relationship Diagram accurately
depict the system data?

ER Diagram for HOT WHEELS (Car Booking Platform)

Conclusions:

The ER diagram made successfully by using the above steps.