Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

OOSD Lab MANUAL

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 67

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
Given case study by using:
2. Class Diagrams 9
3. Sequence Diagrams 14
4. Collaboration Diagrams 21
 The students have to perform the Behavioral Modeling step on the
Given case study by using:
5. Activity Diagrams 24
6. State Diagrams 29
 The students have to perform the Architectural Modeling step on the
Given case study by using:
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.
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:
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.
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:
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
3. Collaboration Diagram

AIM: To represent object interaction for a use case flow of control using
collaboration diagram.
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:
• 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.
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:
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.
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:
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
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:
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
8. Deployment Diagram

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


and to draw Deployment diagram
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:
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.


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:
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.


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:
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
5: enter in database
6: send conformation
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
8: send conformation
9: send score

4: Issue of License

:user :officer :database


1: takes track test

2: validate

3: enter in dB

4: send conformation
5: issue license

54
3. Collaboration Diagram

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


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:
• 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

2: enter in database
:database

56
2: Payment and Verification

2: validate

1: submit certificates
:user 4: makes payment
:accountant
3: send conformation
7: send report

6: send conformation

5: enter in database

: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

8: send conformation
2: get questions

:databas
e
:question
bank

57
4: Issue of License

2: validate

:user 1: takes track test

:officer
5: issue license

4: send conformation

3: enter in dB

:database

58
4. State Chart Diagram
AIM: To Design road transport authority system by using state chart diagram.
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:
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.
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.

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
6. Deployment Diagram

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


and to draw Deployment diagram
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:
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

You might also like