ADGITM Software Engineering Lab

DR. AKHILESH DAS GUPTA INSTITUTE OF TECHNOLOGY & MANAGEMENT

Department of Information Technology

SOFTWARE ENGINEERING LAB

Paper Code: ETCS 353

: Submitted To : : Submitted By :
Ms. Neetu Swarup Name : Jay Chugh
Assistant Professor Roll No :
05815603120 IT Dept. Section: T-7

Jay Chugh
05815603120
T-7
 INDEX

S.no Name of Program Date Signature

Group
B
1. Explain problem statement of student result management
system.
2. Write the software requirement specification document
for result management system.
3. Draw use case diagram through the software Start UML.
4. Draw the data flow diagrams at Level 0
and Level 1 for student result management system.
5. Draw the class diagram for student result management
system.
6. Draw the Activity diagram for student result management
system.
7. To draw the sequence diagram of ATM.
8. Draw the sequence diagram student result management
system.
9. Draw the state chart diagram student result management
system.
10. Draw the collaboration diagram student result
management system.
11. Estimation of effort using FP Estimation for the
chosen system.
12. To perform various testing using the testing tool unit
testing, integration testing
for a sample code of the suggested system.
13. To draw the Component Diagram for the student result
management system and ordering system.
14. To draw the Deployment Diagram for the student result
management system.

Value Added Programs

1. To draw ER diagram of your problem statement.

2. Prepare test cases for solving quadratic equation problem

using Boundary Value
Analysis and write a sample code to execute those test
cases.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 1

AIM: To write the problem statement of STUDENT RESULT MANAGEMENT SYSTEM.

REQUIREMENTS:

1. SOFTWARE REQUIREMENT – Microsoft Word

2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

A university conducts B.Tech course over 8 semesters, divided into 10 branches, namely CSE, IT, ECE, EEE, ME,
MAE, CE, AI&DS, AI&ML and AS&H . The students are offered 6 theory papers and 5 lab papers in all semesters.
The theory papers offered in the 7th Semester are categorized as either 'Core' or 'Elective. Core papers do not have
alternative subject whereas elective papers have 2 other alternative subjects. Thus, a student can take up any subject
out of the 14 given choices.

The evaluation of each subject is done out of 100 marks. For theory paper, the division of externals and internals is
75+25 for respectively. For lab paper, the division is 60+40 for externals and internals respectively. During the
semester, minor exams are conducted for each semester. Students are also required to submit assignments as directed
by the corresponding faculty and maintain Lab records for practical. Based on the students' performance in minor
exams, assignments, Lab records and attendance, marks are given out of 25 in theory paper and 40 in lab paper.
These marks account for internal evaluation if the students. At the end of each semester major exams are conducted
in each subject (theory as well as practical). The theory papers are evaluated out of 75 marks and lab papers are
evaluated out of 60 marks. Thus, the total marks of a student in a subject are obtained by adding the marks
obtained in internal and external evaluation.

The students are required to submit a project report based on their industry training performed by the student in 8 th
semester. They are evaluated out of 100 marks based on the executable project, report submitted, the presentation
given and the viva response.

A student's total score of 40 or higher is considered "pass”, otherwise “fail". If a student fails in a subject, he or she
must reappear in that subject next year to achieve the required percentage.

The requirement is to develop a system that will manage information about subjects offered in different semesters,
students enrolled in different semesters, electives opted by the students and marks obtained by the students in
different semesters. The system should also have the ability to generate mark sheet for each student semester-wise.

Semester-wise detailed marks list and student performance report also need to be generated as well.

CONCLUSION: Problem statement of STUDENT RESULT MANAGEMENT SYSTEM has been written successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 2

AIM: Write the software requirement specification document for RESULT MANAGEMENT SYSTEM.

REQUIREMENTS:

1. SOFTWARE REQUIREMENT – Microsoft Word

2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU i. It provides feedback to the customer.
ii. It decomposes the problem into component parts.
iii. It serves as an input to the design specification.
iv. It serves as a product validation check.
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 is the portability, correctness, maintainability, security, etc. considerations?

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.

Well-designed, well-written SRS accomplishes four major goals:

i. It provides feedback to the customer.
ii. It decomposes the problem into component parts.
iii. It serves as an input to the design specification.
iv. It serves as a product validation check.

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 is the portability, correctness, maintainability, security, etc. considerations?

PROCEDURE:
IEEE Standard SRS Template

1. INTRODUCTION
This document aims at defining the overall software requirements for STUDENT RESULT
MANAGEMENT SYSTEM. Efforts have been made to define the requirements exhaustively and
accurately. The final product will contain the features/functionality mentioned in this document.
1.1 PURPOSE
This specification document describes the capabilities that will be provided by the software
application STUDENT RESULT MANAGEMENT SYSTEM. It also states the various required
constraints by which the system will abide. The intended audiences for this document are the
development team, testing team and end users of the product.
1.2 SCOPE

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
The software product STUDENT RESULT MANAGEMENT SYSTEM will be an MIS and
Reporting application that will be used for result preparation and management of B. Tech
Program of a University. The application will manage the information about various students
enrolled in this course in different years, the subjects offered during different semesters of the
course, the students’ choices for opting different subjects, and the marks obtained by various
students in various subjects in different semesters.
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
Following abbreviations have been used throughout this document: -
B. Tech Bachelor of Technology
CSE Computer Science Engineering
IT Information Technology
EEE Electrical and Electronic Engineering
ECE Electronics and Communication Engineering
DBA Database Administrator
SRMS Student Result Management System

1.4 REFERNECES
(i) University website: For information about course structure of B. Tech Program
(ii) IEEE Recommended Practice for Software Requirement Specifications – IEEE Std 830-1993

1.5 OVERVIEW
The rest of this SRS document describes the various system requirements, interfaces, features and
functionalities in detail.
2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
Online Student Result Management System this software is used to maintain and manage the
result of the student. This software helps the user to easy access the result of students. This
software is also helpful for the administrator because he can easily bring changes to the records of
the student.
2.1.1 HARDWARE
INTERFACESServer Side
The web application will be hosted on one of the department’s Linux servers and
connecting to one of the school Oracle Database servers. The web server is listening on
the web standard port, port 80.
Client Side
The system is a web-based application; clients are requiring using a modern web browser
such as Mozilla Firebox 1.5, Internet Explorer 6 and Enable Cookies. The computer must
have an Internet connection in order to be able to access the system
2.1.2 USER INTEFACES
All pages of the system are following a consistent theme and clear structure. The
occurrence of errors should be minimized through the use of checkboxes, radio buttons
and scroll down in order to reduce the amount of text input from user. JavaScript
implement in HTML in order to provide a Data Check before submission. HTML Tables
to display result to give a clear structure that easy to understand by user. Error message
should be located beside the error input which clearly highlight and tell user how to solve
it. If system error, it should provide the contact methods. The System should provide a
feedback form for all users to give comments or asking questions. It should provide a
FAQ to minimize the workload of system administrator.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
2.1.3 SOFTWARE
INTERFACESServer Side
The UOP already has the required software to host a Java web application. An Apache

Webserver will accept all requests from the client and forward SUMS specific requests to
Tomcat 5.5Servlet Container with J2EE 5.0 and Strut 1.2.8 hosting SUMS. A development
database will be hosted locally (using MySQL); the production database is hosted centrally
(using Oracle).
Client Side
An OS is capable of running a modern web browser which supports HTML version 3.2 or
higher.
2.2 USER CHARACTERISTICS
The users of the system are students, teachers and the administrators who maintain the system. The
users are assumed to have basic knowledge of the computers and Internet browsing. The
administrators of the system to have more knowledge of the internals of the system and is able to
rectify the small problems that may arise due to disk crashes, power failures and other catastrophes
to maintain the system. The proper user interface, user’s manual, online help and the guide to install
and maintain the system must be sufficient to educate the users on how to use the system without
any problems.
2.3 GENERAL CHARACTERISTICS
The result of all the users must be stored in a database that is accessible by the Online Student
Result Management System. The university result security system must be compatible with the
Internet applications. The Online Student Result Management System is connected to the
university computer and is running all 24 hours a day. The users must have their correct
usernames and passwords to enter into the Online Student Result Management.
2.4 ASSUMPTIONS AND DEPENDENCIES
The users have sufficient knowledge of computers. The University computer should have
Internet connection and Internet server capabilities. The users know the English language, as the
user interface will be provided in English. The product can access the university student
database.
3. FUNCTIONAL DESCRIPTION
3.1 FUNCTIONALITY
3.1.1 LOGIN CAPABILITIES
The system shall provide the users with login capabilities.
3.1.2 MOBILE DEVICES
The Online Student Result Management System is also supported on mobile devices such as
cell phones.
3.1.3 ALERTS
The system can alert the administrator in case of any problems.
3.1.4 USABILITY
The system shall allow the users to access the system from the Internet using HTML or its
derivative technologies. The system uses a web browser as an interface. Since all users
are familiar with the general usage of browsers, no specific training is required. The
system is user friendly and self-explanatory.
3.2 RELIABILITY
The system has to be very reliable due to the importance of data and the damages incorrect
or incomplete data can do.
3.3 AVAILABILITY

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
The system is available 100% for the user and is used 24 hrs a day and 365 days a year. The system

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
shall be operational 24 hours a day and 7 days a week.
3.4 MEAN TIME BETWEEN FAILURES (MTBF)
The system will be developed in such a way that it may fail once in a year.
3.5 MEAN TIME TO REPAIR (MTTR)
Even if the system fails, the system will be recovered back up within an hour or less.

3.6 ACCURACY
The accuracy of the system is limited by the accuracy of the speed at which the employees of the
library and users of the library use the system.
3.7 MAXIMUM BUGS OR DEFECT RATE
Not specified.
3.8 ACCESS RELIABILITY
The system shall provide 100% access reliability.
4. PERFORMANCE
RESPONSE
TIME
The Splash Page or Result page should be able to be downloaded within a minute using a 56K modem.The
result is refreshed every two minutes. The access time for a mobile device should be less than a minute.
The system shall respond to the member in not less than two seconds from the time of the request
submittal. The system shall be allowed to take more time when doing large processing jobs.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 3
AIM: Draw use case diagram through the software Start UML.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, Star UML
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:
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. The main purpose of a use case diagram is to portray the
dynamic aspect of a system. It accumulates the system's requirement, which includes both internal as well as
external influences.
Notations of Use Case Diagram:
1. Usecases
A use case describes a function that a system performs to achieve the user’s goal. A use case must yield an
observable result that is of value to the user of the system.
2. Actors
An actor represents a role of a user that interacts with the system that you are modelling. The user can be a
human user, an organization, a machine, or another external system.
3. Subsystems
In UML models, subsystems are a type of stereotyped component that represent independent, behavioural
units in a system. Subsystems are used in class, component, and use-case diagrams to represent large-scale
components in the system that you are modelling.
4. Relationshipsin use-case diagrams
In UML, a relationship is a connection between model elements. A UML relationship is a type of model
element that adds semantics to a model by defining the structure and behaviour between the model elements.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

CONCLUSION: Use Case Description of STUDENT RESULT MANAGEMENT SYSTEM has been
written successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 4
AIM: Draw the data flow diagrams at Level 0 and Level 1 for STUDENT RESULT MANAGEMENT
SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

Data flow diagram (DFD) is a diagram being used frequently in software design. It visually represents the
flow of data throughout processes in a given system. DFD shows the kind of information that will be input
to and output from processes as well as where the data will be stored. A typical information system involves
processing a lot of information and processes. The purpose of Data Flow Diagrams is to view systems as a
whole with its scopes and boundaries while it illustrates the movement of information between components.
The focus of DFD is on the flow of data throughout the system, not process flow. DFD allows readers to
easily see how the system will operate by knowing the kind and flow of information involved. Unlike other
diagrams, DFD can be drawn at different levels, based on the purpose they are drawn to serve.
Context Data Flow Diagram:
Context DFD is sometimes referred to as level 0 DFD. It’s the top-level diagram among all, which illustrates
the entire system in its relationship to any external entities.

Data Flow Diagram Level 1:

Level 1 DFD is the level under the context-DFD. It illustrates the main functions within the system. Level 1
breakdown the context level by including more details. It represents how the data enters and exits the
system, where it is stored and how the basic processes convert it from one form to another.

DFD Diagram Notations

External Entity
An external entity can represent a human, system or subsystem. It is where certain data comes from or goes
to. It is external to the system we study, in terms of the business process. For this reason, people used to
draw external entities on the edge of a diagram.
Process
A process is a business activity or function where the manipulation and transformation of data take place. A
process can be decomposed to a finer level of details, for representing how data is being processed within
the process.
Data Store
A data store represents the storage of persistent data required and/or produced by the process. Here are some
examples of data stores: membership forms, database tables, etc.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
Data Flow
A data flow represents the flow of information, with its direction represented by an arrowhead that shows at
the end(s) of flow connector.

Level 0 : Data Flow Diagram .

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

Level 1 : Data Flow Diagram .

CONCLUSION: Level – 0 and Level – 1 Data Flow Diagram (DFD) for STUDENT RESULT
MANAGEMENT SYSTEM have been drawn successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 5
AIM: To draw the Activity diagram for STUDENT RESULT MANAGEMENT SYSTEM
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential, branched, or
concurrent. Activity diagrams deal with all type of flow control by using different elements such as fork,
join, etc.
The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic
behaviour of the system. Other four diagrams are used to show the message flow from one object to another
but activity diagram is used to show message flow from one activity to another.
It does not show any message flow from one activity to another. Activity diagram is sometimes considered
as the flowchart. Although the diagrams look like a flowchart, they are not. It shows different flows such as
parallel, branched, concurrent, and single.

Symbol Name Use

Start/ Initial Used to represent the starting point or the initial

Node state of an activity

Activity / Used to represent the activities of the process

Action State

Action Used to represent the executable sub-areas of

an activity

Control Used to represent the flow of control from

Flow / one action to the other
Edge

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

Object Flow Used to represent the path of objects

/ Control moving through the activity
Edge

Activity Used to mark the end of all control flows

Final Node within the activity

Flow Final Used to mark the end of a single control flow

Node

Decision Used to represent a conditional branch point

Node with one input and multiple outputs

Merge Node Used to represent the merging of flows. It

has several inputs, but one output.

Fork Used to represent a flow that may branch into

two or more parallel flows

Merge Used to represent two inputs that merge into

one output

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

CONCLUSION: Activity diagram for STUDENT RESULT MANAGEMNT SYSTEM have been drawn
successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 6
AIM: To draw the Sequence diagram for ATM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

A sequence diagram simply depicts interaction between objects in a sequential order i.e., the order in which
these interactions take place. We can also use the terms event diagrams or event scenarios to refer to a
sequence diagram. Sequence diagrams describe how and in what order the objects in a system function.
These diagrams are widely used by businessmen and software developers to document and understand
requirements for new and existing systems.
Sequence Diagram Notations –
1. Actors – An actor in a UML diagram represents a type of role where it interacts with the system and its
objects. It is important to note here that an actor is always outside the scope of the system we aim to model
using the UML diagram. We use actors to depict various roles including human users and other external
subjects.
2. Lifelines – A lifeline is a named element which depicts an individual participant in a sequence diagram.
So basically, each instance in a sequence diagram is represented by a lifeline. Lifeline elements are located
at the top in a sequence diagram.
3. Messages – Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline. We represent messages using arrows. Lifelines and messages form the core
of a sequence diagram. Messages can be broadly classified into the following categories:
Synchronous messages – A synchronous message waits for a reply before the interaction can move
forward. The sender waits until the receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the previous message i.e., it receives a reply
message.
Asynchronous Messages – An asynchronous message does not wait for a reply from the receiver. The
interaction moves forward irrespective of the receiver processing the previous message or not.
Self-Message – Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U-shaped arrow.
Reply Message – Reply messages are used to show the message being sent from the receiver to the sender.
We represent a return/reply message using an open arrowhead with a dotted line. The interaction moves
forward only when a reply message is sent by the receiver.
4. Guards – To model conditions we use guards in UML. They are used when we need to restrict the flow of
messages on the pretext of a condition being met. Guards play an important role in letting software
developers know the constraints attached to a system or a particular process.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

CONCLUSION: Sequence diagram for ATM have been drawn successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 7
AIM: To draw the Sequence diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

CONCLUSION: Sequence diagram for STUDENT RESULT MANAGEMNT SYSTEM have been drawn
successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 8
AIM: To draw the Class Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

CONCLUSION: Class diagram for STUDENT RESULT MANAGEMNT SYSTEM have been drawn
successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 9
AIM: To draw the Collaboration Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

The collaboration diagram is used to show the relationship between the objects in a system. Both the
sequence and the collaboration diagrams represent the same information but differently. Instead of showing
the flow of messages, it depicts the architecture of the object residing in the system as it is based on object-
oriented programming. An object consists of several features. Multiple objects present in the system are
connected to each other. The collaboration diagram, which is also known as a communication diagram, is
used to portray the object's architecture in the system.
Notations of a Collaboration Diagram:
1. Objects: The representation of an object is done by an object symbol with its name and class
underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
The object is represented by specifying their name and class.
It is not mandatory for every class to appear.
A class may constitute more than one object.
In the collaboration diagram, firstly, the object is created, and then its class is specified.
To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the interaction. Each actor
has its respective role and name. In this, one actor initiates the use case.
3. Links: The link is an instance of association, which associates the objects and actors. It portrays a
relationship between the objects through which the messages are sent. It is represented by a solid line. The
link helps an object to connect with or navigate to another object, such that the message flows are attached
to links.
4. Messages: It is a communication between objects which carries information and includes a sequence
number, so that the activity may take place. It is represented by a labelled arrow, which is placed near a link.
The messages are sent from the sender to the receiver, and the direction must be navigable in that particular
direction. The receiver must understand the message.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

CONCLUSION: Collaboration diagram for STUDENT RESULT MANAGEMNT SYSTEM have been
drawn successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
EXPERIMENT- 10
AIM: To draw the State Chart Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, MS Paint
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:

The state machine diagram is also called the Statechart or State Transition diagram, which shows the order
of states underwent by an object within the system. It captures the software system's behaviour. It models the
behaviour of a class, a subsystem, a package, and a complete system.
It tends out to be an efficient way of modelling the interactions and collaborations in the external entities and
the system. It models event-based systems to handle the state of an object. It also defines several distinct
states of a component within the system. Each object/component has a specific state.
Notation of a State Machine Diagram:
1. Initial state: It defines the initial state (beginning) of a system, and it is represented by a black filled circle.
2. Final state: It represents the final state (end) of a system. It is denoted by a filled circle present within a
circle.
3. Decision box: It is of diamond shape that represents the decisions to be made on the basis of an evaluated
guard.
4. Transition: A change of control from one state to another due to the occurrence of some event is termed
as a transition. It is represented by an arrow labelled with an event due to which the change has ensued.
5. Statebox: It depicts the conditions or circumstances of a particular object of a class at a specific point of
time. A rectangle with round corners is used to represent the state box.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

CONCLUSION: State chart diagram for STUDENT RESULT MANAGEMNT SYSTEM have
been drawn successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
Experiment No. 13

AIM: To draw the Component Diagram for STUDENT RESULT MANAGEMENT SYSTEM and
ORDERING SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:
A component diagram is used to break down a large object-oriented system into the smaller components,
so as to make them more manageable. It visualizes the relationships as well as the organization between
the components present in the system. It helps in forming an executable system. A component is a
single unit of the system, which is replaceable and executable.
Notations:
1. Component: A component is a physical and replaceable part of the system that provides or uses set
of interfaces. A component is shown as a rectangle with tabs.
2. Interfaces: A component can be connected with other components through interfaces. An interface is
a collection of operations that are used to specify services of components. A component can provide
an interface or can use services of a component.
3. Dependencies: A dependency exists between two elements. Changes to the definition of one
elementmay cause changes to the other. It is represented as dashed line with an arrow.
4. Realization: A component realizes an interface by providing service through interface. It is
indicatedwith a dashed line and a hollow arrow head.
5. Artifacts: It is used to record keeping for further reference. Attributes and operations can be
added to the artifacts.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab

CONCLUSION: Component diagram for STUDENT RESULT MANAGEMNT SYSTEM

and ORDERING SYSTEM have been drawn successfully.

Jay Chugh
05815603120
T-7
ADGITM Software Engineering Lab
Experiment No. 14

AIM: To draw the Deployment Diagram for STUDENT RESULT MANAGEMENT SYSTEM.
REQUIREMENTS:
1. SOFTWARE REQUIREMENT – Microsoft Word, Rational Rose Enterprise Edition
2. HARDWARE REQUIREMENT – Computer, Keyboard, Mouse, CPU

THEORY:
A deployment diagram is a UML diagram type that shows the execution architecture of a system,
including nodes such as hardware or software execution environments, and the middleware connecting
them. Deployment diagrams are typically used to visualize the physical hardware and software of a
system. Using it you can understand how the system will be physically deployed on
the hardware. Deployment diagrams help model the hardware topology of a system compared to other UML
diagram types which mostly outline the logical components of a system.
Notations:
1. Node: A node, represented as a cube, is a physical entity that executes one or more components, subsystems
or executables. A node could be a hardware or software element.
2. Artifacts: Artifacts are concrete elements that are caused by a development process. Examples of artifacts
are libraries, archives, configuration files, executable files etc.
3. Communication Association: This is represented by a solid line between two nodes. It shows the path of
communication between nodes.

CONCLUSION: Deployment diagram for STUDENT RESULT MANAGEMNT SYSTEM have

beendrawn successfully.

Jay Chugh
05815603120
T-7