Introduction to Rational Rose/UML Q. What is Rational Rose?
Ans. Rational Rose is an object-oriented Unified Modeling Language (UML ( UML)) software design tool tool intend intended ed for visual visual modeli modeling ng and component constructi construction on of enterprise-le enterprise-level vel software 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 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++, C++, Visual Basic, Java, Java, Oracle8, Oracle8, CORBA or Data Definition Language. Two popular features of Rational Rose are its ability to provide iterat iterative ive develo developme pment nt and roundround-tri trip p engine engineeri ering. ng. Ration Rational al Rose Rose allows allows design designers ers to take take advantage of iterative development (sometimes called evolutionary development) because the new application application can be created in stages with the output of one iteration iteration becoming the input to the next. Then, as the developer begins to understand how the components 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
Drawing Window
Browser Window
Rational Rose
Documentation Window
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 timeordered. 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
ELEMENTS OF CLASS DIAGRAM
A class diagram is composed primarily of the following elements that represent the system’s business entities:
system.
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 “<>” 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 “<>” 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:
