SVKM’s NMIMS

School of Technology Management and Engineering,

Kharghar, Navi-Mumbai-410210

Academic Year-2020-21
Department of Electronics & Telecommunication
Programme: B.Tech(Integrated)- Computer
Year-II, Semester- IV
Course: Software Design with UML

COURSE FACULTY

Tejaswini Chavan
 Index

Sr.No Title Page No.

1 Student Outcomes/ Programme Outcomes 3

2 Course Outcomes 4

3 Mapping of Course Outcomes with Student Outcomes/ 4

Programme Outcomes

4 Mapping of Lab Experiments to Course Outcomes 5

5 Lab Manual 6
 Student Outcomes

Graduates of the Computer Engineering program will have an ability to:

1. Identify, formulate, and solve complex engineering problems by applying principles of

engineering, science, and mathematics.

2. Apply engineering design to produce solutions that meet specified needs with consideration
of public health, safety, and welfare, as well as global, cultural, social, environmental, and
economic factors.

3. Communicate effectively with a range of audiences.

4. Recognize ethical and professional responsibilities in engineering situations and make

informed judgments, which must consider the impact of engineering solutions in global,
economic, environmental, and societal contexts.

5. Function effectively on a team whose members together provide leadership, create a

collaborative and inclusive environment, establish goals, plan tasks, and meet objectives.

6. Develop and conduct appropriate experimentation, analyze and interpret data, and use
engineering judgment to draw conclusions.

7. Acquire and apply new knowledge as needed, using appropriate learning strategies.
Course Outcomes:

CO-1 Understand unified process.

CO-2 Design UML for the given problem statement.

CO-3 Analyse the product using testing methodologies

CO-4 Apply project management skills to manage the project.

Mapping of Course Outcomes with student Outcomes:

Mapping SO-1 SO-2 SO-3 SO-4 SO-5 SO-6 SO-7

CO-1 M
CO-2 H M

CO-3 H

CO-4 M H M
 SVKM’s NMIMS
School of Technology Management & Engineering
Computer Engineering Department
Program: B.Tech CSBS

Course: Object Oriented Software Engineering

List of Experiments

Faculty: Prof. Tejaswini Chavan

CO-1 Understand unified process.

CO-2 Design UML for the given problem statement.
CO-3 Analyse the product using testing methodologies.
CO-4 Apply project management skills to manage the project.

Exp Title Prerequisite* CO#

No.

1 Learning the StarUML environment Concepts of Software

and Identifying a problem statement Engineering Model
for preparation of SRS document
using structured approach and CO1
understand different phases of
unified process of object oriented
software engineering.

2. Modeling UML Use Case diagrams Concepts of Actor, Use Case

and capturing Use Case scenarios. and Relationships CO2

3. To draw the behavioral view diagram: Determine the desired flow of

Sequence diagram, Collaboration action and their interaction
diagram with each other CO2

4. To draw the behavioral view diagram: Concepts of Actor, Use Case

Activity diagram and Relationships CO2

5. To draw the structural view diagram: Concepts of objects and class

Class diagram, object diagram. Learn
the object-oriented analysis phase by
CO3
understanding the methods of class
elicitation and finding the classes in
an object-oriented system.
6. To draw the state chart diagram. Concepts of behavioral model,
states CO3

7. To draw the Component diagram Concepts of Class Diagram CO3

8. To draw the Deployment diagram Requirement gathering, CO4
infrastructure of the client site

9. Coding for any Two module of your Code, understanding about CO4
project selected according to the unit testing, integration testing
designs which already designed and
analyzed in EXP.1-7
10. To understand and develop test cases Function point, COCOMO CO4
for object oriented systems. model
 PART A
EXPERIMENT NO. 1
A.1 AIM: - Learning the Star UML environment.
A.2 Prerequisite
1. Concepts of Software Engineering, Process Model
A.3 Outcome
After successful completion of this training students will be able to use Star
UML for creating the UML model with respect to given case study.
Design solution using unified modeling language.

A.4 Task:
Every student needs to follow following steps and record the findings
in appropriate section of PART B

1. Download Star UML software in your machine and Prepare necessary documentation
for doing hands on with Star UML.
2. Select the appropriate case study to design UML diagrams.
3. Identify the Scope of the problems selected
4. Identify the end user of the solution
5. Identify the functional requirements of the project
6. Identify the non-functional requirements of the project
7. Identify the feasibility of the project(Economical feasibility)
8. Frame the final problem statement.
9. List down the list of user requirements, system requirements.
10. Identify the ambiguities, inconsistencies, incompleteness from the requirements
gathered.
11. List down the development plan for the selected problem
statements- SDLC(Software development life cycle)
 PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.1 About Star UML

B.2 Problem Statement of the Case Study Selected
Library users require an efficient method to find a specific book or keyword(s) within a book
given a continuously expanding library

B.3 Conclusion
We learned about and how to use Star UML software.

B.4 Question of curiosity:

1. Justify the statement, “ User requirements must be understood well before beginning
the software development”

A. Understanding user requirements helps to ensure that the software development

project meets the needs of the end-users. By identifying the needs and
expectations of the users, developers can design software that addresses those
needs and is useful and usable for the target audience. This can help increase user
satisfaction and adoption of the software, leading to better overall outcomes for
the project.

2. What is SRS? Download sample IEEE SRS format and prepare the relevant part of
the same for this experiment

Purpose, Scope, Functional and Non-functional Requirements

A. SRS stands for Software Requirements Specification, which is a document that

outlines the functional and non-functional requirements for a software system. It
 serves as a blueprint for the development team, providing a detailed description of
what the software should do, how it should perform, and what features it should have.

3. What is feasibility study? When is the feasibility study done?

A. A feasibility study is an analysis of the viability and potential success of a

proposed project or business venture. It is done to determine whether the project is
technically, financially, and operationally feasible.

4. Differentiate between functional requirements and nonfunctional requirements

A. Functional requirements are the specific tasks and functions that the software must
perform to meet the user's needs. They define what the software should do and how it
should behave. Examples of functional requirements include user authentication, data
processing, report generation, and error handling.

Nonfunctional requirements, on the other hand, define the characteristics and

properties of the software that are not related to its specific functions. They describe
how the software should perform and how it should meet the user's expectations.
Examples of nonfunctional requirements include performance, usability, reliability,
security, and maintainability.

PART A
EXPERIMENT NO. 2
A.1 AIM: - Modeling UML Use Case diagrams and capturing Use Case scenarios.
A.2 Prerequisite
Concepts of Actor, Use Case and Relationships
A.3 Outcome
After successful completion of this experiment students will be able to
Design solution using unified modeling language.

A.4 Theory
Use case diagrams
Use case diagrams belong to the category of behavioral diagram of UML diagrams. Use case
diagrams aim to present a graphical overview of the functionality provided by the system. It
consists of a set of actions (referred to as use cases) that the concerned system can perform,
one or more actors, and dependencies among them.

Actor
An actor can be defined as an object or set of objects, external to the system, which interacts
with the system to get some meaningful work done. Actors could be human, devices, or even
other systems.
For example, consider the case where a customer withdraws cash from an ATM. Here,
customer is a human actor.
Actors can be classified as below :
• Primary actor: They are principal users of the system, who fulfill their goal by availing
some service from the system. For example, a customer uses an ATM to withdraw cash
when he needs it. A customer is the primary actor here.
• Supporting actor: They render some kind of service to the system. "Bank
representatives", who replenishes the stock of cash, is such an example. It may be noted
that replenishing stock of cash in an ATM is not the prime functionality of an ATM.

In a use case diagram primary actors are usually drawn on the top left side of the diagram.
Use Case
A use case is simply a functionality provided by a system. Continuing with the example of the
ATM, withdraw cash is a functionality that the ATM provides. Therefore, this is a use case.
Other possible use cases includes, check balance, change PIN, and so on.
Use cases include both successful and unsuccessful scenarios of user interactions with the
system. For example, authentication of a customer by the ATM would fail if he enters wrong
PIN. In such case, an error message is displayed on the screen of the ATM.
Subject
Subject is simply the system under consideration. Use cases apply to a subject. For example,
an ATM is a subject, having multiple use cases, and multiple actors interact with it. However,
one should be careful of external systems interacting with the subject as actors.
Graphical Representation
An actor is represented by a stick figure and name of the actor is written below it. A use case
is depicted by an ellipse and name of the use case is written inside it. The subject is shown by
drawing a rectangle. Label for the system could be put inside it. Use cases are drawn inside the
rectangle, and actors are drawn outside the rectangle, as shown in below figure:
Association between Actors and Use Cases
A use case is triggered by an actor. Actors and use cases are connected through binary
associations indicating that the two communicates through message passing.
An actor must be associated with at least one use case. Similarly, a given use case must be
associated with at least one actor. Association among the actors are usually not shown.
However, one can depict the class hierarchy among actors.

Use Case Relationships

Three types of relationships exist among use cases:
• Include relationship
• Extend relationship
• Use case generalization

Include Relationship
Include relationships are used to depict common behaviour that are shared by multiple use
cases. This could be considered analogous to writing functions in a program in order to avoid
repetition of writing the same code. Such a function would be called from different points
within the program.

Example
For example, consider an email application. A user can send a new mail, reply to an email he
has received, or forward an email. However, in each of these three cases, the user must be
logged in to perform those actions. Thus, we could have a login use case, which is included
bycompose mail, reply, and forward email use cases. The relationship is shown in below
figure.
Extend Relationship
Use case extensions are used used to depict any variation to an existing use case. They are used
to specify the changes required when any assumption made by the existing use case becomes
false.
Example
Let's consider an online bookstore. The system allows an authenticated user to buy selected
book(s). While the order is being placed, the system also allows to specify any special shipping
instructions, for example, call the customer before delivery. This Shipping Instructionsstep is
optional, and not a part of the main Place Order use case. Below figure depicts such
relationship.

Place Order

<<extends>>

Shipping
Instruction
Generalization Relationship
Generalization relationship are used to represent the inheritance between use cases. A derived
use case specializes some functionality it has already inherited from the base use case.

Example
To illustrate this, consider a graphical application that allows users to draw polygons. We could
have a use case draw polygon. Now, rectangle is a particular instance of polygon having four
sides at right angles to each other. So, the use case draw rectangle inherits the properties of the
use case draw polygon and overrides it's drawing method. This is an example of generalization
relationship. Similarly, a generalization relationship exists between draw rectangle and draw
square use cases.

A.5 Task:
For the problem statement, complete use case modelling in StarUML.

PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2
 Date of Experiment: - Date of Submission:

Grade:

B.1 Actors:

B.2 Use cases:

Request book, reserve a book, pay fine, renew book, add records, update database, track fine

B.3 Use Case diagrams:

B.4 Use Case Specifications:

B.5 Conclusion
We completed use case modelling in star UML.

B.5 Questions of Curiosity:

Q1. What does a use case diagram represent?

a. A set of actions
b. Time sequence of statements executed
c. How to use a particular module
d. Don’t know

Answer: a. A set of actions

Q.2 Generalization relationship exists between two use cases when

a. A use case derives from a base use case.

b. A use case derives from a base use case and specializes some of its inherited
functionality.
c. A use case include functionality of some other use case.
d. No two use cases can be related.

Answer:_ b. A use case derives from a base use case and specializes some of its inherited
functionality.
 PART A
EXPERIMENT NO. 3
A.1 AIM: - To draw the behavioral view diagram: Sequence diagram, Collaboration
diagram
A.2 Prerequisite
Determine the desired flow of action and their interaction with each other
A.3 Outcome
After successful completion of this experiment students will be able to -
1. Better understanding of the interaction diagrams.
2. Get familiar with sequence & collaboration diagrams.
3. Practice drawing the interaction diagrams using StarUML

A.4 Theory
Interaction diagrams describe how groups of objects collaborate in some behavior. An
interaction diagram typically captures the behavior of a single use case. Interaction diagrams
do not capture the complete behavior, only typical scenarios.
Diagram is used to describe some type of interactions among the different elements in the
model. Interaction is part of the dynamic behavior of the system – snapshot of running system
at a particular moment. Sequence diagram emphasizes on time sequence of messages
collaboration diagram emphasizes on the structural organization of the objects that send and
receive messages.
For sequence diagram things to be identified:

– Objects taking part in the interaction – three types of objects – Entity, Control, Boundary
objects
– Message flow among objects
– The sequence in which messages are flowing
– Object organization

Sequence Diagram -
Sequence diagrams are a graphical way to illustrate a scenario:

• They are called sequence diagrams because they show the sequence of message
passing between objects.
• Another big advantage of these diagrams is that they show when the objects are
created and when they are destructed. They also show whether messages are
synchronous or asynchronous

Collaboration Diagram -
They are the same as sequence diagrams but without a time axis:

• Their message arrows are numbered to show the sequence of message sending.
• They are less complex and less descriptive than sequence diagrams.
• These diagrams are very useful during design because you can figure out how objects
communicate with each other.

A.5 Procedure/Algorithm
A.5.1 Task:
Draw a sequence diagram for the case study.

• Identify objects – entity, control, boundary objects

• Identify messages between objects.
 PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.1 Objects

Entity objects:
Boundary objects:
Control objects:

B.2 Sequence diagram:

B.3 Collaboration diagram:

B.4 Conclusion
We drew the behavioral view diagrams: Sequence diagram and Collaboration diagram.
B.5 Questions of Curiosity:
Q1. State the difference between entity, boundary and control objects.
A. Entity objects represent the data or information that is being manipulated or processed by the
system. They typically correspond to the nouns in a problem domain and are often used to represent
persistent data that needs to be stored or retrieved from a database. Examples of entity objects
might include Customer, Order, or Invoice.

Boundary objects represent the interaction between the system and its environment, such as
the user interface or other external systems. They are responsible for input/output operations
and for presenting information to the user. Examples of boundary objects might include a
web form, a report, or a dialog box.
Control objects represent the logic and control flow of the system. They are responsible for
coordinating the interaction between the entity and boundary objects, and for implementing
the business rules that govern the system's behavior. Examples of control objects might
include a controller, a manager, or a process.

Q.2 State the difference between sequence and collaboration diagram.

A. Sequence diagrams illustrate the interactions between objects in a system over time. They show
the order in which messages are sent between objects and the sequence of actions that take place
as a result. Sequence diagrams are often used to model the dynamic behavior of a single use case or
scenario.

Collaboration diagrams, on the other hand, show the relationships between objects in a
system and the messages that are passed between them to accomplish a specific task.
Collaboration diagrams are more focused on the static relationships between objects and how
they work together to achieve a common goal.

Q.3 When looping is required in sequence diagram?

A. Looping is used in sequence diagrams to represent situations where a particular interaction
or sequence of interactions needs to be repeated a certain number of times, or until a certain
condition is met

B.6 Conclusion
We drew the behavioral view diagrams: Sequence diagram, Collaboration diagram
 PART A
EXPERIMENT NO. 4
A.1 AIM: - Modeling UML Class diagrams.
A.2 Prerequisite
Concepts of Actor, Use Case and Relationships, Sequence and collaboration
diagram
A.3 Outcome
After successful completion of this experiment students will be able to
Design solution using unified modeling language.

A.4 Task:

Complete Class Diagram in Star UML.

PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

 Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.1 Design the class diagram

B.4 Conclusion
We modelled the class diagram on Star UML.

B.5 Questions of Curiosity:

Q1. A company consists of departments. Departments are distributed all over India. Each
department has a manager. Department manager manages all the employees.
Design a class diagram, considering appropriately.
 PART A
EXPERIMENT NO. 5
A.1 AIM: - To draw the behavioral view diagram: Activity diagram
A.2 Prerequisite
Determine the desired flow of action and their interaction with each other
A.3 Outcome
After successful completion of this experiment students will be able to -

4. Better understanding of the interaction diagrams.

5. Get familiar with Activity diagram
6. Practice drawing the interaction diagrams using StarUML

A.4 Theory
Activity diagrams are flow charts that are used to show the workflow of a system.
They also:

• Represent the dynamics of the system.

• Show the flow of control from activity to activity in the system.
• Show what activities can be done in parallel, and any alternate paths through the flow.
Activity diagrams may be created to represent the flow across use cases or they may be created
to represent the flow within a particular use case. Later in the life cycle, activity diagrams may
be created to show the workflow for an operation.

Activity diagram notations:

• Rounded rectangles represent activities

Activity1

• Diamonds represent decisions

• A black circle represents the start (initial state) of the work-flow

• An encircled black circle represents the end (final state).

• Swimlane (vertical)
 • Swimlane (horizontal): Swim lane- depicts which human organization is responsible
for an activity. Organization – sales, finance, marketing, purchasing etc. Swim lane
indicates that activity is performed by a person or persons within the organization.

Swimlane1

Swimlane2

• Bars represent the start (split) or end (join) of concurrent activities

Activity diagram for uploading photograph:

Activity diagram for stock trading processing:

Activity diagram using swimlane:

A.5. Task:
Draw an activity diagram for the case study.

PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.1 Activity diagram

B.2 Conclusion
We designed the behavioral view diagram: Activity diagram on Star UML.

B.5 Questions of Curiosity:

Q1. What is the primary purpose of activity diagram?
A. Activity diagrams are used to model and represent the flow of activities and actions within
a system or process. The primary purpose of an activity diagram is to visualize the workflow
or business process, and to provide a clear, concise and easy-to-understand representation of
how the system or process operates.

Q.2 State the difference between branches and fork and join in activity diagram.
A. For the branching of flows in two or more parallel flows we use a synchronization bar,
which is depicted as a thick horizontal or vertical line i.e. frok, on the other hand, for the
consolidation of two or more parallel flows we also use a synchronization bar, which is
depicted as a thick horizontal or vertical line i.e. join.

PART A
EXPERIMENT NO. 6
A.1 AIM: - To draw the State Diagram
A.2 Prerequisite
Determine the State Diagram for the case study.
A.3 Outcome
After successful completion of this experiment students will be able to -
Draw the state diagrams using StarUML

A.4 Procedure/Algorithm
A.4.1 Task:
Draw a state diagram for the case study.

PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.1 State Diagram

B.4 Conclusion
We drew the state diagram.

PART A
EXPERIMENT NO. 7
A.1 AIM: - To draw Component Diagram

A.2 Outcome
After successful completion of this experiment students will be able to –
Practice drawing the component and deployment diagram using StarUML

A.3 Theory
This exercise focuses on component diagram, which depict the implementation of a
system.
Component modeling is a specialized type of structural modeling concerned with
modeling the implementation of a system. Using the UML, you can communicate the
implementation of a system using component diagrams. You usually apply component
modeling during design activities to determine how implementation activities will build
the system; that is, to determine the elements of the system on which implementation
activities will focus. Component modeling typically starts after the design of the system
is fairly complete, as determined by your system development process.
1. Component

A component is a part of the system that exists when the system is executing. For
example, the project management system may be decomposed into the following
components:
A user interface component
Responsible for providing a user interface through which users may interact with
the system
A business-processing component
Responsible for implementing business functionality, including all the project
management functionality provided by the project management system
A data component
For implementing data storage functionality
A security component
Provides various forms of security functionality to the business-processing and data
components, including user authentication and verifying user privileges when
accessing data

You can use the UML to talk about classes of components as well as specific
components of a class. When speaking of a class of components, it's customary to
use the terms component or component class. Thus, while you might think of a
component as a specific thing, in the UML, a component really represents a class
of things. When speaking of a specific component of a class, use the
term component instance.
A component exists during execution time and requires a resource on which to
execute,. In the UML, a component is shown as a rectangle with two small
rectangles protruding from its side. The rectangle is labelled with the name of the
component class.
Figure 1 shows various components associated with the project management
system, including user interface, business-processing, data, and security
components.

Figure 1- Components of the project management system

A component instance is a specific component. For example, specific components

of the project management system include:

A web user interface component instance

Allows users to access the project management system via the Web

A client/server user interface component instance

Allows users to access the project management system in a client/server
environment
A local data component instance
 Stores project management data for a specific user or group of users

An enterprise data component instance

Stores project management data for a complete organization

A component instance is shown similar to a component class, but is labelled with

the component instance name followed by a colon followed by the component class
name, with all parts of the name fully underlined. Both names are optional, and the
colon is present only if the component class name is specified.
Figure 2 shows various component instances of the component classes in Figure 1,
including two user interface component instances, named Web and Client Server,
two data component instances, named Local Data and Enterprise Data, a nameless
business processing component instance, and a nameless security component
instance.

Figure 2- Component instances in the project management system

2. Nodes

A node is a resource that is available during execution time. Traditionally, nodes

refer to computers on a network, but in the UML a node may be a computer, printer,
server, Internet, or any other kind of resource available to components. For
example, the project management system may be deployed on the following nodes:
A desktop client
On which the user interface component executes
A printer
Which the project management system uses to print reports
A business-processing server
On which the business-processing component executes
A database server
On which the data component executes and where project-related information is
stored.
Nodes follow the type-instance dichotomy and applied to classes and objects. You
can use the UML to talk about classes of nodes, as well as specific nodes of a class.
When speaking of a class of nodes, it's customary to use the terms node or node
class. Thus, while you might think of a node as a specific thing, in the UML, a node
really represents a class of nodes. When speaking of a specific component of a class,
use the term node instance.

A node is available during execution time and is a resource on which components

may execute. In the UML, a node is shown as a three-dimensional rectangle labelled
with the node's name.

Figure 3 shows various nodes associated with the project management system,
including a desktop client, business-processing server, database server, and printer
node.

Figure 3- Nodes used by the project management system

A node instance is a specific node. For example, specific nodes used by the
project management system include:

A desktop client node instance

Used by Jonathan to access the project management system

A desktop client node instance

Used by Andy to access the project management system

A group business-processing server node instance

 Used by a group of users to manage projects

An enterprise business-processing server node instance

Used by a complete organization to manage projects
A node instance is shown similarly to a node class but labelled with the node
instance name followed by a colon followed by the node class name, all fully
underlined. Both names are optional, and the colon is present only if the node class
name is specified.

Figure 4 shows various node instances of the node classes in Figure 3, including
two desktop client node instances, named Jonathan's Computer and Andy's
Computer, two business-processing node instances, named Group Server
and Enterprise Server, a printer node instance, named Group Printer, and a database
server node instance.

Figure 4- Node instances

3. Dependencies

Figure 1 shows components associated with the project management system, and
Figure 3 shows nodes associated with the project management system, but how are
components related to undifferentiated and differentiated classes, packages,
subsystems, and to other components and nodes? Specialized types of dependencies
called reside, use, and deploy dependencies address these questions. The next few
sections discuss these specialized types of dependencies.

3.1 Reside Dependencies

A reside dependency from a component to any UML element indicates that the
component is a client of the element, which is itself considered a supplier, and that
the element resides in the component. The element may be an undifferentiated or
differentiated class, package, or subsystem. An element may reside in any number
of components, and a component may have any number of elements that reside in
it.

A reside dependency is shown as a dashed arrow from a client component to a

supplier element marked with the reside keyword.
Figure 5 shows that the User Interface and Utility packages reside in
the User Interface component. Because the User Interface package depends on
the Utility package, the User Interface and Utility packages must reside in the same
component; otherwise, the User Interface package would not be able to use the
Utility package.

Figure 5. Reside dependencies for packages

Figure 6 shows that the Business Processing subsystem and Utility package reside
in the Business Processing component. Because the Business Processing subsystem
provides the IBusiness Processing interface, the Business Processing component
also provides the interface. Again, because the Business Processing subsystem
depends on the Utility package, the Business Processing subsystem
and Utility package must reside in the same component; otherwise,
the Business Processing subsystem would not be able to use the Utility package.
Remember, it's perfectly fine for an element to reside in more than one component.
For example, the Utility package resides in both the User Interface and Business
Processing components, and, as you will soon see, in the Data component.

Figure 6. Reside dependencies for subsystems

Alternatively, an element that resides inside a component may be shown nested
inside the component. Figure 7 shows that the Data subsystem and Utility package
reside in the Data component. The Data subsystem is drawn inside the
Data component, while thereside dependency to Utility is still drawn in the same
manner as in Figures Figure 5 and Figure 6.

Figure 7. Reside dependencies using nesting

Notice that the Utility package resides in all the components in Figures Figure 5,
Figure 6, and Figure 7, because each component described in those figures has a
package that uses the Utility package.

3.2 Use Dependencies

A use dependency from a client component to a supplier component indicates that
the client component uses or depends on the supplier component. A use dependency
from a client component to a supplier component's interface indicates that the client
component uses or depends on the interface provided by the supplier component. A
use dependency is shown as a dashed arrow from a client component to a supplier
component or a supplier component's interface. The dependency may be marked
with the use keyword; however, the keyword is often omitted because this is the
default, and the meaning is evident from how the dependency is used.

Figure 8 shows how the various components of the project management system are
related:

The User Interface component-

Uses the Security component and the IBusinessProcessing interface provided by
the Business Processing component

The Business Processing component-

Uses the Security component and the IProducible and IConsumable interfaces
provided by the Data component

The Data component-

Uses the Security component

Figure 8- Use dependencies

3.3 Deploy Dependencies

A deploy dependency from a client component to a supplier node indicates that the
client component is deployed on the supplier node.

A deploy dependency is shown as a dashed arrow from a client component to a

supplier node marked with the deploy keyword.

Figure 9 shows that the User Interface component is deployed on the Desktop
Client node.

Figure 9- Deploy dependencies

 Figure 10 shows that the Business Processing component is deployed on
the Business-Processing Server node.

Figure 10- Deploy dependencies for a subsystem

Alternatively, a component that is deployed on a node may be shown nested inside

the node. Figure 11 shows that the Data component is deployed on the Database
Server node.

Figure 11- Deploy dependencies using nesting

A.4 Procedure/Algorithm
A.4.1 Task:
For the case study given on black board complete component and deployment model.
 PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.4 Conclusion
We drew the component diagram.

PART A
EXPERIMENT NO. 8

A.1 AIM: - To draw Deployment Diagram

A.2 Outcome
After successful completion of this experiment students will be able to -

7. Practice drawing the deployment diagram using StarUML

A.3 Theroy
This exercise focuses on component diagram, which depict the implementation of a
system.
Component modeling is a specialized type of structural modeling concerned with
modeling the implementation of a system. Using the UML, you can communicate the
implementation of a system using component diagrams. You usually apply component
modeling during design activities to determine how implementation activities will build
the system; that is, to determine the elements of the system on which implementation
activities will focus. Component modeling typically starts after the design of the system
is fairly complete, as determined by your system development process.
4. Component

A component is a part of the system that exists when the system is executing. For
example, the project management system may be decomposed into the following
components:

A user interface component

Responsible for providing a user interface through which users may interact with
the system
A business-processing component
Responsible for implementing business functionality, including all the project
management functionality provided by the project management system

A data component
For implementing data storage functionality

A security component
Provides various forms of security functionality to the business-processing and data
components, including user authentication and verifying user privileges when
accessing data

You can use the UML to talk about classes of components as well as specific
components of a class. When speaking of a class of components, it's customary to
use the terms component or component class. Thus, while you might think of a
component as a specific thing, in the UML, a component really represents a class
of things. When speaking of a specific component of a class, use the
term component instance.

A component exists during execution time and requires a resource on which to

execute,. In the UML, a component is shown as a rectangle with two small
rectangles protruding from its side. The rectangle is labelled with the name of the
component class.

Figure 1 shows various components associated with the project management

system, including user interface, business-processing, data, and security
components.

Figure 1- Components of the project management system

A component instance is a specific component. For example, specific components

of the project management system include:
 A web user interface component instance
Allows users to access the project management system via the Web

A client/server user interface component instance

Allows users to access the project management system in a client/server
environment
A local data component instance
Stores project management data for a specific user or group of users

An enterprise data component instance

Stores project management data for a complete organization

A component instance is shown similar to a component class, but is labelled with

the component instance name followed by a colon followed by the component class
name, with all parts of the name fully underlined. Both names are optional, and the
colon is present only if the component class name is specified.

Figure 2 shows various component instances of the component classes in Figure 1,

including two user interface component instances, named Web and Client Server,
two data component instances, named Local Data and Enterprise Data, a nameless
business processing component instance, and a nameless security component
instance.

Figure 2- Component instances in the project management system

5. Nodes
A node is a resource that is available during execution time. Traditionally, nodes
refer to computers on a network, but in the UML a node may be a computer, printer,
server, Internet, or any other kind of resource available to components. For
example, the project management system may be deployed on the following nodes:
A desktop client
On which the user interface component executes
A printer
Which the project management system uses to print reports
A business-processing server
On which the business-processing component executes
A database server
On which the data component executes and where project-related information is
stored.
Nodes follow the type-instance dichotomy and applied to classes and objects. You
can use the UML to talk about classes of nodes, as well as specific nodes of a class.
When speaking of a class of nodes, it's customary to use the terms node or node
class. Thus, while you might think of a node as a specific thing, in the UML, a node
really represents a class of nodes. When speaking of a specific component of a class,
use the term node instance.
A node is available during execution time and is a resource on which components
may execute. In the UML, a node is shown as a three-dimensional rectangle labelled
with the node's name.
Figure 3 shows various nodes associated with the project management system,
including a desktop client, business-processing server, database server, and printer
node.

Figure 3- Nodes used by the project management system

A node instance is a specific node. For example, specific nodes used by the
project management system include:
A desktop client node instance
 Used by Jonathan to access the project management system
A desktop client node instance
Used by Andy to access the project management system
A group business-processing server node instance
Used by a group of users to manage projects

An enterprise business-processing server node instance

Used by a complete organization to manage projects
A node instance is shown similarly to a node class but labelled with the node
instance name followed by a colon followed by the node class name, all fully
underlined. Both names are optional, and the colon is present only if the node class
name is specified.

Figure 4 shows various node instances of the node classes in Figure 3, including
two desktop client node instances, named Jonathan's Computer and Andy's
Computer, two business-processing node instances, named Group Server
and Enterprise Server, a printer node instance, named Group Printer, and a database
server node instance.

Figure 4- Node instances

6. Dependencies

Figure 1 shows components associated with the project management system, and
Figure 3 shows nodes associated with the project management system, but how are
components related to undifferentiated and differentiated classes, packages,
subsystems, and to other components and nodes? Specialized types of dependencies
called reside, use, and deploy dependencies address these questions. The next few
sections discuss these specialized types of dependencies.

3.1 Reside Dependencies

A reside dependency from a component to any UML element indicates that the
component is a client of the element, which is itself considered a supplier, and that
the element resides in the component. The element may be an undifferentiated or
differentiated class, package, or subsystem. An element may reside in any number
of components, and a component may have any number of elements that reside in
it.

A reside dependency is shown as a dashed arrow from a client component to a

supplier element marked with the reside keyword.

Figure 5 shows that the User Interface and Utility packages reside in
the User Interface component. Because the User Interface package depends on
the Utility package, the User Interface and Utility packages must reside in the same
component; otherwise, the User Interface package would not be able to use the
Utility package.

Figure 5. Reside dependencies for packages

Figure 6 shows that the Business Processing subsystem and Utility package reside
in the Business Processing component. Because the Business Processing subsystem
provides the IBusiness Processing interface, the Business Processing component
also provides the interface. Again, because the Business Processing subsystem
depends on the Utility package, the Business Processing subsystem
and Utility package must reside in the same component; otherwise,
the Business Processing subsystem would not be able to use the Utility package.
Remember, it's perfectly fine for an element to reside in more than one component.
For example, the Utility package resides in both the User Interface and Business
Processing components, and, as you will soon see, in the Data component.
 Figure 6. Reside dependencies for subsystems

Alternatively, an element that resides inside a component may be shown nested

inside the component. Figure 7 shows that the Data subsystem and Utility package
reside in the Data component. The Data subsystem is drawn inside the
Data component, while thereside dependency to Utility is still drawn in the same
manner as in Figures Figure 5 and Figure 6.

Figure 7. Reside dependencies using nesting

Notice that the Utility package resides in all the components in Figures Figure 5,
Figure 6, and Figure 7, because each component described in those figures has a
package that uses the Utility package.

3.2 Use Dependencies

A use dependency from a client component to a supplier component indicates that
the client component uses or depends on the supplier component. A use dependency
from a client component to a supplier component's interface indicates that the client
component uses or depends on the interface provided by the supplier component. A
use dependency is shown as a dashed arrow from a client component to a supplier
component or a supplier component's interface. The dependency may be marked
with the use keyword; however, the keyword is often omitted because this is the
default, and the meaning is evident from how the dependency is used.
Figure 8 shows how the various components of the project management system are
related:

The User Interface component-

Uses the Security component and the IBusinessProcessing interface provided by
the Business Processing component

The Business Processing component-

Uses the Security component and the IProducible and IConsumable interfaces
provided by the Data component

The Data component-

Uses the Security component

Figure 8- Use dependencies

3.3 Deploy Dependencies

A deploy dependency from a client component to a supplier node indicates that the
client component is deployed on the supplier node.
A deploy dependency is shown as a dashed arrow from a client component to a
supplier node marked with the deploy keyword.
 Figure 9 shows that the User Interface component is deployed on the Desktop
Client node.

Figure 9- Deploy dependencies

Figure 10 shows that the Business Processing component is deployed on

the Business-Processing Server node.

Figure 10- Deploy dependencies for a subsystem

Alternatively, a component that is deployed on a node may be shown nested inside

the node. Figure 11 shows that the Data component is deployed on the Database
Server node.

Figure 11- Deploy dependencies using nesting

A.4 Procedure/Algorithm
A.4.1 Task:
For the case study given on black board complete deployment model.
PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.4 Conclusion
We drew the deployment diagram.
 PART A
EXPERIMENT NO. 9
Experiment 9
A.1 Aim: Coding for any Two module of your project selected according to the designs
which already designed and analyzed in EXP.1-6
A.2 Prerequisite:
Use case diagram, class diagram, State diagram

A.3 Outcome:

Coding of a module with less errors

A.4 Theory:
The coding depends on individual’s project. Any programming language can be used
according to student’s interest.

Coding : The objective of the coding phase is to transform the design of a system into code in
a high-level language and then to unit test this code. Good software development organizations
normally require their programmers to adhere to some well-defined and standard style of
coding called coding standards.

Coding Standards- A coding standard gives a uniform appearance to the codes written by
different engineers. It enhances code understanding. It encourages good programming
practices.

Coding Standards and Guideline:

Limiting the use of global data type. Contents of the headers preceding codes for different
modules naming conventions for global variables, local variables, and constant identifiers.
Error return conventions and exception handling mechanisms Representative Coding
Standards. Do not use a coding style that is too clever or too difficult to understand. Avoid
obscure side effects .Do not use an identifier for multiple purposes. The code should be well-
documented.

Code Review:

Code review for a model is carried out after the module is successfully compiled and all the
syntax errors have been eliminated. Normally, two types of reviews are carried out on the code
of a module.

Code Walk Through: To discover the algorithm and logical errors in the code.

Code Inspection: The aim of code inspection is to discover some common types of errors
caused due to oversight and improper programming.
Software Documentation:Good documents are very useful and serves the following purposes.
Good documents enhance understandability and maintainability of a software product. It helps
the users in effectively using the system. Helps in effectively handling the manpower turnover
problem. Helps the manager in effectively tracking the progress of the project.
Software Documentation classified into the following: Internal documentation: These are
provided in the source code itself
External documentation: These are the supporting documents that usually accompany a
software product

**********************
 PART B
(PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.1 Task:
While viewing from PC:
While viewing from Phone:
B.1 Conclusion
We developed the user interface as required of our project i.e. Library Management System.

PART A
EXPERIMENT NO. 10
A.1 AIM: - To Design Test Cases
A.2 Outcome
After successful completion of this experiment students will be able to design the test
cases
Learn different testing methods and design test cases for their project
A.3 Theory

• Testing is the process of analyzing a system or system component to detect the

differences between specified (required) and observed (existing) behavior.
• Activities involved in testing are:
• Establish the test objectives
• Design the test cases
• Write the test cases
• Test the test cases
• Execute the tests
 • Evaluate the test results
• Change the system
• Do regression testing
1. Select what has to be tested
– Analysis: Completeness of requirements
– Design: Cohesion
– Implementation: Source code
2. Decide how the testing is done
– Review or code inspection
– Proofs (Design by Contract)
– Black-box, white box,
– Select integration testing strategy (big bang, bottom up, top down, sandwich)
3. Develop test cases
– A test case is a set of test data or situations that will be used to exercise the
unit (class, subsystem, system) being tested or about the attribute being
measured
4. Test plan
a. Focuses on managerial aspects of testing
b. Documents the scope, approach, resources and schedule of testing activities
c. Requirements and the components to be tested are identified in this document
5. Test case specification
a. Writing effective test cases is a skill and that can be achieved by some
experience and in-depth study of the application on which test cases are being
written
Test Case Specification Template:
Tes Test cases Priorit Preconditio Input test data Steps to be Expected Actual Pass/fa Commen
t y ns executed results results il ts
cas
e id

1 Test if user A User must be correct 1)Enter User must (note

is able to registered username, input(correct successfull down
login already )username y login to the
successfull correct password and the web results
y. password on page you
the have
respective observe
fields 2)click d)
submit/login

2 Test if A incorrect 1)Enter Proper (note

unregistere username,incorre input(incorre error must down
d users is ct password ct )username be the
not able to and displayed results
login to the password on and you
site the prompt to have
respective enter login observe
fields 2)click again d)
submit/login

A.4 Task:
For Selected Case Study write appropriate test cases and adopt necessary test comments to
existing coding. Improve the quality of the coding which is performed in Experiment-9.
PART B
 (PART B: TO BE COMPLETED BY STUDENTS)
(Students must submit the soft copy as per the following segments within two hours of the
practicals. The soft copy must be uploaded on Blackboard LMS or emailed to the concerned
Lab in charge Faculties at the end of practical; in case Blackboard is not accessible)

Roll No: A117 Name: Kushagra Mehrotra

Class: - Batch: A2

Date of Experiment: - Date of Submission:

Grade:

B.1 Task:
For Selected Case Study write appropriate test cases and adopt necessary test comments to
existing coding. Improve the quality of the coding which is performed in Experiment-9.

Login Form Test Cases:

Book Issue Form Test Cases:

Book Return Form Test Cases:
B.2 Conclusion
We designed test cases.