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 Usecase Diagrams

1

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

*d Deployment Diagrams 66

2

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.

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

4

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

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

http://www.books24x7.com/viewer.asp?bkid=3219&image_src=http://images.books24x7.com/bookimages/id_3219/f0402%5F0%2Ejpg&image_id=155&previd=IMG_155&titlelabel=Figure+4%2E2%3A+&title=+An+includes+relationship

http://www.books24x7.com/viewer.asp?bkid=3219&image_src=http://images.books24x7.com/bookimages/id_3219/f0403%5F0%2Ejpg&image_id=156&previd=IMG_156&titlelabel=Figure+4%2E3%3A+&title=+An+extends+relationship

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 relationships8. Draw a Main and sub use case diagrams for you system.

10

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

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

WindowOriginSize

Open ()Close ()Display ()

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

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

Lifeline

15

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

http://www.books24x7.com/viewer.asp?bkid=3219&image_src=http://images.books24x7.com/bookimages/id_3219/g0508%5F0%2Ejpg&image_id=257&previd=IMG_257

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

DIAGRAM:

Login:

18

Notification:

Questions and key preparation:

19

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.

Basic Collaboration Diagram Symbols and Notations

Class roles

21

Object: Class

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:

Notification:

22

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

5. Activity Diagram

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

swim lanes and without swim lanes.



23




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

Object

Object Flow

Start State

States

Swim lanes

Synchronizations

Transitions

24

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

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

25

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

SynchronizationA synchronization bar helps illustrate parallel transitions. Synchronization is also

called forking and joining.

Swim lanes

Swim lanes group related activities into one column.

26

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:

enter id

idle

enter id

enter password

enter password

questions prep

invigialtion

setup test centers

appoint faculty

send results

manage database

questions prep

invigialtion

setup test centers

appoint faculty

send results

manage database

31

Faculty:

idle

enter id

enter password

questions prep

invigialtion

enter id

enter password

questions prep

invigialtion

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.

Diagram:

37

db server

data base.ddl

system

user

sudent.exefaculty.exe

service manager

admin officer.execonveynor.exe

Exercise

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

9. Selection of a Case Study – Problem Statement

AIM: Select the problem to be solved as case study by each team and preparation of

38

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.

42

3.3.3 Take test: - the students write the test.

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.

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.

WindowOriginSize

Open ()Close ()Display ()

45

ISpelling

The various classes in our class diagram are:

RTA

Employee

Operator

Administrator

Accountant

Officer

Helpdesk

Applicant

Report

46

Diagram:

officernameid

test drive prep()invigilation()issue licence()

Employeenameid

salary()

RTARegionCodePhnoAdd

Provide Facilities()

helpdesknameid

respond to queries()

operatornameid

accept reg()allot pid()

administratornameid

record maintenance()record classification()

applicantnamepid

gets registered()takes test()bill payments()

accountantnameid

accept payments()generate bills()prepare report()

reportno

daily report()monthly report()

verification

certificates

test

2. Sequence Diagram

47

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

Lifeline

49

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

2: enter in database

3: send confortmation4: send PID and date

1: send request with details

2: Payment & Verification

:user :accountant :database

1: submit certificates

2: validate

3: send conformation

4: makes payment5: enter in database


7: send report

3: Test

53

:user :system :question bank

:database

1: send test details2: get questions

3: send questions

5: submit

4: start test

6: validate7: store score in dB

8: send conformation9: send score

4: Issue of License

:officer:user :database

1: takes track test

2: validate

3: enter in dB

4: send conformation5: 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

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

55

Object: Class

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

:user

:system

:database

4: send PID and date

1: send request with details


3: send confortmation

2: Payment and Verification

56

:user

:accountant

:database

2: validate

1: submit certificates4: makes payment

3: send conformation7: send report



3: Test

:user

:system

:question bank

:database

6: validate

1: send test details5: submit

4: start test9: send score

2: get questions

3: send questions 7: store score in dB


4: Issue of License

57

:user

:officer

:database

2: validate

1: takes track test

5: issue license

3: enter in dB


4. State Chart Diagram

58

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.

Diagram:

60

Registration

Verification & payment

Completed

Active

Online Test

Evaluation

Online Test

Evaluation

Online test failed

Online test passed

5. Use case diagrams

61

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.

Graphical Depiction

62

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.

USECASE DIAGRAM:

64

Takes track test

send a request for license

User

validate the test

Officerissue license

Update the database

Send report to user and officer

Accountant

Receive the details of user


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:

User

RTA System

RTA Officer

67

oosd lab manual

Documents