se lab filw

8/6/2019 se lab filw

http://slidepdf.com/reader/full/se-lab-filw 1/8

INTRODUCTION TO RATIONAL ROSE

Rational Machines was founded by Paul Levy and Mike Devlin in 1981 to provide tools to

expand the use of modern software engineering practices, particularly explicit modular

architecture and iterative development. Rational was sold for US$2.1 billion to IBM on

February 20, 2003.

Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool

intended for visual modeling and component construction of enterprise-level software

applications. In much the same way a theatrical director blocks out a play, a software

designer uses Rational Rose to visually create (model) the framework for an application by

blocking out classes with actors (stick figures), use case elements (ovals), objects (rectangles)

and messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols.

Rational Rose documents the diagram as it is being constructed and then generates code in

the designer's choice of C++, Visual Basic, Java, Oracle8, Corba or Data Definition

Language.

Two popular features of Rational Rose are its ability to provide iterative development and

round-trip engineering. Rational Rose allows designers to take advantage of iterative

development (sometimes called evolutionary development) because the new application can

be created in stages with the output of one iteration becoming the input to the next. (This is in

contrast to waterfall development where the whole project is completed from start to finish

before a user gets to try it out.) Then, as the developer begins to understand how the

components interact and makes modifications in the design, Rational Rose can perform what

is called "round-trip engineering" by going back and updating the rest of the model to ensure

the code remains consistent.

Rational Rose is extensible, with downloadable add-ins and third-party partner applications.

It supports COM/DCOM (ActiveX), JavaBeans, and Corba component standards.



INTRODUCTION TO USE CASE DIAGRAM

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral

diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical

overview of the functionality provided by a system in terms of actors, their goals (represented

as use cases), and any dependencies between those use cases.

The main purpose of a use case diagram is to show what system functions are performed for

which actor. Roles of the actors in the system can be depicted.

Diagram Building Blocks

Interaction among actors is not shown on the use case diagram. If this interaction is essential

to a coherent description of the desired behavior, perhaps the system or use case boundaries

should be re-examined. Alternatively, interaction among actors can be part of theassumptions used in the use case.

Use cases

A use case describes a sequence of actions that provide something of measurable value to an

actor and is drawn as a horizontal ellipse.

Actors

An actor is a person, organization, or external system that plays a role in one or more

interactions with the system.

System boundary boxes (optional)

A rectangle is drawn around the use cases, called the system boundary box, to indicate the

scope of system. Anything within the box represents functionality that is in scope and

anything outside the box is not.

Actor Generalization

One popular relationship between Actors is Generalization/Specialization. This is useful in

defining overlapping roles between actors. The notation is a solid line ending in a hollow

triangle drawn from the specialized to the more general actor.



Use Case Relationships

Four relationships among use cases are used often in practice.

Include

In one form of interaction, a given use case may include another. "Include is a Directed

Relationship between two use cases, implying that the behavior of the included use case is

inserted into the behavior of the including use case".

The first use case often depends on the outcome of the included use case. This is useful for

extracting truly common behaviors from multiple use cases into a single description. The

notation is a dashed arrow from the including to the included use case, with the label"«include»". This usage resembles a macro expansion where the included use case behavior

is placed inline in the base use case behavior. There are no parameters or return values. To

specify the location in a flow of events in which the base use case includes the behavior of

another, you simply write include followed by the name of use case you want to include.

Extend

In another form of interaction, a given use case (the extension) mayextend another. The

relationship indicates that the behavior of the extension use case may be inserted in the

extended use case under some conditions. The notation is a dashed arrow from the extension

to the extended use case, with the label "«extend»". The notes or constraints may beassociated with this relationship to illustrate the conditions under which this behavior will be

executed.

Modelers use the «extend» relationship to indicate use cases that are "optional" to the base

use case. Depending on the modeler's approach "optional" may mean "potentially not

executed with the base use case" or it may mean "not required to achieve the base use case

goal".

Generalization

In the third form of relationship among use cases, a generalization/specialization relationshipexists. A given use case may have common behaviors, requirements, constraints, and

assumptions with a more general use case. In this case, describe them once, and deal with it

in the same way, describing any differences in the specialized cases. The notation is a solid

line ending in a hollow triangle drawn from the specialized to the more general use case

(following the standard generalization notation)



Associations

Associations between actors and use cases are indicated in use case diagrams by solid lines.

An association exists whenever an actor is involved with an interaction described by a use

case. Associations are modeled as lines connecting use cases and actors to one another, with

an optional arrowhead on one end of the line. The arrowhead is often used to indicate thedirection of the initial invocation of the relationship or to indicate the primary actor within

the use case. The arrowheads imply control flow and should not be confused with data flow.



EXPE E T 1

________________________________________________________________

:To

draw use case diagram f o

r R egistration

system.

DIAGRAM:

The use case diagram f or the registration system is:



DISCUSSION

In the use case diagram for the registration system we have two actors student and faculty .

Actor student has four use cases login ,fill details,print and submit. Now the login further

extends to two use cases user id and password.Fill details also extends to the use cases fill

name ,fill address,fill place of stay during the year ,fill phone number and save .Print has the

use case print preview as it includes from print on clicking print preview new window

opens.The actor faculty has the use case receive ,verify and the use case submit is common

between the two actors student and faculty. Use cases receive and verify has fee receipt

,registration form and affadavits as common use cases. Associations between actors and use

cases are indicated in use case diagrams by solid lines with an arrow head. Associations of

the use cases with the further use cases are indicated by dotted lines with an arrow head.



E ERIMENT 2

AIM To draw use case diagram for ATM system.

DIAGRAM

The use case diagram for the ATM system:

DISCUSSION

In the use case diagram of the ATM system we consider only one actor user .User has the

use diagram insert card, enter pin ,select option and cancel. Now use case select option has

the use cases banking ,fund transfer ,bill payment ,change pin and cancel.Banking use case

has the use cases withdrawl, mini statement , balance inquiry and cancel.withdrawl has the

insert card

enter pin

select option

user

cancel

Banking

fund transfer

bill payment

change pin

cancel1

withdrawl

balance enquiry

Mini statement

cancl

savings

current

cancel2

enter amount

Print reciept

yes

no

collect cash

imclude

include

include

include

include

enter current pin

enter new pin

confirm new pin

include

include

include

extend

extend



use cases savings ,current and cancel .Now saving and current has the same use cases enter

amount ,print receipt and collect cash . Further print receipt has two use cases yes and no.

There is a use case change pin has three use cases enter current pin,enter new pin and confirm

new pin . Associations between actors and use cases are indicated in use case diagrams by

solid lines with an arrow head. Associations of the use cases with the further use cases are

indicated by dotted lines with an arrow head

Documents

se lab filw