OOSD Lab MANUAL

B.E.
3/4 - II Semester
BIT- 381 OOSD LAB
List of Experiments Prescribed by Osmania University
Students have to perform the following OOSD steps on the

Given Case Study.
 Use case Modeling
 Structural Modeling
 Behavioral Modeling
 Architectural Modeling
The list of Experiments:
1. Use case Diagram
2. Class Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. State Diagram
6. Activity Diagram
7. Component Diagram
8. Deployment Diagram
List of innovative experiments (If any)
9. Selection of a Case Study – Problem Statement.

10. Software Requirement Specification.
Design based Experiments
To design a case study like Road Transport Authority system by using the following
UML Diagrams:
 Class Diagram
 Sequence Diagram
 Collaboration Diagram
 State chart Diagrams
1
 Usecase Diagrams
 Deployment Diagrams
OOSD LAB
CONTENTS
S.NO Name of the Experiment Page no.
 The students have to perform the Use case Modeling step on the
Given case study by using:
1. Use case Diagrams. 3
 The students have to perform the Structural Modeling step on the
2. Class Diagrams 9
3. Sequence Diagrams 14
4. Collaboration Diagrams 21
 The students have to perform the Behavioral Modeling step on the
5. Activity Diagrams 24
6. State Diagrams 29
 The students have to perform the Architectural Modeling step on the
7. Component Diagrams 33
8. Deployment Diagrams 36
9* Assigning of a Case Study - Example: ONLINE EAMCET EXAM.
Writing of Problem Statement to the given Case Study. 39
10* Software Requirement Specification. 40
* Innovative Experiments
 *d Class Diagram 44
 *d Sequence Diagrams 48
 *d Collaboration Diagrams 55
 *d State chart Diagrams 59
 *d Usecase Diagrams 62
2
 *d Deployment Diagrams 66
1. Use case diagrams
AIM: To identify actors, use cases and relationships for representing functional
Requirement of system using Use case diagrams.
SOFTWARE REQUIREMENTS:
• Operating system: Windows XP
• Software : Rational Rose
HARDWARE REQUIREMENTS:
• PROCESSOR : Pentium IV ,2.6 GHz
• Memory :256 MB
• Hard disk capacity: 80 GB
PROCEDURE:
Actor:
Actors represent system users. They help delimit the system and give a clearer picture
of what the system should do. It is important to note that an actor interacts with, but
has no control over the use cases.
An actor is someone or something that:
· Interacts with or uses the system

· Provides input to and receives information from the system
· Is external to the system and has no control over the use cases
Actors are discovered by examining:
· Who directly uses the system?

· Who is responsible for maintaining the system?
· External hardware used by the system
· Other systems that need to interact with the system
The needs of the actor are used to develop use cases. This insures that the system will
be that the user expected.
3
Graphical Depiction
An actor is a stereotype of a class and is depicted as a "stickman" on a use-case

diagram.
Naming
The name of the actor is displayed below the icon.

Additional information about the actor can be viewed in the Use-Case Specification
which is identical to a Class Specification with the addition of the Stereotype field set
to actor.
Use cases: A use case is a high-level piece of functionality that the system will provide
In its simplest form, a use case can be described as a specific way of using the system
from a user’s (actor’s) perspective. A more detailed description might characterize a
use case as:
· A pattern of behavior the system exhibits

· A sequence of related transactions performed by an actor and the system
· Delivering something of value to the actor
Use cases provide a means to:
· capture system requirements

· communicate with the end users and domain experts
· test the system
Use cases are best discovered by examining the actors and defining what the actor
will be able to do with the system.
Since all the needs of a system typically cannot be covered in one use case, it is usual
to have a collection of use cases. Together this use case collection specifies all the
ways of using the system.
4
By looking at the use cases, the customer can see what functionality will be provided,
and can agree to the system scope before the project goes any further
Graphical Depiction
The basic shape of a use case is an ellipse:

Naming
A use case may have a name, although it is typically not a simple name. It is often
written as an informal text description of the actors and the sequences of events
between objects. Use case names often start with a verb. For example, names of
possible use cases for an ATM machine might include Dispense Cash or Transfer
Funds.
The name of the use case is displayed below the icon.
Additional information about a use case can be viewed in the Use-Case specification.
Relationships
There are four types of relationships
1. Association
2. Includes relationship
3. Extends relationship
4. Generalization relationship.
You can draw an Association relationship from a use case to an actor.
You can draw a Generalize relationship between two use cases and /or two actors
You can draw a Dependency relationship between two use cases.
Association Relationship
The relationship between an actor and a use case is an association relationship.
In UML, association relationships are diagrammed using an arrow:
5
Include Relationship
An included relationship allows one use case to use the functionality provided by
another use case. This relationship can be used in one of two cases.
First, if two or more use cases have a large piece of functionality that is identical,
this functionality can be split into its own use case. Each of the other use cases
can then have an include relationship with this new use case.
The second case where an include relationship is helpful is a situation in which a

single use case has an unusually large amount of functionality. An include
relationship can be used to model two smaller use cases instead.
Includes relationships are shown in Rational Rose with dashed arrows and the
word <<include>>
3. Extend Relationship
In contrast, an extend relationship allows one use case the option to extend the
functionality provided by another use case. It is very similar to an include
relationship, because in both of these types of relationships, you separate some
common functionality into its own use case.
In UML, the extend relationship is shown as a dashed arrow with the word
<<extend>>
6
4. Generalization Relationship
A generalization relationship is used to show that several actors or use cases have
some commonality. For example, you may have two types of customers:
corporate customers and individual customers.
If both types of customers use the same use cases, it's probably not necessary to
show an actor generalization. If both types use the same use cases, but slightly
differently, it still isn't worth including the generalization. The slight differences are
documented in the flow of events
Flow of Events
The purpose of the flow of events is to document the flow of logic through the use
case. This document will describe in detail what the user of the system will do and
what the system itself will do. The flow of events typically includes:
 A brief description
 Preconditions
 Primary flow of events
 Alternate flow of events
 Post-conditions
Description
Each use case should include a short description that explains what the use case
will do The description should be short and to the point, but should include the
different types of users who will be executing the use case and the end result the
user expects to achieve through the use case.
7
Preconditions
The preconditions for a use case list any conditions that have to be met before the
use case can start at all. For example, a precondition might be that another use
case has been executed or that the user has the necessary access rights to run the
current use case. Not all use cases will have preconditions.
Primary and Alternate Flow of Events

The specific details of the use case are described in the primary and alternate
flow of events. The flow of events describes, step-by-step, what will happen to
execute the functionality in the use case. The flow of events focuses on what the
system will do not how it will do it, and is written from the user's perspective.
The primary and alternate flow of events includes:
 How the use case starts
 The various paths through the use case
 The normal, or primary, flow through the use case
 Any deviations from the primary flow, known as
alternate flows, through the use case
 Any error flows
 How the use case ends
Post-Conditions
Post-conditions are conditions that must always be true after the use case has
finished executing. Like preconditions, post-conditions can be used to add
information about the order in which the use cases are run. If, for example, one
use case must always be run after another use case, you can document this in the
post-conditions. Not every use case will have post-conditions.
USECASE DIAGRAM:
8
Use case Diagram is graphical view of some or all of the actors, use cases, their
interactions identified for a system
Exercise 3:
9
1. Identify actors for your system.
2. For each actor write the documentation.
3. Identify use cases for your system.
4. Document the use cases.
5. Write use case specification for each use case identified.
6. Link use case documents to Use cases in Rational Rose.
7. Identify use case relationships
8. Draw a Main and sub use case diagrams for you system.
10
1. Class Diagram
AIM: To identify different classes involve in the system and relationships among
these classes to draw class diagram with all options.
• Memory :256 MB
PROCEDURE:
Class diagrams are the most common diagrams found in modeling object-oriented
systems. A class diagram shows a set of classes, interfaces, and collaborations and
their relationships. Graphically, a class diagram is a collection of vertices and arcs.
A class diagram is a picture for describing generic descriptions of possible systems.
Class diagrams and collaboration diagrams are alternate representations of object
models. Class diagrams contain classes and object diagrams contain objects, but it
is possible to affix classes and objects when dealing with various kinds of
metadata, so the separation is not rigid.
Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data
structures-or message-passing structures.
Class diagrams contain icons representing classes, interfaces, and their
relationships. You can create one or more class diagrams to depict the classes at
the top level of the current model; such class diagrams are themselves contained by
the top level of the current model. You can also create one or more class diagrams
to depict classes contained by each package in your model; such class diagrams are
themselves contained by the package enclosing the classes they depict; the icons
representing logical packages and classes in class diagrams
We can change properties or relationships by editing the specification or
modifying the icon on the diagram. The associated diagrams or specifications are
automatically updated.
11
Class diagrams are the backbone of almost every object oriented method including
UML. Class diagrams describe the static structure of a system.
Contents:
Class Diagrams commonly contain the following things:
Classes
Interfaces
Collaborations
Dependency, generalization and association relationships
2. Classes & Interfaces:
Class: A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics. A class implements one
or more interfaces.
Graphically a class is rendered as a rectangle, usually including its name,
attributes and operations, as shown below.
Window
Origin
Size
Open ()
Close ()
Display ()
Interface:
An interface is a collection of operations that specify a service of a class or
component. An interface describes the externally visible behavior of that
element.
Graphically the interface is rendered as a circle together with its name.
ISpelling
12
The various classes in our class diagram are:
 student
 system
 database
 faculty
Manager
DIAGRAM:
Exercise:
1) Discover the initial – cut classes – Entity, Boundary and Control Classes.
2) Document the classes identified above and observe whether you have given
appropriate name and definition.
3) Group the identified classes into packages.
4) Write Main class diagram of the logical view model.
5) Write Main class diagram for each package identified.
13
2. Sequence Diagram
AIM: To analyze major functionalities and represent communication among objects

with time bound for each operation.
• Memory :256 MB
PROCEDURE:
A sequence diagram is a graphical view of a scenario that shows object interaction in
a time-based sequence what happens first, what happens next. Sequence diagrams
establish the roles of objects and help provide essential information to determine class
responsibilities and interfaces. This type of diagram is best used during early analysis
phases in design because they are simple and easy to comprehend. Sequence diagrams
are normally associated with use cases.
Sequence diagrams are closely related to collaboration diagrams and both are
alternate representations of an interaction. There are two main differences between
sequence and collaboration diagrams: sequence diagrams show time-based object
interaction while collaboration diagrams show how objects associate with each other.
A sequence diagram has two dimensions: typically, vertical placement represents time
and horizontal placement represents different objects.
The following tools located on the sequence diagram toolbox enable you to model
sequence diagrams:
 Object
 Message Icons
 Focus of Control
 Message to Self
 Note
 Note Anchor
14
A sequence diagram consists of the following sequence diagram behavioral
elements.
Element and its description Symbol

Object: The primary element involved in a sequence
diagram is an object—an instance of a class. A
Sequence diagram consists of sequence of interaction
among different objects over a period of time. An
object is represented by a named rectangle. The name
to the left of the “.” Is the object name and to its right
is the class name.
Message: The interaction between different objects
in a sequence diagram is represented as messages. A
message is denoted by a directed arrow. Depending
on the type of message, the notation differs. In a
sequence diagram, you can represent simple
messages, Special messages to create or destroy
objects, and message responses.
The steps involved in creating a Sequence are:

 Identify objects.
 Identify actors.
 Add messages to the diagram.
Object
An object is something that encapsulates information and behavior. It's a term
that represents some concrete, real-world thing. Examples of objects are:
airplane, a flight, a passenger, a piece of luggage, or a ticket.
Finding Objects
A good way to find some initial objects is to examine the nouns in your flow of
events. Another good place to look is in the scenario documents. A scenario is a
specific instance of a flow of events.
15
Lifeline
It specifies the existence of the Object. Each object has a lifeline, drawn as a
vertical dashed line below the object. The lifeline begins when the object is
instantiated and ends when the object is destroyed.
Focus of Control
In a Sequence diagram, you have the option of showing the focus of control,
which lets you know which object has control at a particular point in time. A
small vertical rectangle represents the focus of control.
Messages
A message is a communication between objects in which one object (the client)
asks another object (the supplier) to do something. By the time you generate
code, a message will translate to a function call. In this example, one form is
asking another to display itself:
Types of Messages:
Simple: This is the default value for messages. This option specifies that the
message runs in a single thread of control. On the Sequence diagram, simple
messages use this symbol.
Synchronous: Use this option when the client sends the message and waits until
the supplier has acted upon the message. On the Sequence diagram, synchronous
messages will appear this way.
16
Balking: With this option, the client sends the message to the supplier. If the
supplier is not immediately ready to accept the message, the client abandons the
message. On the Sequence diagram, balking messages appear like this.
Timeout: Using this option, the client sends the message to the supplier and
waits a specified amount of time. If the supplier isn't ready to receive the message
in that time, the client abandons the message. On the Sequence diagram, timeout
messages appear using this arrow.
Asynchronous: With this option, the client sends the message to the supplier.
The client then continues processing, without waiting to see if the message was
received or not. On the Sequence diagram, asynchronous messages look like this.
Procedure Call: With this option, the client sends the message to the supplier.
The client then must wait until the entire nested sequence of messages is
processed before continuing. On the Sequence diagram, procedure call messages
look like this.
17
Return: This option indicates the return from a procedure call. On the Sequence
diagram, return messages look like this.
Objects Identification:
The objects in the sequence diagram are
1. User
2. System
3. Database
18
DIAGRAM:
Login:
Notification:
19
Questions and key preparation:
Exercise 5:
1 Write use case realizations for any major three use cases
2. Draw sequence diagrams for above three use case realizations.
20
AIM: To represent object interaction for a use case flow of control using
collaboration diagram.
• Memory :256 MB
PROCEDURE:
• A collaboration diagram is an alternate way to show a scenario. This type of
diagram shows object interactions organized around the objects and their links
to each other.
• A collaboration diagram can be created from the sequence diagram by
pressing the F5 key in Rational Rose. And vice versa.
• Why there are two different diagrams for object interaction?
Sequence diagrams are useful in the early analysis phases as customers can
read and understand this type of diagram.
Collaboration diagrams seem to be used more in the design phase of
development when you are designing the implementation of the relationships.
Like Sequence diagrams, Collaboration diagrams are used to show the flow
through a specific scenario of a use case. While Sequence diagrams are ordered
by time, Collaboration diagrams focus more on the relationships between the
objects.
21
Basic Collaboration Diagram Symbols and Notations
Object: Class
Class roles
Class roles describe how objects behave. Use the UML object symbol to
illustrate class roles, but don’t list object attributes.
Association roles:
Association roles describe how an association will behave given in a particular
situation. You can draw association roles using simple lines labeled with
stereotypes.
Messages:
Unlike sequence diagrams, collaboration diagrams do not have an explicit way
to denote time and instead number messages in order of execution. Sequence
numbering can become nested using the Dewey decimal system. For example,
nested messages under the first message are labeled 1.1, 1.2, 1.3, and so on. A
condition for a message is usually placed in square brackets immediately
following the sequence number. Use a * after the sequence number to indicate
a loop.
Objects:
The objects in the Collaboration diagram are the same as in the Sequence
diagram.
Diagrams:
Login:
22
Notification:
Exercise 6:
1. Identify flow of control for any three major use cases.

2. Draw collaboration diagrams for above use cases.
3. Observe how a collaboration diagram can be drawn from
existing sequence diagram and vice versa in rational rose
23
5. Activity Diagram
AIM: To draw activity diagram of a system to represent workflow of system using

swim lanes and without swim lanes.
• Memory :256 MB
PROCEDURE:
Activity diagrams provide a way to model the workflow of a business process. You
can also use activity diagrams to model code-specific information such as a class
operation. Activity diagrams are very similar to a flowchart because you can model a
workflow from activity to activity. Activity diagrams can model many different types
of workflows.
Understanding Workflows
Each activity represents the performance of a group of actions in a workflow. Once
the activity is complete, the flow of control moves to the next activity or state through
a transition. If an outgoing transition is not clearly triggered by an event, then it is
triggered by the completion of the contained actions inside the activity. A unique
activity diagram feature is a swim lane that defines who or what is responsible for
carrying out the activity or state. It is also possible to place objects on activity
diagrams. The workflow stops when a transition reaches an end state.
You can attach activity diagrams to most model elements in the use case or logical
views. Activity diagrams cannot reside within the component view.
Activity Diagram Tools
You can use the following tools on the activity diagram toolbox to model activity
diagrams:
 Activities
 Decisions
 End State
24
 Object
 Object Flow
 Start State
 States
 Swim lanes
 Synchronizations
 Transitions
Action states
Action states represent the noninterruptible actions of the objects. You can draw an
action state in smart Draw using a rectangle with rounded corners.
Action flow
Action flow arrows illustrate the relationships among action states.
Object flow
Object flow refers to the creation and modification of objects by activities. An object
flow arrow fro an action to an object means that the action creates or influences the
object. An object flow arrow from an object to an action indicates that the action state
uses the object
25
Initial state
A filled circle followed by an arrow represents the initial action state.
Final state
An arrow pointing to a filled circle nested inside another circle represents the final
action state.
Branching
A diamond represents a decision with alternate
paths. The outgoing alternates should be
Labeled with a condition or guard expression. You can also label one of the paths
“else”.
Synchronization
A synchronization bar helps illustrate parallel transitions. Synchronization is also
called forking and joining.
Swim lanes
26
Swim lanes group related activities into one column.
Diagram:
27
Exercise:
1. Draw activity diagrams for any two major use cases (with
swim lines and another without swim lanes.
2. Draw activity diagram for entire system.
28
6. State Chart Diagram
AIM: To identify different states of an object and draw state chart for its life
cycle .A State chart diagram shows the life cycle of a single object, from the time
that it is created until it is destroyed. These diagrams are a good way to model the
dynamic behavior of a class.
• Memory :256 MB
PROCEDURE:
A state chart diagram shows the behavior of classes in response to external stimuli.
This diagram models the dynamic flow of control from state to state within a system.
States: States representing situations during the life of an object. You can easily
illustrate a state in Smart Draw by using a rectangle with rounded corners.
Transition:
A solid arrow represents the path between different states of an object. Label the
transition with the event that triggered it and the action that results from it.
29
Initial State:
A filled circle followed by an arrow represents the object’s initial state.
Final State:
An arrow pointing to a filled circle nested inside another circle represents the object’s
final state.
Synchronization and splitting of control

A short heavy bar with two transitions entering it represents a synchronization
of control. A short heavy bar with two transitions leaving it represents a splitting of
control that creates multiple states.
Sequential States:
The sequential states in our state diagram 1 are idle, login, send problem, receive
prescription, and pay fee and log out. The sequential states in state diagram 2 are idle,
login, read problem, send problem, receive prescription, send prescription, take fee,
pay salary, logout. The sequential states of diagram 3 are idle, login, read problem,
send prescription, take salary.
30
Diagrams:
Student:
Conveyor:
id le
qu e s tion s
p re p s e tu p te s t m a n a ge
c e n te rs d a ta b a s e
e n te r id in vig ialtio n
a p po in t s end
fa c u lty res u lts
en te r
p a s s w o rd
31
Faculty:
id le
ques tions in vigialtio n

prep
enter id
e nte r
pas s word
Exercise:
1. Identify all possible states for any three objects of your
system
2. Draw state chart for each of above objects to represent their
life cycles.
32
7. Component Diagram
AIM: To identify all software components and associations among them and to draw
Component diagram
• Memory :256 MB
PROCEDURE:
Component diagrams provide a physical view of the current model. A component
diagram shows the organizations and dependencies among software components,
including source code components, binary code components, and executable
components. These diagrams also show the externally-visible behavior of the
components by displaying the interfaces of the components. Calling dependencies
among components are shown as dependency relationships between components and
interfaces on other components. Note that the interfaces actually belong to the logical
view, but they can occur both in class diagrams and in component diagrams.
Component diagrams contain:
· Component packages
· Components
· Interfaces
· Dependency relationships
You can create one or more component diagrams to depict the component packages
and components at the top level of the component view, or to depict the contents of
each component package. Such component diagrams belong to the component
package that they depict.
A Component Package Specification enables you to display and modify the properties
of a component package. Similarly, a Component Specification and a Class
Specification enables you to display and modify the properties of a component and an
interface, respectively. The information in these specifications is presented textually.
33
Some of this information can also be displayed inside the icons representing
component packages and components in component diagrams, and interfaces in class
diagrams.
You can change properties of, or relationships among, component packages,
components, and interfaces by editing the specification or modifying the icon on the
diagram. The affected diagrams or specifications are automatically updated.
Basic Component diagram symbols and Notations
Component
A component is a physical building block of the system. It is represented as a
rectangle with tabs.
Interface
An interface describes a group of operations used or created by components.
Dependencies
34
Draw dependencies among components using dashed arrows.
Diagram:
Exercise:
1. Identify all required components of your system and draw a detail
Component diagram
35
AIM: To identify all runtime components and implementation architecture of system

and to draw Deployment diagram
• Memory :256 MB
PROCEDURE:
A deployment diagram shows processors, devices, and connections. Each model
contains a single deployment diagram which shows the connections between its
processors and devices, and the allocation of its processes to processors.
Processor Specifications, Device Specifications, and Connection Specifications
enable you to display and modify the respective properties. The information in a
specification is presented textually; some of this information can also be displayed
inside the icons.
You can change properties or relationships by editing the specification or modifying
the icon on the diagram. The deployment diagram specifications are automatically
updated.
Basic Deployment diagram symbols and Notations
Node
A node is a physical resource that executes code components.
36
Association
Association refers to a physical connection between nodes, such as Ethernet.
Components and Nodes

Place components inside the node that deploys them.
37
Diagram:
db
s erver
d a ta b a se .d d l
s y s tem
us er s ervic e
m anager
su d e n t.e xe a d m i n o ffi ce r.e xe

fa cu lty.e xe c o n ve yn o r.e x e
Exercise
1. Identify all implementation nodes of your system and draw deployment

diagram for your system
38
9. Selection of a Case Study – Problem Statement
AIM: Select the problem to be solved as case study by each team and preparation of
Technical problem statement for the same .Example: ONLINE EAMCET
EXAM.
PROCEDURE:
The following are the users which can access the database .They are emcee
conveyor, student and faculty. The emcee conveyor issues the notification for the
particular year. After receiving the applications from the students, he issues hall
tickets online .He manages the database and the entire system. He appoints the faculty
and also set up regional test centers with required infrastructure .A regional centre
will have few computers and a local server which will manage the tests. This server
will manage the question bank and as well as results of the test taker.
The faculty has access to the question bank server and they can
only add more questions to it. Some of the faculty is appointed as invigilators for the
test. A student can take only one time in a year at the test center and the score is valid
for two years. Students have to register online for the test with a valid identity proof.
The payment can be made through credit cards or through demand draft. The results
are sending to the test takers through postal mail. Admission offices of all registered
institutions have access to the results through which they can verify the score.
Exercise 1:
• Select a system and write the problem statement for the selected
system
39
10. Software Requirement Specification
AIM: Preparation of SRS document to understand the system characteristics in

detail.
PROCEDURE:
• Standard SRS should include the following
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions
1.4 References
1.5 Overview
2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 Functional requirements
3.2 Non functional requirements
3.3 Performance requirements
3.4 External interfaces
3.5 Software system attributes
40
1. INTRODUCTION
1.1 Purpose
The purpose of the online emcee exam is to make eamcet online
and make conducting and evaluating the result easy.
1.2 Scope
The main users of the system are conveynor, student, and faculty
and admission officer.
1.3 Definitions, acronyms and abbreviations
Reg-regional
Admn-admission
Ques prep-question preparation
1.4 Overview
General description deals with project perspective, project
function, user characteristics and general constraints. Specific
requirements deal with external interface requirements,
performance requirements and design constraints.
2. GENERAL DESCRIPTION
2.1 Product perspective
The online eamcet exam is used when student wants to join
engineering.
2.2 Product function
The main function of online eamcet exam is to accept request for
the students to write exam and get the results immediately.
2.3 User characteristics
Main users are conveynor,student and faculty
Convey nor:-he should have the knowledge of managing and
conducting the exam.
Student:-he should have the knowledge of applying and writing the
exam.
Faculty:-he should have the knowledge of preparing questions and
conducting exam.
41
2.4 General constraints
It works only on windows.
3. SPECIFIC REQUIREMENTS
3.1 External Interface requirements
3.1.1 User Interfaces
HTML
3.1.2 Hardware Interfaces
Keyboard, Mouse
3.1.3 Software Interfaces
Rational Rose, Windows
3.2 FUNCTIONAL REQUIREMENTS

• 3.2.1 Login:-It allows the users to use the services. It takes in
login id and password and returns to the next page.
• 3.2.2 Notification:-conveyor notifies the data for applying hall
tickets and date of exam.
• 3.2.3 issue hall ticket:-after receiving applications ,conveynor
issues hall tickets for eligible students online.
• 3.2.4 appoint faculty:-conveynor appoints the faculty for
conducting test.
• 3.2.5 Manage database:-conveynor manages the database which
consists of question bank and results.
• 3.2.6 Setup regional test centers:-conveyor setup regional test
centers with infrastructures.
• 3.2.7 Sendresults:-conveynor sends results to the test takers
through postal mail.
• 3.2.8 Conduct counseling:-conveyor conducts counseling for
the test takers to join in institutions.
• 3.2.9 Logout:-the user logout after their work is completed.
• 3.3.1 Register online:-the students register online for the test
with a valid identity proof.
• 3.3.2payfees:-the students pay fees through credit card or
demand draft.
• 3.3.3 Take test: - the students write the test.
42
• 3.3.4 Questions preparation:-the faculty prepares the questions
bank.
• 3.3.5 Invigilation:-the faculty conducts the test.
• 3.3.6 Verify results:-admissions of registered institutions verify
the results.
3.3 NON FUNCTIONAL REQUIREMENTS
The system is dependable, reliable and interoperable.
Static requirements: A limited number of customers can only login
to the hotel based on the no of rooms present in that hotel.
Dynamic requirements: Query processing time is 10 ms.
3.4 DESIGN CONSTRAINTS
The login of conveyor and faculty has to provide their password.
Exercise 2:
Write SRS for the case or system chosen by you.
43
Design Based Experiments
1. Class Diagram
AIM: To design Road Transport Authority System by using class diagram.

• Memory :256 MB
PROCEDURE:
Class diagrams are the most common diagrams found in modeling object-oriented
systems. A class diagram shows a set of classes, interfaces, and collaborations and
their relationships. Graphically, a class diagram is a collection of vertices and arcs.
A class diagram is a picture for describing generic descriptions of possible systems.
Class diagrams and collaboration diagrams are alternate representations of object
models. Class diagrams contain classes and object diagrams contain objects, but it
is possible to affix classes and objects when dealing with various kinds of
metadata, so the separation is not rigid.
Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data
structures-or message-passing structures.
Class diagrams contain icons representing classes, interfaces, and their
relationships. You can create one or more class diagrams to depict the classes at
the top level of the current model; such class diagrams are themselves contained by
the top level of the current model. You can also create one or more class diagrams
to depict classes contained by each package in your model; such class diagrams are
themselves contained by the package enclosing the classes they depict; the icons
representing logical packages and classes in class diagrams
We can change properties or relationships by editing the specification or
44
modifying the icon on the diagram. The associated diagrams or specifications are
automatically updated.
Class diagrams are the backbone of almost every object oriented method including
UML. Class diagrams describe the static structure of a system.
Contents:
Class Diagrams commonly contain the following things:
Classes
Interfaces
Collaborations
Dependency, generalization and association relationships
2. Classes & Interfaces:
Class: A class is a description of a set of objects that share the same
attributes, operations, relationships, and semantics. A class implements one
or more interfaces.
Graphically a class is rendered as a rectangle, usually including its name,
attributes and operations, as shown below.
Window
Origin
Size
Open ()
Close ()
Display ()
Interface:
An interface is a collection of operations that specify a service of a class or
component. An interface describes the externally visible behavior of that
element.
Graphically the interface is rendered as a circle together with its name.
45
ISpelling
The various classes in our class diagram are:

 RTA
 Employee
 Operator
 Administrator
 Accountant
 Officer
 Helpdesk
 Applicant
 Report
46
Diagram:
R TA
R e g io n
Code
P hno
A dd
P ro vide F a c ilities ()
E m p lo ye e
nam e
id
s a la ry ()
o p e ra to r a d m inis tra to r a c c o unta nt o ffic e r

nam e nam e nam e
nam e
id id id
id
a c c e pt re g () rec o rd m a in te n a n c e () t es t d rive p re p ()
a c c e pt p a y m e n t s ()
a llo t pid () rec o rd c la s s ific a tio n() in vig ila tio n()
g e n e ra te b ills ()
p re p a re re p o rt() is s u e lic e n c e ()
a p p lic a nt
he lp d e s k nam e re p o rt
nam e p id
no
id
g e ts re g is te re d ()
d a ily re p o rt()
res p o n d t o q u e rie s () t ak e s te s t()
m o n t h ly re p ort()
b ill pa y m en t s ()
te s t
c e rtific a te s ve rific a tio n
47
2. Sequence Diagram
AIM: To design Road transport authority system by using sequence diagram.

• Memory :256 MB
PROCEDURE:
A sequence diagram is a graphical view of a scenario that shows object interaction in
a time-based sequence what happens first, what happens next. Sequence diagrams
establish the roles of objects and help provide essential information to determine class
responsibilities and interfaces. This type of diagram is best used during early analysis
phases in design because they are simple and easy to comprehend. Sequence diagrams
are normally associated with use cases.
Sequence diagrams are closely related to collaboration diagrams and both are
alternate representations of an interaction. There are two main differences between
sequence and collaboration diagrams: sequence diagrams show time-based object
interaction while collaboration diagrams show how objects associate with each other.
A sequence diagram has two dimensions: typically, vertical placement represents time
and horizontal placement represents different objects.
The following tools located on the sequence diagram toolbox enable you to model
sequence diagrams:
 Object
 Message Icons
 Focus of Control
 Message to Self
 Note
 Note Anchor
48
A sequence diagram consists of the following sequence diagram behavioral
elements.
Element and its description Symbol

Object: The primary element involved in a sequence
diagram is an object—an instance of a class. A
Sequence diagram consists of sequence of interaction
among different objects over a period of time. An
object is represented by a named rectangle. The name
to the left of the “.” Is the object name and to its right
is the class name.
Message: The interaction between different objects
in a sequence diagram is represented as messages. A
message is denoted by a directed arrow. Depending
on the type of message, the notation differs. In a
sequence diagram, you can represent simple
messages, Special messages to create or destroy
objects, and message responses.
The steps involved in creating a Sequence are:

 Identify objects.
 Identify actors.
 Add messages to the diagram.
Object
An object is something that encapsulates information and behavior. It's a term
that represents some concrete, real-world thing. Examples of objects are:
airplane, a flight, a passenger, a piece of luggage, or a ticket.
Finding Objects
A good way to find some initial objects is to examine the nouns in your flow of
events. Another good place to look is in the scenario documents. A scenario is a
specific instance of a flow of events.
49
Lifeline
It specifies the existence of the Object. Each object has a lifeline, drawn as a
vertical dashed line below the object. The lifeline begins when the object is
instantiated and ends when the object is destroyed.
Focus of Control
In a Sequence diagram, you have the option of showing the focus of control,
which lets you know which object has control at a particular point in time. A
small vertical rectangle represents the focus of control.
Messages
A message is a communication between objects in which one object (the client)
asks another object (the supplier) to do something. By the time you generate
code, a message will translate to a function call. In this example, one form is
asking another to display itself:
Types of Messages:
Simple: This is the default value for messages. This option specifies that the
message runs in a single thread of control. On the Sequence diagram, simple
messages use this symbol.
Synchronous: Use this option when the client sends the message and waits until
the supplier has acted upon the message. On the Sequence diagram, synchronous
messages will appear this way.
50
Balking: With this option, the client sends the message to the supplier. If the
supplier is not immediately ready to accept the message, the client abandons the
message. On the Sequence diagram, balking messages appear like this.
Timeout: Using this option, the client sends the message to the supplier and
waits a specified amount of time. If the supplier isn't ready to receive the message
in that time, the client abandons the message. On the Sequence diagram, timeout
messages appear using this arrow.
Asynchronous: With this option, the client sends the message to the supplier.
The client then continues processing, without waiting to see if the message was
received or not. On the Sequence diagram, asynchronous messages look like this.
Procedure Call: With this option, the client sends the message to the supplier.
The client then must wait until the entire nested sequence of messages is
processed before continuing. On the Sequence diagram, procedure call messages
look like this.
51
Return: This option indicates the return from a procedure call. On the Sequence
diagram, return messages look like this.
Objects Identification:
The objects in the sequence diagram are
4. User
5. System
6. Database
52
1: Register
:user :system :database
1: send request with details
2: enter in database
3: send confortmation
4: send PID and date
2: Payment & Verification
:user :accountant :database

1: submit certificates
2: validate
3: send conformation
4: makes payment
7: send report
53
3: Test
:user :system :question :database

bank
1: send test details
2: get questions
3: send questions
4: start test
5: submit
6: validate
7: store score in dB
9: send score
4: Issue of License
:user :officer :database

1: takes track test
2: validate
3: enter in dB
5: issue license
54
AIM: To Design Road transport authority system by using collaboration diagram.

• Memory :256 MB
PROCEDURE:
• A collaboration diagram is an alternate way to show a scenario. This type of
diagram shows object interactions organized around the objects and their links
to each other.
• A collaboration diagram can be created from the sequence diagram by
pressing the F5 key in Rational Rose. And vice versa.
• Why there are two different diagrams for object interaction?
Sequence diagrams are useful in the early analysis phases as customers can
read and understand this type of diagram.
Collaboration diagrams seem to be used more in the design phase of
development when you are designing the implementation of the relationships.
Like Sequence diagrams, Collaboration diagrams are used to show the flow
through a specific scenario of a use case. While Sequence diagrams are ordered
by time, Collaboration diagrams focus more on the relationships between the
objects.
Basic Collaboration Diagram Symbols and Notations
Object: Class
Class roles
Class roles describe how objects behave. Use the UML object symbol to
illustrate class roles, but don’t list object attributes.
Association roles:
Association roles describe how an association will behave given in a particular
situation. You can draw association roles using simple lines labeled with
stereotypes.
55
Messages:
Unlike sequence diagrams, collaboration diagrams do not have an explicit way
to denote time and instead number messages in order of execution. Sequence
numbering can become nested using the Dewey decimal system. For example,
nested messages under the first message are labeled 1.1, 1.2, 1.3, and so on. A
condition for a message is usually placed in square brackets immediately
following the sequence number. Use a * after the sequence number to indicate
a loop.
Objects:
The objects in the Collaboration diagram are the same as in the Sequence
diagram.
Diagrams:
1: Register
4: send PID and date
:user 1: send request with details
:system
3: send confortmation
:database
56
2: Payment and Verification
2: validate
1: submit certificates
:user 4: makes payment
:accountant
7: send report
:database
3: Test
6: validate
1: send test details

5: submit :system
:user
4: start test
9: send score
3: send questions 7: store score in dB
2: get questions
:databas
e
:question
bank
57
4: Issue of License
2: validate
:user 1: takes track test
:officer
5: issue license
3: enter in dB
:database
58
4. State Chart Diagram
AIM: To Design road transport authority system by using state chart diagram.
• Memory :256 MB
PROCEDURE:
A state chart diagram shows the behavior of classes in response to external stimuli.
This diagram models the dynamic flow of control from state to state within a system.
States: States representing situations during the life of an object. You can easily
illustrate a state in SmartDraw by using a rectangle with rounded corners.
Transition:
A solid arrow represents the path between different states of an object. Label the
transition with the event that triggered it and the action that results from it.
Initial State:
A filled circle followed by an arrow represents the object’s initial state.
59
Final State:
An arrow pointing to a filled circle nested inside another circle represents the object’s
final state.
Synchronization and splitting of control

A short heavy bar with two transitions entering it represents a synchronization
of control. A short heavy bar with two transitions leaving it represents a splitting of
control that creates multiple states.
Sequential States:
The sequential states in our state diagram 1 are idle, login, send problem, receive
prescription, and pay fee and log out. The sequential states in state diagram 2 are idle,
login, read problem, send problem, receive prescription, send prescription, take fee,
pay salary, logout. The sequential states of diagram 3 are idle, login, read problem,
send prescription, take salary.
60
Diagram:
Online test failed Registration
Verification &
payment
Active
Online
Test
Evaluation
Online test passed
Completed
61
5. Use case diagrams
AIM: To identify actors, use cases and relationships for representing functional
Requirement of system using Use case diagrams.
• Memory :256 MB
PROCEDURE:
Actor:
Actors represent system users. They help delimit the system and give a clearer picture
of what the system should do. It is important to note that an actor interacts with, but
has no control over the use cases.
An actor is someone or something that:
· Interacts with or uses the system

· Provides input to and receives information from the system
· Is external to the system and has no control over the use cases
Actors are discovered by examining:
· Who directly uses the system?

· Who is responsible for maintaining the system?
· External hardware used by the system
· Other systems that need to interact with the system
The needs of the actor are used to develop use cases. This insures that the system will
be that the user expected.
62
Graphical Depiction
An actor is a stereotype of a class and is depicted as a "stickman" on a use-case

diagram.
Naming
The name of the actor is displayed below the icon.

Additional information about the actor can be viewed in the Use-Case Specification
which is identical to a Class Specification with the addition of the Stereotype field set
to actor.
Use cases: A use case is a high-level piece of functionality that the system will provide
In its simplest form, a use case can be described as a specific way of using the system
from a user’s (actor’s) perspective. A more detailed description might characterize a
use case as:
· A pattern of behavior the system exhibits

· A sequence of related transactions performed by an actor and the system
· Delivering something of value to the actor
Use cases provide a means to:
· capture system requirements

· communicate with the end users and domain experts
· test the system
Use cases are best discovered by examining the actors and defining what the actor
will be able to do with the system.
Since all the needs of a system typically cannot be covered in one use case, it is usual
to have a collection of use cases. Together this use case collection specifies all the
ways of using the system.
By looking at the use cases, the customer can see what functionality will be provided,
and can agree to the system scope before the project goes any further
63
Graphical Depiction
The basic shape of a use case is an ellipse:

Naming
A use case may have a name, although it is typically not a simple name. It is often
written as an informal text description of the actors and the sequences of events
between objects. Use case names often start with a verb. For example, names of
possible use cases for an ATM machine might include Dispense Cash or Transfer
Funds.
The name of the use case is displayed below the icon.
Additional information about a use case can be viewed in the Use-Case specification.
Relationships
There are four types of relationships
1. Association
2. Includes relationship
3. Extends relationship
4. Generalization relationship.
You can draw an Association relationship from a use case to an actor.
You can draw a Generalize relationship between two use cases and /or two actors
You can draw a Dependency relationship between two use cases.
64
USECASE DIAGRAM:
send a request for

license
User
Takes track test
validate the test
Officer
issue license
Receive the details of

user
Accountant
Update the database
Send report to user and

officer
65
AIM: To identify all runtime components and implementation architecture of system

and to draw Deployment diagram
• Memory :256 MB
PROCEDURE:
A deployment diagram shows processors, devices, and connections. Each model
contains a single deployment diagram which shows the connections between its
processors and devices, and the allocation of its processes to processors.
Processor Specifications, Device Specifications, and Connection Specifications
enable you to display and modify the respective properties. The information in a
specification is presented textually; some of this information can also be displayed
inside the icons.
You can change properties or relationships by editing the specification or modifying
the icon on the diagram. The deployment diagram specifications are automatically
updated.
Basic Deployment diagram symbols and Notations
Node
A node is a physical resource that executes code components.
66
DEPLOYMENT DIAGRAM:
RTA System
User RTA
Officer
67

OOSD Lab MANUAL

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

OOSD Lab MANUAL

Загружено:

Авторское право:

Доступные форматы

B.E.

BIT- 381 OOSD LAB

List of Experiments Prescribed by Osmania University

Students have to perform the following OOSD steps on the

List of innovative experiments (If any)

9. Selection of a Case Study – Problem Statement.

Design based Experiments

S.NO Name of the Experiment Page no.

1. Use case diagrams

· Interacts with or uses the system

Actors are discovered by examining:

· Who directly uses the system?

An actor is a stereotype of a class and is depicted as a "stickman" on a use-case

The name of the actor is displayed below the icon.

· A pattern of behavior the system exhibits

Use cases provide a means to:

· capture system requirements

The basic shape of a use case is an ellipse:

There are four types of relationships

The second case where an include relationship is helpful is a situation in which a

Primary and Alternate Flow of Events

AIM: To analyze major functionalities and represent communication among objects

Element and its description Symbol

The steps involved in creating a Sequence are:

2. Draw sequence diagrams for above three use case realizations.

1. Identify flow of control for any three major use cases.

AIM: To draw activity diagram of a system to represent workflow of system using

Synchronization and splitting of control

ques tions in vigialtio n

AIM: To identify all runtime components and implementation architecture of system

Components and Nodes

su d e n t.e xe a d m i n o ffi ce r.e xe

1. Identify all implementation nodes of your system and draw deployment

AIM: Preparation of SRS document to understand the system characteristics in

3.2 FUNCTIONAL REQUIREMENTS

Write SRS for the case or system chosen by you.

AIM: To design Road Transport Authority System by using class diagram.

The various classes in our class diagram are:

o p e ra to r a d m inis tra to r a c c o unta nt o ffic e r

AIM: To design Road transport authority system by using sequence diagram.

Element and its description Symbol

The steps involved in creating a Sequence are:

:user :system :database

1: send request with details

2: Payment & Verification

:user :accountant :database

:user :system :question :database

:user :officer :database

AIM: To Design Road transport authority system by using collaboration diagram.

4: send PID and date

:user 1: send request with details

1: send test details

3: send questions 7: store score in dB

:user 1: takes track test

Synchronization and splitting of control

Online test failed Registration

Online test passed

· Interacts with or uses the system

Actors are discovered by examining:

· Who directly uses the system?

An actor is a stereotype of a class and is depicted as a "stickman" on a use-case

The name of the actor is displayed below the icon.

· A pattern of behavior the system exhibits