Anda di halaman 1dari 20

UML

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

The Evolution of Methods


Object-oriented methods became prominent in the early 1980s

From 5 to 50 in under 5 years

Booch, OMT and OOSE were the leading methods


Differences were often superficial

Different graphical syntax and terminology

Experience with methods on real projects suggested what to keep and what to throw
away

E v o l u t i o n o f t e c h n o l o g y:Submission of UML 1.0 to OMG


for adoption, Jan 97

public
feedback

June 96 & Oct 96

UML 1.0

UML 0.9 & 0.91


UML Partners

OOPSLA 95

Booch 93
Other methods

Expertise

Unified Method 0.8

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

construction or renovation is as essential as having a blueprint for large building. Good


models are essential for communication among project teams and to assure architectural
soundness. We build models of complex systems because we cannot comprehend any
such system in its entirety. As the complexity of systems increase, so does the importance
of good modeling techniques. There are many additional factors of a projects success, but
having a rigorous modeling language standard is one essential factor. A modeling language
must include:
Model elements fundamental modeling concepts and semantics
Notation visual rendering of model elements
Guidelines idioms of usage within the trade
In the face of increasingly complex systems, visualization and modeling become
essential. The UML is a well-defined and widely accepted response to that need. It is the
visual modeling language of choice for building object-oriented and component-based
systems.

INDUSTRY TRENDS IN SOFTWARE


As the strategic value of software increases for many companies, the industry looks

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-

PRIOR TO INDUSTRY CONVERGENCE


Prior to the UML, there was no clearly leading modeling language. Users had to

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.

U s e o f m o d e l i n g :Modeling is the designing of software applications before coding. Modeling is


an Essential Part of large software projects, and helpful to medium and even small projects
as well. A model plays the analogous role in software development that blueprints and other
plans (site maps, elevations, physical models) play in the building of a skyscraper. Using a
model, those responsible for a software development project's success can assure
themselves that business functionality is complete and correct, end-user needs are met,
and program design supports requirements for scalability, robustness, security, extendibility,

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.

Use case diagrams

Class diagrams

Object diagrams

Sequence diagrams

Collaboration diagrams

State chart 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

Inheritance is represented by a triangle and Savings Account is a subclass of


Account, inheriting all of the Attributes and Operations of the Account Class. Aggregation is
represented by a diamond.
Object diagrams :An object diagram is a graph of instances, including objects and data values, a
static object diagram is an instance of a class diagram; it shows a snapshot of the detailed
state of a system at a point in time. The use of object diagrams is fairly limited, mainly to
show examples of data structures.
The object model provides the semantic foundation for UMLs design models. The
meaning of any design construct or notation in UML can be explained by rephrasing it in
terms of assertions about a set of connected and intercommunicating objects. Static
models describe the kinds of connections that can exist between objects and the possible
topologies the resulting object network can have. Dynamic models describe the messages
that can be passed between objects and the effect that receiving a message has on an
object.
Object : class name

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

Welcome Next Visitor

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 -

A component diagram shows the various components and their dependencies


among software components, including source code components, binary code
components, and executable components. A software module may be represented as a
component type. Some components exist at compile time, some exist at link time, and
some exist at run time; some exist at more than one time. A compile-only component is one
that is only meaningful at compile time; the run-time component in this case would be an
executable program.
Components represent all kinds of elements that pertain to the grouping together of
software applications. Among other things, they may be simple files, or libraries loaded
dynamically. By default, each class in the logical model has a specification and a body. The
specification contains the class interface, while the body contains the implementation of
that same class, represented by the component symbol.
In C++, a specification corresponds to a file with .h suffix(extension), and a body
corresponds to a file with the suffix(extension) .cpp
The below one is representation for the component diagram
Web Server

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.

Provide extensibility and specialization mechanisms to extend the core concepts.

Support higher-level development concepts such as collaborations, frameworks,


patterns and components.

Integrate best practices.

The UML is expressive

The UML is applicable to a wide variety of problem domains and development


processes

The UML is stable

Work together efficiently and communicate effectively

Enables us to create simplified representations of our systems

DIs a d v a n t a g e s :

The lack of precise semantics

UML doesnt dictate a particular process

UML can be used to record the resulting domain and designing models, independent of
the process

Does the tool generate code as the semantics would predict?

Problems with machine processing of language

Model simulation or execution

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.

References: Practical Object Oriented Design with UML


Mark Priestley
Object Oriented Modeling and Design
James Rambaugh

www.rational.com
www.together.com
www.holub.com
www.ambysoft.com

UML

www.jeckle.com

- 20 -

Anda mungkin juga menyukai