Introduction to Rational Rose/UML

Q. What is Rational Rose?

Ans. 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 the framework for an application by blocking out classes

with actors , use case elements , objects and messages/relationships 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. 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.

The Windows In Rational Rose:

1. Browser WindowThis presents a hierarchical view of the analysis and design model, including all the diagrams and all the

individual elements that make up a diagram.

2. Drawing ToolsThis tool presents a set of icons that indicate the different elements that can be added to a diagram. The

elements that can be used will change, depending on the type of diagram being created. Different

diagram types have different sets of icons. If you were creating a different diagram type, you would see a

different set of icons. The above example is a class diagram in logical view.

3. Diagram Window

This is where the diagram is actually created. You will see that the diagram shown in the drawing

window on Figure 1 represents a high-level model of this course. Course content can be seen as a system

composed of four interacting subsystems, two of which involve software. We have used the Package

element to represent the subsystems, and the Note element to indicate which packages contain software.

4. Documentation Window

It is strongly recommended that each element added to a diagram have documentation to accompany it.

To add documentation, right click on the element, select specification, and fill in the documentation

field. The documentation will then be shown in the documentation window each time the mouse is

clicked on the element. Documentation can also be added directly to the documentation window.

Rational Rose

Different Views in Rational Rose

Views in UML/Rational Rose: There are four views for a model created in Rational Rose, each

representing the system from a different point of view.These are:

The Use Case View

Browser Window

Drawing Window

Drawing Tools

Documentation Window

The use case view contains the diagrams used in analysis (use case, sequence, and

collaboration), and all the elements that comprise these diagrams (e.g., actors). More recent

versions of Rational Rose also allow for additional documentation in the form of word-

processed documents and/or URLs to Web-based materials. The purpose of the use case view is

to envisage what the system must do, without dealing with the specifics of how it will be

implemented.

Logical View

The logical view contains the diagrams used in object design (class diagrams and state transition

diagrams). It offers a detailed view of how the system envisaged in the use case view will be

implemented. The basic element in this view is the class, which includes an outline of its

attributes and operations. This directly corresponds to a class created in your chosen

implementation language. From the logical view, skeletal code can be generated for

implementation into a computer language. More recent versions of Rational Rose not only can

generate skeletal code for Visual C++, Visual Java, or Visual BASIC, but also reverse engineer

programs created in these languages into Rational Rose models. This allows existing

components to be included in documented models, if there is access to the source code. In

addition, changes that need to be made during implementation can be reflected in the

documentation of the design model.

Component View

The component view is a step up from the logical view and contains diagrams used in system

design (component diagrams). This includes information about the code libraries, executable

programs, runtime libraries, and other software components that comprise the completed

systems. Components can be pre-existing; for example, a Windows program in Visual C++ will

utilize Microsoft Foundation Class to provide the framework for the Windows interface.

Components that do not exist and need to be created by the developers will have to be designed

in the logical view.

Deployment View

The deployment view illustrates how the completed system will be physically deployed. This

view is necessary for complex applications in which a system will have different components

located on different machines. For example, interface components may be located on a user

machine while other components may be located on a network server.

Introduction To UML Diagrams

UML DiagramsThe underlying premise of UML is that no one diagram can capture the different elements of a

system in its entirety. Hence, UML is made up of nine diagrams that can be used to model a

system at different points of time in the software life cycle of a system. The nine UML diagrams

are:

Use case diagram: The use case diagram is used to identify the primary elements and

processes that form the system. The primary elements are termed as "actors" and the

processes are called "use cases." The use case diagram shows which actors interact with

each use case.

Class diagram: The class diagram is used to refine the use case diagram and define a

detailed design of the system. The class diagram classifies the actors defined in the use

case diagram into a set of interrelated classes. The relationship or association between

the classes can be either an "is-a" or "has-a" relationship. Each class in the class diagram

may be capable of providing certain functionalities. These functionalities provided by

the class are termed "methods" of the class. Apart from this, each class may have certain

"attributes" that uniquely identify the class.

Object diagram: The object diagram is a special kind of class diagram. An object is an

instance of a class. This essentially means that an object represents the state of a class at

a given point of time while the system is running. The object diagram captures the state

of different classes in the system and their relationships or associations at a given point

of time.

State diagram: A state diagram, as the name suggests, represents the different states

that objects in the system undergo during their life cycle. Objects in the system change

states in response to events. In addition to this, a state diagram also captures the

transition of the object's state from an initial state to a final state in response to events

affecting the system.

Activity diagram: The process flows in the system are captured in the activity diagram.

Similar to a state diagram, an activity diagram also consists of activities, actions,

transitions, initial and final states, and guard conditions.

Sequence diagram: A sequence diagram represents the interaction between different

objects in the system. The important aspect of a sequence diagram is that it is time-

ordered. This means that the exact sequence of the interactions between the objects is

represented step by step. Different objects in the sequence diagram interact with each

other by passing "messages".

Collaboration diagram: A collaboration diagram groups together the interactions

between different objects. The interactions are listed as numbered interactions that help

to trace the sequence of the interactions. The collaboration diagram helps to identify all

the possible interactions that each object has with other objects.

Component diagram: The component diagram represents the high-level parts that

make up the system. This diagram depicts, at a high level, what components form part of

the system and how they are interrelated. A component diagram depicts the components

culled after the system has undergone the development or construction phase.

Deployment diagram: The deployment diagram captures the configuration of the

runtime elements of the application. This diagram is by far most useful when a system is

built and ready to be deployed.

Now that we have an idea of the different UML diagrams, let us see if we can somehow group

together these diagrams to enable us to further understand how to use them.

UML Diagram Classification—Static, Dynamic, and Implementation:

A software system can be said to have two distinct characteristics: a structural, "static" part and

a behavioral, "dynamic" part. In addition to these two characteristics, an additional

characteristic that a software system possesses is related to implementation. Before we

categorize UML diagrams into each of these three characteristics, let us take a quick look at

exactly what these characteristics are.

Static: The static characteristic of a system is essentially the structural aspect of the

system. The static characteristics define what parts the system is made up of.

Dynamic: The behavioral features of a system; for example, the ways a system behaves

in response to certain events or actions are the dynamic characteristics of a system.

Implementation: The implementation characteristic of a system is an entirely new

feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

Static

Use case diagram

Class diagram

Dynamic

Object diagram

State diagram

Activity diagram

Sequence diagram

Collaboration diagram

Implementation

Component diagram

Deployment diagram

Class Diagram

DEFINA TION

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of

static structure diagram that describes the structure of a system by showing the system’s classes,

their attributes, and the relationships between the classes.

A class diagram is similar to a family tree. A class diagram consists of a group of classes and

interfaces reflecting important entities of the business domain of the system being modeled, and

the relationships between these classes and interfaces. The classes and interfaces in the diagram

represent the members of a family tree and the relationships between the classes are analogous

to relationships between members in a family free. Interestingly, classes in a class diagram are

interconnected in a hierarchical fashion, like a set of parent classes and related child classes

under the parent classes.

AIM / PURPOSE

Design experts who understand the rules of modeling and designing systems design the

system’s class diagrams. A thing to remember is that a class diagram is a static view of a

system. The structure of a system is represented using class diagrams. Class diagrams are

referenced time and again by the developers while implementing the system.

ELEMENTS OF CLASS DIAGRAM

A class diagram is composed primarily of the following elements that represent the

system’s business entities:

Class: A class represents an entity of a given system that provides an encapsulated

implementation of certain functionality of a given entity. These are exposed by the class to other

classes as methods. Apart from business functionality, a class also has properties that reflect

unique features of a class. The properties of a class are called attributes. A class is represented

by a rectangle

Interface: An interface is a variation of a class. As we saw from the previous point, a class

provides an encapsulated implementation of certain business functionality of a system. An

interface on the other hand provides only a definition of business functionality of a system. A

separate class implements the actual business functionality.

Package: A package provides the ability to group together classes and/or interfaces that are

either similar in nature or related. Grouping these design elements in a package element

provides for better readability of class diagrams, especially complex class diagrams.

Class Diagram For ATM:

USE CASE DIAGRAM

DEFINATION:

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

• The use case diagram shows the position or context of the use case among other use cases.

• As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture

of system behavior, a common understanding between the customer/owner/user and the

development team

AIM/PURPOSE OF USE CASE DIAGRAM:

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.

ELEMENTS OF USE CASE DIAGRAM

Actors: An actor portrays any entity (or entities) that performs certain roles in a given system.

The different roles the actor represents are the actual business roles of users in a given system.

An actor in a use case diagram interacts with a use case. For example, for modeling a banking

application, a customer entity represents an actor in the application.

Use case: A use case in a use case diagram is a visual representation of a distinct business

functionality in a system. The key term here is “distinct business functionality

System boundary: A system boundary defines the scope of what a system will be. A system

cannot have infinite functionality.

RELATIONSHIPS IN USE CASE DIAGRAM :

Use cases share different kinds of relationships. A relationship between two use cases is

basically a dependency between the two use cases. Defining a relationship between two use

cases is the decision of the modeler of the use case diagram.

Include: When a use case is depicted as using the functionality of another use case in a diagram,

this relationship between the use cases is named as an include relationship An include

relationship is depicted with a directed arrow having a dotted shaft. The tip of the arrowhead

points to the parent use case and the child use case is connected at the base of the arrow. The

stereotype “<<include>>” identifies the relationship as an include relationship.

Extcnd: In an extend relationship between two use cases, the child use case adds to the existing

functionality and characteristics of the parent use case. An extend relationship is depicted with a

directed arrow having a dotted shaft, similar to the include relationship. The tip of the

arrowhead points to the parent use case and the child use case is connected at the base of the

arrow. The stereotype “<<extend>>” identifies the relationship as an extend relationship .

Generalizations: A generalization relationship is also a parent-child relationship between use

cases. The child use case in the generalization relationship has the underlying business process

meaning, but is an enhancement of the parent use case. In a use case diagram, generalization is

shown as a directed arrow with a triangle arrowhead. The child use case is connected at the base

of the arrow. The tip of the arrow is connected to the parent use case.

STEPS TO CONSTRUCT USE CASE DIAGRAM

1. Actors: List the actors that interact and participate in this use case.

2. Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform.

3. Post-conditions: Defme the different states in which you expect the system to be in, after

the use case executes.

4. Basic Flow: List the basic events that will occur when this use case is executed.

Include all the primaiy activities that the use case will perform.

5. Alternative flows: Any subsidiary events that can occur in the use case should be listed

separately. Each such event should be completed in itself to be listed as an alternative flow.

6. Special Requirements: Business rules for the basic and alternative flows should be listed as

special requirements in the use case narration.

7. Use case relationships: For complex systems, it is recommended that you document the

relationships between use cases. If this use case extends from other use cases or includes the

functionality of other use eases, these relationships should be listed here.

Use Case Diagram Of Cash Withdrawal Through an ATM Machine

SEQUENCE DIAGRAM

DEFINATION:

A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of

methods in each object, and the order in which the invocation occurs is captured in a Sequence

diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic

behavior of a system .

AIM/PURPOSE:

A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of

the object that it represents, while on the vertical axis, it shows the sequence of the creation or

invocation of these objects. Sequence diagram is very useful in elaborating and detailing the

dynamic design and the sequence and origin of invocation of objects. Hence, the Sequence

diagram is one of the most widely used dynamic diagrams in UML

ELEMENTS OF A SEQUENCE DIAGRAM:

Object: A Sequence diagram consists of sequences 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.

An Object

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.

A Message

Sequence Diagram For ATM:

COLLABORATION DIAGRAM

DEFINATION:

A Sequence diagram is dynamic, and, more importantly, is time ordered. A distinguishing

feature of a Collaboration diagram is that it shows the objects and their association with other

objects in the system apart from how they interact with each other. The association between

objects is not represented in a Sequence diagram.

AIM/PURPOSE:

A Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves in

other words, it shows the dynamic interaction of the objects in a system.

ELEMENTS IN A COLLABORA TION DIAGRAM

Object: The objects interacting with each other in the system. Depicted by a rectangle with the

name of the object in it, preceded by a colon and underlined.

An Object

Relation/Association: A link connecting the associated objects. Qualifiers can be placed on

either end of the association to depict cardinality.

A Relation

Messages: An arrow pointing from the commencing object to the destination object shows the

interaction between the objects. The number represents the order/sequence of this interaction.

A Message

Collaboration Diagram For ATM:

StateChart Diagram

DEFINATION

State Chart diagrams, often used in real time embedded systems than in information

systems ,show for class, the order in which incoming calls to operations normally occur and the

conditions under which the operation respond and the response.

AIM / PURPOSE

They are class centric view of system functionality, as opposed to sequence diagram and

collaboration diagram which are use case centric view of system functionality

ELEMENTS OF STATE CHART DIAGRAM

States: Oblong boxes which indicate the stable state of the object between events.

Transitions: The solid arrow which shows possible change of states.

Events: The text on the transition before the ‘/’ showing the incoming call to the object

interface which causes change of the state

Conditions: A Boolean statement in square brackets which qualifies the events.

Actions: The text after the ‘/’ which defines the object response to the transition

between states.

Extra syntax defines state centric functionality.

StateChart Diagram For ATM:

Activity Diagram

DEFINATION

Activity Diagrams are diagram techniques showing workflows of stepwise activities and

actions, with support for choice, iteration and concurrency.

AIM /PURPOSE

In the Unified Modeling language, activity diagrams can be used to describe the business and

operational step by step workflows of a components in a system. An Activity Diagram shows

the overall flow of control. It can be used to detail a business process, or to help define complex

iteration and a selection in a use case description.

ELEMENTS OF ACTIVITY DIAGRAM

Initial Activity: This shows the starting point or first activity of the flow. This is

denoted by a solid circle. This is similar to the notation used for initial state

Activity: Represented by a rectangle with rounded or oval edges.

Decisions: Similar to a flow chart, a logic where a decision is to be made is depicted by

a diamond, with the options written on either sides of the arrows emerging from the

diamond, within box brackets.

Signal: When an activity sends or receives a message, that activity is called a signal.

Signals are of two types: Input Signal –Concave polygon and output signal –Convex

Polgon.

Concurrent Activities: Some activities occur simultaneously or in parallel. Such

activities are called Concurrent activities. For example: Listening to a lecturer and

looking on a blackboard is a concurrent activity.

Final Activity: The end of the activity diagram is shown by a bull’s eye symbol also

called as final activity.

Activity Diagram For ATM: