вход по аккаунту

код для вставкиСкачать
Unified Markup
Ziya Karakaya
Atılım University,
Computer Engineering
[email protected]
Unified Markup Language is the successor to
the wave of Object-oriented Analysis and
Design methods that appear in the late `80s
and early `90s.
Most directly unifies the methods of Booch,
Rumbaugh (OMT), and Jacabson, but its
reach is wider than that.
UML went through a standardization process
with the OMG (Object Management Grouop)
and is now an OMG standard.
UML is a modeling language, not a method
Most methods consist, at least in principle, of both
a modeling language and a process.
Modelling Language is the (mainly graphical)
notation that methods use to express designs.
Process is their advice on what steps to take in
doing a design.
Modeling Language is the most important part of
the method, which is the key part of
Helps Analysis and Design
 Used for communication
 Use the advantages of OO
 Documentation
As stated in The Unified Modeling Language User
UML is a language for;
• Visualizing
• Specifying
• Constructing
• Documenting
It makes it easier to understand and work
through problem
Since it is a formal language, it enables other
developers familiar with the language to more
easily interpret our drawings.
We must communicate our software system
using some common, precise, and
unambiguous communication mechanism.
Again the formal nature of the UML facilitates
this specification quite nicely.
We know that the UML is a formal language with its
own set of syntactical rules.
Because of this formality, we can create tools that
interpret our models.
They can map the elements to a programming
language, such as Java, C++.
Many tools such as Rational Rose, supports this
forward engineering. In fact this is one of the
advantages of using a formal modeling tool.
The models we create are just one of the
articats produced throughout the
development lifecycle.
Using the UML in a consistent fashion
produces a set of documentation that can
serve as a blueprint of our system.
Models and Views
Core Diagrams
Fundamental Elements
Models and Views
UML is more than disjointed diagrams
Turn attention to an illustration of the UML
from three different perspectives
Further insight into these divisions enables us
to realize one of the greatest benefits of
modeling, which is creating different views of
our software system.
Class Diagrams
Sequence Diagrams
Class Diagrams
Individual Diagrams
Fundamental Elements
Fundamental Elements
These are the elements of which diagrams
are composed
Understanding the intent of each element
enables us to create precise diagrams,
because each of them has unambiguous
Individual diagrams contribute more to the
specification of a software system.
They are composition of many of the fundamental
Are mechanism that developers use to communicate
and solve problems in the complex aspects of the
The most common diagram is the Class Diagram,
which describe the structural relationships that exist
among the classes, can guide developers in
understanding our software system’s class structure.
As we become more proficient in modeling, we
begin to realize that using a combination of
diagrams to communicate is most effective.
We may need to combine class diagram with a
diagram whose intent is to give systems dynamics.
By combining these called views.
View is a depiction of our system from a particular
By making different views, we can represent our
system from different perspectives.
There are five main views,
Use case
They must be consistent with each other,
because all of them are representing the same
Can be used to validate each other.
This view documents the system from the
customer’s perspective.
Terminology used in this view should be domain
Depending on the technical nature of our audience,
we should avoid obscure technical terms.
Diagrams most common in this view are the use
case diagrams and, less common, activity diagrams.
Organizations transitioning to the UML may wish to
work only with use case diagrams early and
experiment with activity diagrams over time.
Design VIEW
This view documents the system from
designer’s and architect’s perspective.
Diagrams most common in this view are
class and interaction diagrams (either
sequence or collaboration), as well as
package diagrams illustrating the package
structure of our Java application.
Development VIEW
This view documents the components that
the system is composed of.
This view typically contains component
Except for the most complex Java
applications, this view is optional.
This view documents the processes and
threads that compose our application.
These processes and threads typically are
captured on class diagrams using an active
Because of the advanced nature of active
classes, coupled with the volume of use,
active classes are beyond the scope of this
Physical VIEW
This view documents the system topology.
Deployment diagrams that compose this view
illustrate the physical nodes and devices that
make up the application, as well as the
connections that exist between them.
VIEWS (cont.)
We are not limited with the listed views.
If there is something that architecturally
important, for example security, then we may
create a new view (ex: security view) into the
system from that perspective.
As we’ve seen, we can combine
diagrams that form models and that
can serve as views into our system.
If an advantage in modeling is to
combine diagrams to form views
into our system, then it only makes
sense that each diagram has a
different focus on what it
Each falls into one of two
categories: behavioral, and
Most commonly used are use case,
sequence, and class diagrams.
Behavioral diagrams
Behavioral diagrams depict the dynamic aspects of our
system.They are most useful for specifying the collaborations
among elements that satisfy the behavior of our system’s
Five diagrams that fall into this category are;
 Use case
 Activity
 State
 Sequence
 Collaboration
Mostly used are use case, sequence, and collaboration.
Activity and state diagrams are used on an as-needed basis.
Activity diagrams visually represent behaviors captured by use
State diagrams, on the other hand, are used to illustrate complex
transitions in behavior for a single class.
Use case diagrams
Use case diagrams are centered around the
business processes that our application must
Most simply, use case diagrams enable us to
structure our entire application around the core
processes that it must support.
Doing so enables us to use these use cases to drive
the remainder of the modeling and development
Shows a set of actors and use cases, and the
relationships between them.
Use case diagrams contribute to effective model
organization, as well as modeling the core behaviors
of a system.
Activity Diagrams
Models the flow of activity between
These diagrams are most useful in detailing
use case behavior.
An activity diagram doesn’t show
collaboration among objects.
State Diagrams
Illustrates internal state-related behavior of
an object.
Transitions between states help identify, and
validate, complex behavior.
A class can have at most a single state
Sequence Diagrams
Semantically equivalent to a collaboration
sequence diagram is a type of interaction
diagram that describes time ordering of
messages sent between objects.
Almost in all software development activity,
this diagram is used.
Collaboration Diagrams
A type of interaction diagram that describes
the organizational layout of the objects that
send and receive messages.
Semantically equivalent to a sequence
It uses class diagrams layout, and can be
used to make more cohesive and less
coupled classes.
Diagrams in this category are focused on specifying the static
aspects of our system.
Of these four diagrams, the class diagram is most often used.
when transitioning to the UML, most organizations tend to use
class diagrams first because they are excellent mechanisms for
communication among developers, as well as tools that can be
used for problem solving.
There are two forms of class diagrams.
The first is the most commonly understood and consists of the
classes that compose our system and of the structure among
these classes.
Unfortunately, the second is not often used but is of equal
importance and can be most effective in helping developers
understand our system from a high level.
A type of class diagram, called a package diagram, often
represents the Java packages and the dependencies between
them that our application consists of.
Class Diagrams
Illustrates a set of classes, packages, and
relationships detailing a particular aspect of a
This diagram is likely the most common one
used in modeling.
Object Diagrams
Provides a snapshot of the system illustrating the
static relationships that exist between objects.
Object diagrams depict the structural relationship
that exists among the objects within our running
application at a given point in time.
When we think of the runtime version of our system,
we typically think of behavior.
Many people have found that object diagrams are
most useful in fleshing out the instance relationships
among objects, which in turn can help verify our
class diagrams.
Beyond this, object diagrams are not often used.
Component Diagrams
Addresses the static relationships existing
between the deployable software
Examples of components may be .exe, .dll,
.ocx, jar files, and/or Enterprise JavaBeans.
Component diagrams might be used to show
the software components within our
Components aren’t equivalent to classes.
Deployment Diagrams
Describes the physical topology of a system.
Typically includes various processing nodes,
realized in the form of a device (for example, a
printer or modem) or a processor (for example, a
Deployment diagrams are most useful when we
have a complex configuration environment.
If our application is to be deployed to multiple
servers, across locations, a deployment diagram
might be useful.
Пожаловаться на содержимое документа