Introduction of Rational Rose and UML

Unified Modeling Language (UML) was created in 1995 by merging diagramming conventions
used by three software development methodologies: OMT by James Rumbaugh, Objectory by
Ivar Jacobson and the Booch Method by Grady Booch. Prior to this time, these three amigos,
along with about a dozen other practitioners had promoted competing methodologies for
systematic software development, each with its own system of diagramming conventions. The
methodologies followed a kind of cookbook style of pushing a software project through a
succession of life cycle stages, culminating with a delivered and documented application. One
goal of UML was to reduce the proliferation of diagramming techniques by standardizing on a
common modeling language, thus facilitating communication between developers. It achieved
that goal in 1997 when the (international) Object Management Group (OMG) adopted it as a
standard.

Some critics consider that UML is a bloated diagramming language written by a committee.
That said, I consider it to be the best means available today for documenting object-oriented
software development. It has been and is becoming increasingly used in industry and academia.

It should be stressed that UML is not a methodology, rather it is a language for expressing
software models. Conceivably, it can be used with various software methodologies. However,
separately from the UML, the three amigos have developed the Rational Unified Process, a
methodology that is use case driven, and carried out using UML models.

Rational Rose is a Computer Aided Software Engineering (CASE) tool developed by the
Rational Corporation under the direction of Booch, Jacobson and Rumbaugh to support software
development using UML. Rational Rose is necessarily complex owing to its mission of fully
supporting UML. In addition, Rational Rose has numerous language extensions to Ada, C++,
VB, Java, J2EE, etc. Rational Rose supports forward and reverse engineering to and from these
languages. On the other hand, Rational Rose does not support some traditional design
techniques as data flow diagrams and CRC cards, since these are not part of UML.

Because Rational Rose has so many capabilities it is a daunting task to master it. Fortunately, a
lot can be done using just a small subset of these capabilities. These notes are designed to
introduce novice developers into making productive use of such a subset. They reflect the
author’s bias towards developing software and should not be taken as the last word on the
subject.

Rational Rose Views Related to the Software Development

Life Cycle
Rational Rose models have these four views:
1. Use Case View
2. Logical View
3. Component View
4. Deployment View
I like to use a Software Development Life Cycle with these phases:

0. Project Initiation
1. Requirements
2. Design
2.1 Architectural Design
2.2 Detail Design
3. Implementation
4. Maintenance

0. Project Initiation

The project initiation phase involves identifying a problem that need a software solution,
investigating to see if an adequate solution is already available for purchase, if not, working up
an informal proposal outlining new software to be built and making the case that the expected
benefits justify the cost. Rational rose need not be involved in this phase.

1. Requirements

The requirements phase involves eliciting requirements from the client and presenting them in a
formal contractual document that will later serve as the basis for acceptance of the finished
project. Getting the requirements right is key to the success of the project. However, the
software developers are usually not expert on the client’s business environment, nor are the
clients necessarily good at expressing what their real requirements are. The developers need to
work with the clients to determine the real requirements.

• Use Case Diagram - The best tool I know of for talking about requirements is the use
case diagram, developed by Jacobson. The diagrams and the use case technique are so
simple that clients instantly relate to them and will readily volunteer usual and
exceptional scenarios to go along with each use case. The use cases are recorded in the
use case view of rational rose.

Some other diagrams strictly speaking belong to the design phase, but may also be useful in the
requirements phase. They are constructed in Rational Rose’s Logical View.

• Class Diagram – As part of the requirements process entity classes are identified and
described in terms of attributes, operations and associations using the UML class
diagram. A class is an entity class if it forms part of the client’s business model. So, for
example, if the client is running a hospital, possible entity classes are: Patient, Doctor,
Nurse, Therapist, Bed, Treatment, Diagnosis, etc. On the other hand, classes such as
Form, Canvas, Button, Socket, etc. are not entity classes. They are classes needed to
implement the solution, but are not meaningful in describing the client’s business, hence
not part of the requirements phase.
 Another way to look at entity classes is from a database point of view. The entity classes
are usually the persistent ones, i.e. they describe the objects, which the system will
permanently track in a database.

• Sequence Diagram (Logical View)– Object-Oriented systems get work done by sending
messages between objects, invoking functions to obtain services. Sequence diagrams are
designed to help visualize the messaging. Each use case results in one or more sequence
diagrams, a main sequence diagram to illustrate the usual scenario for the use case and
zero or more additional sequence diagrams to illustrate exceptional scenarios. One or
two sequence diagrams are appropriate in the requirements phase; they are helpful in
refining and adding to use cases, and discovering entity classes. The bulk of sequence
diagrams belong to the design phase.

• Component and Deployment diagrams are primarily used in the architectural design
phase. They show the division of software responsibilities into software components or
modules, and the deployment of modules to various devices. However, for some projects
such as web applications, client-server and multi-tiered configurations, etc. these issues
are so important that the developer may wish to discuss them with the client during
requirements analysis. In Rational Rose, these diagrams properly belong in the
Component and Deployment views, respectively.

2.1 Architectural Design

The architectural design phase is used to divide up system responsibilities into subsystems. The
subsystems (modules) are identified, responsibilities assigned to them, and interfaces between
modules are specified. A general scheme for the software architecture is chosen. For example:
client/server, layered services, model-view-controller, etc. The data model is refined including
levels of access for different actors.

The following UML diagrams are useful at this stage:

• Class Diagram (Logical View) – Classes are grouped into packages representing
subsystems.
• Component Diagram (Component View) – Components and interfaces are defined.
• Deployment Diagram (Deployment View) – Software components are mapped to
hardware components.

2.2 Detail Design

The modules identified in architectural design need to be fully specified prior to implementation.

The following UML diagrams are useful at this stage:

• Class Diagram (Logical View) – Entity classes were identified by analyzing the problem
space during the requirements phase. These are now supplemented with additional
solution classes needed to build interfaces, maintain persistent data, manage
communications, etc.
 The expanded class diagram is reexamined to take advantage of factoring out common
behavior into abstract superclasses, simplify associations and otherwise make the design
more cohesive.

• Sequence Diagram (Logical View) – A complete set of sequence diagrams is now drawn
for each of the use cases identified as requirements. As mentioned earlier, each use case
has a usual scenario and perhaps several exceptional scenarios. Rather than attempt to
show branching in the sequence diagrams, usually a separate diagram is drawn for each
scenario.

• State chart Diagram (Logical View) – The state of an object is the current set of values of
all its attributes (including inherited ones). Objects may change state in response to
messages received. The statechart diagram shows all the states, transitions between states
labeled by the messages, which cause them, and guards on transitions.
• Activity Diagram (Logical View) – These diagrams are similar to the familiar flowcharts.
They show activities (processes) and the flow of control and data between activities.

Together the sequence, statechart and activity diagrams form the dynamic model of the system.
In general, the system is at rest until an actor initiates a use case by requesting a system function.
This causes a flurry of messages and state changes as predicted by the dynamic model.

3. Implementation
In the implementation phase the detailed design is actually carried out in program code using a
target language. Data definition language is written to create and populate the database tables
and grant role-based privileges. Reports and interactive forms are written, as well as help files
and exception handling routines.

The implementation phase is characterized by testing, unit tests to see if individual modules
work correctly, integration tests to ensure that the modules work together properly to carry out
the use cases. Tested modules are deployed to the target hardware and retested on site. Finally,
acceptance testing verifies that the system carries out its various functions correctly, i.e.
according to their specification in the requirements document.

Rational Rose provides extensive support for implementation:

• Model checking.
• Forward code generation (from model to source code) in a variety of target languages.

5. Maintenance
 INTRODUCTION OF USE CASE DIAGRAM
use case diagram is “a diagram that shows the relationships among actors and use
cases within a system.” Use case diagrams are often used to:

• Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model
• Communicate the scope of a development project

• Model your analysis of your usage requirements in the form of a system use
case model

A use case model is comprised of one or more use case diagrams and any supporting
documentation such as use case specifications and actor definitions. Within most use case
models the use case specifications tend to be the primary artifact with use case diagrams filling a
supporting role as the “glue” that keeps your requirements model together. Use case models
should be developed from the point of view of your project stakeholders and not from the (often
technical) point of view of developers. There are guidelines for:

1. Use Cases
2. Actors
3. Relationships
4. System Boundary Boxes

1. Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor. A use
case is drawn as a horizontal ellipse on a UML use case diagram, as you see in Figure 1.

1. Use Case Names Begin With a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases. As you see in Figure 1, the use
cases that typically occur first are shown above those that appear later.

Figure 1. Implying timing considerations between use cases.

2. Actors

An actor is a person, organization, or external system that plays a role in one or more interactions
with your system (actors are typically drawn as stick figures on UML Use Case diagrams).

Figure 2. Online shopping.

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
 7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use case diagram:

• An association between an actor and a use case

• An association between two use cases
• A generalization between two actors
• A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional open-
headed arrowhead on one end of the line indicating the direction of the initial invocation of the
relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing
towards the more general modeling element.

Figure 3. Enrolling students in a university.

1. Indicate An Association Between An Actor And A Use Case If The Actor Appears
Within The Use Case Logic
2. Avoid Arrowheads On Actor-Use Case Relationships
3. Apply <<include>> When You Know Exactly When To Invoke The Use Case
4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly New Business
Logic
 7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the “Is Like” Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the “Is Like” Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name suggests it
indicates the scope of your system – the use cases inside the rectangle represent the functionality
that you intend to implement.

1. Indicate Release Scope with a System Boundary Box. In Figure 2 you see that three
system boundary boxes are included, each of which has a label indicating which release
the various use cases have been assigned to.
2. Avoid Meaningless System Boundary Boxes.

A use case typically includes the following information:

• Name: The name of the use case
• Brief Description: A brief description of the role and purpose of the use case
• Flow of Events: A textual description of what the system does in regard to a use case
scenario (not how specific problems are solved by the system). Write the description so
that the customer can understand it. The flows can include a basic flow, alternative flows,
and subflows.
• Key scenarios: A textual description of the most important or frequently discussed
scenarios
• Special Requirements: A textual description that collects all of the requirements of the
use case that are not considered in the use-case model, but that must be taken care of
during design or implementation (for example, non-functional requirements)
• Preconditions: A textual description that defines a constraint on the system when the use
case starts
• Post-conditions: A textual description that defines a constraint on the system when the
use case ends
• Extension points: A list of locations within the flow of events of the use case at which
additional behavior can be inserted by using the extend-relationship
 Activity Diagram in the Use-Case Model

The flow of events of a use case describes what needs to be done by the system to provide value
to an actor. It consists of a sequence of activities that together produce something for the actor.
The flow of events consists of a basic flow, and one or several alternative flows.

The flow of events of a use case can be described graphically with the help of an activity
diagram. Such a diagram shows:

• Activity states, which represent the performance of an activity or step within the flow of
events.
• Transitions that show what activity state follows after another. This type of transition is
sometimes referred to as a completion transition, since it differs from a transition in that it
does not require an explicit trigger event, it is triggered by the completion of the activity
the activity state represents.
• Decisions for which a set of guard conditions are defined. These guard conditions
control which transition (of a set of alternative transitions) follows once the activity has
been completed. Decisions and guard conditions allow you to show alternative threads
in the flow of events of a use case.
• Synchronization bars which you can use to show parallel subflows. Synchronization
bars allow you to show concurrent threads in the flow of events of a use case.
A simplified activity diagram for the use case Withdraw Money in the use-case model of an
automated teller machine (ATM).

Activity diagram is a special case of a statechart diagram in which all or most of the states are
activity states and in which all or most of the of the transitions are triggered by completion of
actions in the source states.

Architecture of activity diagrams

Basic Nodes

According to Conrad Bock (2003), there there are three kinds of nodes in activity models:

1. Action nodes operate on control and data values that they receive, and provide control
and data to other actions.
2. Control nodes route control and data tokens through the graph. These include constructs
for choosing between alternative flows (decision points), for proceeding along multiple
flows in parallel (forks), and so on.
 3. Object nodes hold data tokens temporarily as they wait to move through the graph.
Below, the notation for some of the activity nodes to be discussed. Contrary to the names,
control nodes coordinate both data flow and control flow in the graph, and object nodes
can hold both objects and data

Action nodes

• Represented by a rectangle with rounded corners (drawn in slightly different ways

depending on the software used ...)
• Action nodes should have a label

Object nodes

• Represented by a rectangle with a label (i.e. UML class boxes)

Decision and merge control node

• Represented by a lozange

Fork and join control node

• Forks and joins are represented by a horizonal or vertical line (and incoming and
outgoing flows)
• One or more activities can fork.
• One or more activities can join

Initial node

• Represented by a fat black dot

• There can be only one initial (starting) node

Final nodes

• A fat black dot inside a circle (bull's eye symbol)

• A circle with an x represents the end of a flow (not the whole activity)
Below is a complete example User eats until he has had enough. Then he both reads a book and
listens to some music, until he stops.

Flows

Flows (or edges) describe connections between 2 actions. These edges can be drawn with
arrows in various ways.

Usually in activity diagrams, actions are simply connected through an unlabelled arrow. In
addition, you also can include an object in the flow. These objects can carry data. Finally, instead
of objects one can use "pins".

The control flow is modeled in terms of tokens. The start node will create a token which then
goes to next action. After the action executes, the token will go to the next action. When it
encounters a fork, the fork will create a token for each of its outbound flows. The opposite
happens for joins. It will produce an outbound token once all inbound tokens arrived.

Simple flows

• Simple flows are represented by an arrow from an activity showing parameters with pins
from a node to another

Simple flows with connectors

An arrow to a connector (a small circle with a letter) and then from a same connector to a
activity node does the same job as a simple arrow. (not shown here)

Flows with objects

 • Activity node to object node to activity node (with arrows). Object nodes

Flows with pins

• These are similar to flows with objects. A pin represents data needed and data produced.
• The flow is represented by an arrow and a pin is a small rectangle added to an activity
rounded rectangle (no picture here)

Decision flows

• Outgoing arrows from decision nodes are usually labeled.

Signals

Actions in a diagram also can respond to signals (instead of the flow)

Time signals

• Represented like an hour glass

Input Accept signal (accept)

• Represented by a concave pentagon (a smashed-in rectangle)

Output signal (send)

• Represented by a convex polygon

Partitions and subactivities

Subactivities

• Activities can be decomposed into subactivities. They can have input or output
parameters.
• A rake in an action node signals a subactivity
• The subsidiary activity diagram has an input and an output parameter (object nodes)

Partititions

• An activity can be partitioned in a swimlanes

• Each swimlane (partition) typically represents a player or role (e.g. learner A, learner B,
group A, teacher). See below for some examples
 UML sequence diagram
UML sequence diagrams are used to represent or model the flow of messages, events and actions
between the objects or components of a system. Time is represented in the vertical direction
showing the sequence of interactions of the header elements, which are displayed horizontally at
the top of the diagram.

Sequence Diagrams are used primarily to design, document and validate the architecture,
interfaces and logic of the system by describing the sequence of actions that need to be
performed to complete a task or scenario. UML sequence diagrams are useful design tools
because they provide a dynamic view of the system behavior which can be difficult to extract
from static diagrams or specifications.

Although UML sequence diagrams are typically used to describe object-oriented software
systems, they are also extremely useful as system engineering tools to design system
architectures, in business process engineering as process flow diagrams, as message sequence
charts and call flows for telecom/wireless system design, and for protocol stack design and
analysis.

1. Sequence Diagram Drawing Elements

This tutorial describes the basic drawing elements used in sequence diagrams and when they are
used. These are the diagram elements that are supported by the Sequence Diagram Editor tool.
Some are not part of the UML specification and may not be supported by other UML tools.

Sequence Diagram Header Elements

The header portion of the sequence diagram represents the components or objects of the system
being modeled and are laid out horizontally at the top of the diagram. See an example sequence
diagram here.

Actor Represents an external person or entity that interacts

with the system
Object Represents an object in the system or one of its
components

Unit Represents a subsystem, component, unit, or other

logical entity in the system (may or may not be
implemented by objects)
Separator Represents an interface or boundary between
subsystems, components or units (e.g., air interface,
Internet, network)
Group Groups related header elements into subsystems or
components

Sequence Diagram Body Elements

Action Represents an action taken by an actor, object or

unit
Asynchronous An asynchronous message between header
Message elements

Block A block representing a loop or conditional for a

particular header element

Call Message A call (procedure) message between header

elements
Create Message A "create" message that creates a header element
(represented by lifeline going from dashed to solid
pattern)
Destroy Element Represents the destruction of a header element

Destroy Message Represents the destruction of a header element as a

result of a call from another element
Diagram Link Represents a portion of a diagram being treated as
a functional block. Similar to a procedure or
function call that abstracts functionality or details
not shown at this level. Can optionally be linked to
another diagram for elaboration.
Else Block Represents an "else" block portion of a diagram
block

Flow Note Documentation note that is automatically

formatted to flow after previous elements
Free Note Documentation note that is free-flowing and can
be placed anywhere in the diagram (can also be
anchored relative to a flow element)
Message A simple message between header elements

Page Break A page break in the diagram

Return Message A return message between header elements

Scenario Start Start of a scenario (set of alternatives)

Scenario Case Start of an alternative or case in a scenario

Scenario End End of a scenario

State A state change for a header element

Steady State A steady state in the system

Timer Start Start of a timer for a particular header element

Timer Stop Stop of a timer for a particular header element

Timer Expiration Expiration of a timer for a particular header

element

2. What can be modeled using sequence diagrams?

Sequence diagrams are particularly useful for modeling:

• Complex interactions between components. Sequence diagrams are often used to

design the interactions between components of a system that need to work together to
accomplish a task. They are particularly useful when the components are being developed
in parallel by different teams (typical in wireless and telephony systems) because they
support the design of robust interfaces that cover multiple scenarios and special cases.
• Use case elaboration. Usage scenarios describe a way the system may be used by its
actors. The UML sequence diagram can be used to flesh out the details of one or more
use cases by illustrating visually how the system will behave in a particular scenario. The
use cases along with their corresponding sequence diagrams describe the expected
behavior of the system and form a strong foundation for the development of system
architectures with robust interfaces.
• Distributed & web-based systems. When a system consists of distributed components
(such as a client communicating with one or more servers over the Internet), sequence
diagrams can be used to document and validate the architecture, interfaces and logic of
each of these components for a set of usage scenarios.
• Complex logic. UML sequence diagrams are often used to model the logic of a complex
feature by showing the interactions between the various objects that collaborate to
implement each scenario. Modeling multiple scenarios showing different aspects of the
feature helps developers take into account special cases during implementation.
• State machines. Telecom, wireless and embedded systems make extensive use of
state machine based designs where one or more state machines communicate with each
other and with external entities to perform their work. For example, each task in the
protocol stack of a cellular phone goes through a series of states to perform actions such
 as setup a call or register with a new base station. Similarly the call processing
components of a Mobile Switching Center use state machines to control the registration
and transfer of calls to roaming subscribers. Sequence diagrams (or call flows as they are
commonly referred to in the telecom and wireless industry) are useful for these types of
applications because they can visually depict the messages being exchanged between the
components and their associated state transitions.

3. Benefits of using UML sequence diagrams

These are some of the main benefits of using UML sequence diagrams.

1. Help you discover architectural, interface and logic problems early. Because they allow
you to flesh out details before having to implement anything, sequence diagrams are useful tools
to find architectural, interface and logic problems early on in the design process. You can
validate your architecture, interfaces, state machine and logic by seeing how the system
architecture would handle different basic scenarios and special cases.

This is particularly true for systems involving the interaction of components that are being
implemented in parallel by different teams. In the cell phone example, each task would typically
be implemented by a separate team. Having a set of sequence diagrams describing how the
interfaces are actually used and what messages/actions are expected at different times gives each
team a consistent and robust implementation plan. You can also document how special cases
should be handled across the entire system.

The very act of creating the sequence diagrams and making them work with your architecture is
valuable because it forces you to think about details such as interfaces, states, message order,
assignment of responsibilities, timers/timeouts and special/error cases ahead of time.

2. Collaboration tool. Sequence diagrams are valuable collaboration tools during design
meetings because they allow you to discuss the design in concrete terms. You can see the
interactions between entities, various proposed state transitions and alternate courses/special
cases on paper as you discuss the design.

In our experience, having a concrete design proposal during design meetings greatly enhances
the productivity of these meetings even if the proposed design has problems. You can narrow
down the problems and then make corrections to solve them. The proposal serves as a concrete
starting point for the discussion and as a place to capture proposed changes.

Sequence diagram editor makes it so easy to edit your sequence diagrams that you could even
make the corrections in real time during the meeting and instantly see the result of the changes as
you make them.
3. Documentation. Sequence diagrams can be used to document the dynamic view of the system
design at various levels of abstraction, which is often difficult to extract from static diagrams or
even the complete source code. The diagrams can abstract much of the implementation detail and
provide a high level view of system behavior.

One of our colleagues shared this experience of joining the software team for a wireless
switching subsystem component:

"Our component was the primary interface between the call processing component of the
wireless base station and the Public Switched Telephone Network and had to support several
different network protocols including T1, E1 and SS7. The previous lead had developed several
dozen call flows describing the basic messaging and state transitions for common operations
such as call setups including mobile and land originated, call teardowns and features such as call
waiting and three way calling for each of the protocols, since each involved different states and
messages with the switching component. I found these diagrams invaluable in helping me learn
the software, interfaces and state machine and would refer to them often, even after working in
the project for a couple of years."

UML Class diagram

UML class diagrams show the classes of the system, their inter-relationships, and the operations
and attributes of the classes. Class diagrams are typically used, although not all at once, to:

• Explore domain concepts in the form of a domain model

• Analyze requirements in the form of a conceptual/analysis model

• Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting specifications that
describe model elements including classes, relationships between classes, and interfaces. There
are guidelines for:

1. General issues
2. Classes
3. Interfaces
4. Relationships
5. Inheritance
6. Aggregation and Composition

1. General Guidelines

Because class diagrams are used for a variety of purposes – from understanding requirements to
describing your detailed design – you will need to apply a different style in each circumstance.
This section describes style guidelines pertaining to different types of class diagrams.
Figure 1. Analysis and design versions of a class.

Figure 2. Modeling association classes.

1. Identify Responsibilities on Domain Class Diagrams.

2. Indicate Visibility Only On Design Models.
3. Indicate Language-Dependent Visibility With Property Strings.
4. Indicate Types Only On Design Models.
5. Indicate Types On Analysis Models Only When The Type is an Actual Requirement.
6. Design Class Diagrams Should Reflect Language Naming Conventions. In Figure 1 you
see that the design version of the Order class uses names that conform to common Java
programming conventions such as placementDate and calculateTaxes().
7. Model Association Classes On Analysis Diagrams. Figure 2 shows that association
classes are depicted as class attached via a dashed line to an association – the association
line, the class, and the dashed line are considered one symbol in the UML.
8. Do Not Name Associations That Have Association Classes.
 9. Center The Dashed Line of an Association Class.

2. Class Style Guidelines

A class is effectively a template from which objects are created (instantiated). Although in the
real world Doug, Wayne, John, and Bill are all student objects we would model the class Student
instead. Classes define attributes, information that is pertinent to their instances, and operations,
functionality that the objects support. Classes will also realize interfaces (more on this later).
Note that you may need to soften some of the naming guidelines to reflect your implementation
language or software purchased from a third-party vendor.

Figure 3. The OrderItem class with and without scaffolding code.

Figure 4. Indicating the exceptions thrown by an operation.

+ findAllInstances(): Vector {exceptions=NetworkFailure, DatabaseError}

1. Use Common Terminology for Names

2. Prefer Complete Singular Nouns for Class Names
3. Name Operations with a Strong Verb
4. Name Attributes With a Domain-Based Noun
5. Do Not Model Scaffolding Code. Scaffolding code refers to the attributes and operations
required to implement basic functionality within your classes, such as the code required
to implement relationships with other classes. Figure 3 depicts the difference between
the OrderItem class without scaffolding code and with it.
6. Never Show Classes With Just Two Compartments
 7. Label Uncommon Class Compartments
8. Include an Ellipsis ( … ) At The End of Incomplete Lists
9. List Static Operations/Attributes Before Instance Operations/Attributes
10. List Operations/Attributes in Decreasing Visibility
11. For Parameters That Are Objects, Only List Their Type
12. Develop Consistent Method Signatures
13. Avoid Stereotypes Implied By Language Naming Conventions
14. Indicate Exceptions In An Operation’s Property String. Exceptions can be indicated with
a UML property string, an example of which is shown in Figure 4.

3. Interfaces

An interface is a collection of operation signature and/or attribute definitions that ideally defines
a cohesive set of behaviors. Interfaces are implemented, “realized” in UML parlance, by classes
and components – to realize an interface a class or component must implement the operations
and attributes defined by the interface. Any given class or component may implement zero or
more interfaces and one or more classes or components can implement the same interface.

Figure 5. Interfaces on UML class diagrams.

1. Interface Definitions Must Reflect Implementation Language Constraints. In Figure 5

you see that a standard class box has been used to define the interface PersistentObject
(note the use of the <<interface>> stereotype).
2. Name Interfaces According To Language Naming Conventions
3. Apply “Lollipop” Notation To Indicate That A Class Realizes an Interface
4. Define Interfaces Separately From Your Classes
5. Do Not Model the Operations and Attributes of an Interface in Your Classes. In Figure 5
you’ll notice that the Shipment class does not include the attributes or operations defined
by the two interfaces that it realizes.
6. Consider an Interface to Be a Contract
4. Relationship Guidelines

For ease of discussion the term relationships shall include all UML concepts such as
associations, aggregation, composition, dependencies, inheritance, and realizations – in other
words, if it’s a line on a UML class diagram we’ll consider it a relationship.

Figure 6. Shipping an order.

Figure 7. Modeling an order.

Figure 8. Professors and seminars.

Figure 9. Modeling people at a university.

 1. Model Relationships Horizontally
2. Collaboration Indicates Need for a Relationship
3. Model a Dependency When The Relationship is Transitory
4. Depict Similar Relationships Involving A Common Class As A Tree. In Figure 6 you see
that both Delivery and Order have a dependency on OIDGenerator. Note how the two
dependencies are drawn in combination in “tree configuration”, instead of as two separate
lines, to reduce clutter in the diagram.
5. Always Indicate the Multiplicity
6. Avoid a Multiplicity of “*”
7. Replace Relationships By Indicating Attribute Types. In Figure 7 you see that Customer
has a shippingAddress attribute of type Address – part of the scaffolding code to maintain
the association between customer objects and address objects.
8. Do Not Model Implied Relationships
9. Do Not Model Every Single Dependency
10. Center Names on Associations
11. Write Concise Association Names In Active Voice
12. Indicate Directionality To Clarify An Association Name
13. Name Unidirectional Associations In The Same Direction
14. Word Association Names Left-To-Right
15. Indicate Role Names When Multiple Associations Between Two Classes Exist
16. Indicate Role Names on Recursive Associations
17. Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions.
The lives at association of Figure 9 is uni-directional.
18. Redraw Inherited Associations Only When Something Changes
19. Question Multiplicities Involving Minimums And Maximums

6. Inheritance Guidelines
Inheritance models “is a” and “is like” relationships, enabling you to easily reuse existing data
and code. When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the
superclass of “A.” Furthermore, we say that we have “pure inheritance” when “A” inherits all of
the attributes and methods of “B.” The UML modeling notation for inheritance is a line with a
closed arrowhead pointing from the subclass to the superclass.

1. Apply the Sentence Rule For Inheritance

2. Place Subclasses Below Superclasses
3. Beware of Data-Based Inheritance
4. A Subclass Should Inherit Everything

7. Aggregation and Composition Guidelines

Sometimes an object is made up of other objects. For example, an airplane is made up of a

fuselage, wings, engines, landing gear, flaps, and so on. A delivery shipment contains one or
more packages. A team consists of two or more employees. These are all examples of the
concept of aggregation, which represents “is part of” relationships. An engine is part of a plane,
a package is part of a shipment, and an employee is part of a team. Aggregation is a
specialization of association, specifying a whole-part relationship between two objects.
Composition is a stronger form of aggregation where the whole and parts have coincident
lifetimes, and it is very common for the whole to manage the lifecycle of its parts. From a
stylistic point of view, because aggregation and composition are both specializations of
association the guidelines for associations apply.

Figure 10. Examples of aggregation and composition.

1. Apply the Sentence Rule for Aggregation

2. You Should Be Interested In Both The Whole And The Part
3. Depict the Whole to the Left of the Part
 4. Apply Composition to Aggregates of Physical Items
5. Apply Composition When the Parts Share The Persistence Lifecycle With the Whole
6. Don’t Worry About Getting the Diamonds Right

Various levels of Data Flow Diagrams

1) Zero-level DFD or Context-level Data Flow Diagram

This level basically represents the input and output of the entire system.

2) 1-level DFD
The basic/care modules of the system are represented in this phase and how data mane gates
through different modules is shown.

3) 2-Level DFD
The module details are represented in this level. Therefore, detailed Data Flow Diagrams can be
drawn with regard to the complexity of system.

Notations in DFD’s

Data Flow Diagrams show the passage of data through the system by using fine basic constructs

1) Data Flow
It shows flow of data from a source to a destination. It is shown with an arrowed line with the
arrowhead showing the direction of flow.

It can move from an external entity to a process, from a process to another process, into and out
of a store from a process, and from a process to an external entity as well.

It should be noted that the ‘Data flow’ cannot occur from external entity to a store or from a store
directly to an external entity.

2) Processes:

These are transformations which change incoming data flow into outgoing data flow.
They are drawn in circular boxes:

The name of the process should describe what may happen to the data as it passes through the
process.

3) Data/Stores

It is repository of data, that is, a file or database

It is represented by two parallel lines and between those lines name of data store is mentioned

4) External entities:

They are external data processing units which represent some external process, outside of the
regular data flow .They rely outside the system boundaries.

5) Resource store:

It represents process with resource flow. It represents flow of material than data.
Example of Data Flow Diagrams

Data Flow Diagram (Level-0 and Level-1) for an ATM system can be represented as

Advantages of Data Flow Diagrams

• It is a simplified but powerful graphic technique

• It enables representing data with different levels of details.
• It helps defining boundaries of the system