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 Window
This 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 Tools
This 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.

Drawing Tools

Browser Drawing Window

Window

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

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 Diagrams
The 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: