-1-
I n t r o d u c t I o n :Despite the fact that several advanced languages have come out of the Information
Age Revolution, such as Java, C++, XML, etc., many people are still designing their code
with minimal design in mind. They fall back on the IDE to do the work for them and this as
far as the design goes. This may seem acceptable in the short term, but if its a long term,
large project involving many individuals on the project, this is a recipe for disaster.
Although, graphic design has been excepted in many of the other engineering fields:
Mechanical, Electrical, Architectural, for some reason software design has been very slow
to adopting these methods. The main reason, I believe, is that most people feel its a lot of
extra work. Some other reasons are that people feel the tools arent quite there yet, lack of
understanding of the methodologies, too many competing methods, too much design
concepts to learn. UML is an attempt to solve some of the common issues. Its been
marketed well by Rational and it is becoming widely accepted in corporations. It seems to
bring together some of the best concepts in the Object - Oriented community and provide a
common way for people to communicate design. It is also adopted by the Object
Management Group and is quickly becoming a standard. UML is not specific to any one
implementation and brings together models that have been used for years by programmers
to describe their software.
History:
The development of UML began in late 1994 when Grady Booch and Jim
Rumbaugh of Rational Software Corporation began their work on unifying the Booch and
OMT (Object Modeling Technique) methods. In the fall of 1995, Jacobson and his
Objectory company joined Rational and this unification effort, merging in the OOSE
(Object-Oriented Software Engineering) method.
As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim
Rumbaugh, and Jacobson were motivated to create a unified modeling language for three
reasons. First, these methods were already evolving toward each other independently. It
made sense to continue that evolution together rather than apart, eliminating the potential
for any unnecessary and gratuitous differences that would further confuse users. Second,
by unifying the semantics and notation, they could bring some stability to the objectoriented marketplace, allowing projects to settle on one mature modeling language and
letting tool builders focus on delivering more useful features. Third, they expected that their
collaboration would yield improvements in all three earlier methods, helping them to
UML
-2-
capture lessons learned and to address problems that none of their methods previously
handled well.
The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML
0.9 and 0.91 documents in June and October of 1996. During 1996, the UML authors
invited and received feedback from the general community.
During 1996, it became clear that several organizations saw UML as strategic to
their business. A Request for Proposal (RFP) issued by the Object Management Group
(OMG) provided the catalyst for these organizations to join forces around producing a joint
RFP response. Rational established the UML Partners consortium with several
organizations willing to dedicate resources to work toward a strong UML 1.0 definition.
Experience with methods on real projects suggested what to keep and what to throw
away
public
feedback
UML 1.0
OOPSLA 95
Booch 93
Other methods
Expertise
Booch 91
OMT - 2
OMT -1
OOSE
UML
-3-
LeadIng factors:
This section describes several factors motivating the UML. We discuss why
modeling is essential, highlight a few key trends in the software industry, and describe the
issues caused by divergence of modeling approaches.
WHY WE MODEL
Developing a model for an industrial-strength software system prior to its
for techniques to automate the production of software. We look for techniques to improve
quality and reduce cost and time-to-market. These techniques include component
technology, visual programming, patterns, and frameworks. We also seek techniques to
manage the complexity of systems as they increase in scope and scale. In particular, we
recognize the need to solve recurring architectural problems, such as physical distribution,
concurrency, replication, security, load balancing, and fault tolerance. Complexity will vary
by application domain and process phase. One of the key motivations in the minds of the
UML developers was to create a set of semantics and notation that adequately addresses
all scales of architectural complexity, across all domains.
UML
-4-
choose from among many similar modeling languages with minor difference in overall
expressive power. Most of the modeling languages shared a set of commonly accepted
concepts that are expressed slightly differently in different languages. This lack of
agreement discouraged new users from entering the OO market and from doing OO
modeling, without greatly expanding the power of modeling. Users longed for the industry
to adopt one, or a very few, broadly supported modeling languages suitable for generalpurpose usage. They wanted a lingua franca for modeling. Some vendors were
discouraged from entering the OO modeling area because of the need to support many
similar, but slightly different, modeling languages. In particular, the supply of add on
tools has been depressed because small vendors cannot afford to support many different
formats from many different front-end modeling tools. It is important to the entire OO
industry to encourage broadly based tools and vendors, as well as niche products that
cater to the needs of specialized groups. The perpetual cost of using and supporting many
modeling languages motivated many companies producing or using OO technology to
endorse and support the development of the UML. While the UML does not guarantee
project success, it does improve many things. For example, it significantly lowers the
perpetual cost of training and retooling when changing between projects or organizations. It
provides the opportunity for new integration between tools, processes, and domains. But
most importantly, it enables developers to focus on delivering business value and provides
them a paradigm to accomplish this.
UML
-5-
and other characteristics, before implementation in code renders changes difficult and
expensive to make. Surveys show that large software projects have a huge probability of
failure - in fact, it's more likely that a large software application will fail to meet all of its
requirements on time and on budget than that it will succeed. If you're running one of these
projects, you need to do all you can to increase the odds for success, and modeling is the
only way to visualize your design and check it against requirements before your crew starts
to code.
U M L diagrams :
At the center of the UML are its 9 kinds of modeling diagrams,which we describe here.
Class diagrams
Object diagrams
Sequence diagrams
Collaboration diagrams
Activity diagrams
Component diagrams
Deployment diagrams
Use case diagrams :The Use Case Model describes the proposed functionality of the new system. A Use
Case represents a discrete unit of interaction between a user (human or machine) and the
system. A Use Case is a single unit of meaningful work; for example login to system,
register with system and create order are all Use Cases. Each Use Case has a description
which describes the functionality that will be built in the proposed system. A Use Case may
'include' another Use Case's functionality or 'extend' another Use Case with its own
behavior.
Use case diagrams describe what a system does from the standpoint of an external
observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of
what happens when someone interacts with the system.
Below is a use case for depositing a check
UML
-6-
Account Controller
ATM Hardware
Print receipt
The Ovals represent the different actions of each of the actors. The Customer
Deposits a check, the ATM prints the receipt. Note that Use Case dont represent any
sequence or time events, they just tell you the list of cases and how each user acts upon
that case. Use cases can be more descriptive by using extend and uses relationships.
Below is an example of how the Print Receipt Case is extended. An extended case
is a subtype of the existing case. Here we extended case Print Receipt in two ways:
(1) Print a Receipt on the screen,
(2) print the receipt on a piece of paper. Both cases are still printing a receipt so they are
of the same type.
Use Cases are typically related to 'actors'. An actor is a human or machine entity
that interacts with the system to perform meaningful work
UML
-7-
Actors :An Actor is a user of the system. This includes both human users and other
computer systems. An Actor uses a Use Case to perform some piece of work which is of
value to the business. The set of Use Cases an actor has access to defines their overall
role in the system and the scope of their action.
The Class Diagrams :The Unified Modeling language has several models that help you describe the
software system you are trying to represent. Each model represents a different aspect of
the software description. The Class Model is the static architectural representation of your
software and often a good starting point. It allows you to see the overall object structure of
the software system. Below is a class represented in UML:
The Account is the name of the class representing the definition of an Account. The
Value is an attribute of the Account representing the amount of money in the account.
Withdraw and Deposit are methods to Add/Delete money to the account. The and + signs
are visibility indicators used to show encapsulation. The minus says that Value is a private
member of class Account and can only be seen by methods of the Account class. The plus
represents public members, so Withdraw and Deposit can be accessed outside the
Account class. The void after the colon are the return types from the class.
UML Can also represent the relationships between classes:
UML
-8-
Account
-Value : float
+withdraw (float) : void
+deposit(float) : void
Savings Account
+calicluate interest(float): void
Attributes
operations
UML
-9-
Sequence diagram:The sequence diagram describes the flow of messages being passed from object to
object. Unlike the class diagram, the sequence diagram represents dynamic message
passing between instances of classes rather than just a static structure of classes. In some
ways, a sequence diagram is like a stack trace of object messages. Below is a sample
sequence diagram
The Sequence diagram allows the person reading the documentation to follow the
flow of messages from each object. The vertical lines with the boxes on top represent
instances of the classes (or objects). The label to the left of the colon is the instance and
the label to the right of the colon is the class. The horizontal arrows are the messages
passed between the instances and are read from top to bottom. Here we have a customer
(user) depositing money into MyAccount which is an instance of Class Savings Account.
Then MyAccount object Validates the account by asking the Bank object, MyBank to
ValidateAccount. Finally, the Customer Asks the ATM object for a Receipt by calling the
ATMs operation GetReceipt. The white rectangle indicate the scope of a method or set of
methods occurring on the Object My Bank. The dotted line is a return from the method
ValidateAccount.
Collaboration diagrams :-A collaboration diagram shows an interaction organized around the objects in the
interaction and their links to each other. Unlike a sequence diagram, a collaboration
diagram shows the relationships among the objects. On the other hand, a collaboration
UML
- 10 -
diagram does not show time as a separate dimension, so the sequence of messages and
the concurrent threads must be determined using sequence numbers.
Behavior is implemented by sets of objects that exchange messages within an
overall interaction to accomplish a purpose. To understand the mechanisms used in a
design, it is important to see only the objects and the messages involved in accomplishing
a purpose or a related set of purposes, projected from the larger system of which they are
part. Such a construct is called a collaboration.
Collaboration diagrams and sequence diagrams are semantically equivalent, which
means you can convert one type of diagram to the other without losing any information.
However, a collaboration diagram has two key features that a sequence diagram does not:
optional stereotypes, such as local and self, for the paths between objects, and
sequence numbers.
The below one is an example for the collaboration diagram
UML
- 11 -
State diagrams:State Diagrams are another model in UML that allow you to actually describe the
timing taking place in your system. State Diagrams have been around a long time in logical
design and have proved very useful for concurrent and real-time systems. A state diagram
consists mostly of states and transitions. It often represents the different states a class can
undergo and the events that effect a change in state in the class
In our ATM machine example the key entry of a users password can be represented
as a set of states
The initial state is represented by a small black circle, wait states are represented
by rounded rectangles, and the final state is represented by a small black circle surrounded
by a white circle. Transitions are the arrows going from one state to another. A transition is
triggered by an event. An event can be a key press, mouse movement or a menu selection
for example. The event is an activity either from the user or the system that causes a
change of state. In the example above, # pressed and Cancel pressed are examples of
UML
- 12 -
events from the user. Usually an event causes some sort of action to occur when the
system is changing state. The action is represented by the slash followed by the action,
e.g. /Display. Display is most likely an operation in a class to tell the screen to display the
key being pressed. Another characteristic of transitions is known as a condition. Conditions
can be coupled with an event to determine if a change of state occurs. In our example, in
order to go from the Start state to the NextNumber state a key must be pressed (the
event) and the first digit must be greater than 0 (the condition). Conditions are represented
in UML surrounded with square brackets [ ].
Activity diagrams:Another model coming out of UML which I often think of as the brother to the state
diagram, is the Activity Diagram. The Activity Diagram in some ways is like a flowchart with
states. With the activity diagram you can follow flow of activities in your system in the order
that they take place. Below is an activity diagram for making a deposit.
UML
- 13 -
Deposit check
Validate check
Print receipt
Record visit
Reject deposit
Note the activity diagram looks like a cross between a state diagram, a use case
diagram and a flowchart. Activities look similar to states but they are a bit more rounded.
They are stateless in that they take place and automatically transition to the next state upon
finishing. The diamond is a conditional branch that determines which activity to transition
too based on a condition and it is also stateless. In our example, if the deposited check is
valid, a receipt is printed.
Otherwise, if its not a valid check then the activity is to reject the deposit. The solid
black bar is a synch state. This state simply synchs up existing activities so that they
transition to the next activity at the same time.
Component diagrams:-
UML
- 14 -
Get request
Post response
Deployment diagrams :
Deployment diagrams show the configuration of run-time processing elements and
the software components, processes, and objects that live on them. Software component
instances represent run-time manifestations of code units. Components that do not exist as
run-time entities (because they have been compiled away) do not appear on these
diagrams; they should be shown on component diagrams.
A deployment diagram
Shows the physical relationship among software and hardware components in the
delivered system.
UML
- 15 -
Is a good place to show how components and objects are routed and move around a
distributed system
Shows the configuration of run-time processing elements and the software components,
processes , and objectives that live on them.
Components that do not exist at runtime entities (because they have been compiled
away ) do not appear on these diagrams, they should be shown on component diagrams.
The below one is an example for the TCP/IP deployment diagram in a company
UML
- 16 -
UML
- 17 -
Advantages:
Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
DIs a d v a n t a g e s :
UML can be used to record the resulting domain and designing models, independent of
the process
Does the tool check the consistency of a model in accordance with the
semantics?
UML
- 18 -
Future Enhancements :
Although the UML defines a precise language, it is not a barrier to future
improvements in modeling concepts. Many leading-edge techniques have been addressed
by OMG but they expect additional techniques to influence future versions of the UML.
Many advanced techniques can be defined using UML as a base. The UML can be
extended without redefining the UML core.
The UML, in its current form, is expected to be the basis for many tools, including
those for visual modeling, simulation and development environments. As interesting tool
integrations are developed, implementation standards based on the UML will become more
available. The UML has integrated many disparate ideas, and this integration will
accelerate the use of object-orientation and component-based development.
However there is a danger that users are overwhelmed by UML's expressive power and
care must be taken to keep it clearly structured with easily understandable semantics.
Standardization of the UML and planned improvements
Many organizations which were using Booch, OMT or OOSE have already
endorsed the UML as their standard, since it is based on the modeling languages of leading
object methods. The UML is ready for widespread use. The number of articles, training
courses, examples and books is continually increasing and will ensure that UML is
accessible to a wide audience. The Unified Modeling Language v. 1.1 specification was
added to the list of OMG Adopted Technologies in November 1997. Since then the OMG
has assumed responsibility for the further development of the UML standard.
After the UML 1.1 proposal was adopted by the OMG membership in November 1997, the
OMG assigned a revision task force (RTF) to accept comments from the general public and
to make revisions.
OMG is aiming for international standardization sometime this year. The advantages
would be a wider recognition and acceptance which would enlarge the market for products
based on UML. However normally the standardization process is formal and lengthy
because it has to fulfill many technical and legal requirements. This conflicts with the
business concept of using the latest technology as early as possible. On the technical side
in order to achieve a standard, everyone must agree, and such committees can take time
to reach decisions.
UML
- 19 -
Conclusion :
In this overview, the UML was discussed in terms of Class Diagrams, Interaction
Diagrams, Use Case Diagrams, and Activity Diagrams. Other types of UML notation that
were discussed include State Diagrams (explore the state transitions of a single object),
Deployment Diagrams (show how software is mapped onto hardware devices), and
Component Diagrams (show the structure of software in terms of software components and
their relationship to executable components).
Modeling has taken a strong foothold in software development and is undoubtedly
here to stay. The UML was created to provide the software development community with a
standard, unified modeling language. The UML has a rich history and was created by some
of the most well - respected methodologists in the software industry.
While modeling is not the silver bullet for software development, it has numerous
benefits, which include enhanced communication, validation of our design theories, and
helping to simplify an inherently difficult process. By taking advantage of these benefits, we
can produce systems that will survive as the demands of our users and business change.
In some regards, all projects utilize a certain degree of modeling. The choice to use a
formal language such as the UML should be given serious consideration. The result can be
a much more resilient design, which can reduce the cost associated with the maintenance
effort.
www.rational.com
www.together.com
www.holub.com
www.ambysoft.com
UML
www.jeckle.com
- 20 -