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

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 the assumptions 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) may extend 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 be associated 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 relationship exists. 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 the direction 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 T1

________________________________________________________________

: To draw use case diagram for Registration system.

DIAGRAM:
The use case diagram for 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.

ERIMENT 2

AIM To draw use case diagram for ATM system.

DIAGRAM
The use case diagram for the ATM system:
extend include insert card include yes Banking include enter pin imclude balance enquiry current Print reciept no user Mini statement cancel2 collect cash select option include cancl withdrawl savings enter amount

extend

include include fund transfer

include cancel bill payment enter current pin

change pin enter new pin

cancel1 confirm new pin

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

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