Here are 2 excellent and well written UML Tutorials, one
hosted by Sparxsystems.com.au (UML Tutorial), and the other by
Borland.com (Practical UML: A Hands-On Introduction for Developers).
These will give anyone unfamiliar with the UML a thorough understanding
and kick start to using this modeling language.
The
Unified Modeling Language (UML) has quickly become the de-facto
standard for building Object-Oriented software. This tutorial provides
a technical overview of the 13 UML. diagrams supported by Enterprise
Architect.UML 2 semantics are explained in detail in the new UML
2.0 tutorial.
But first... What is UML?
The OMG specification states:
"The
Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a
software-intensive system.
The UML offers a standard way to
write a system's blueprints, including conceptual
things such
as business processes and system functions as well as concrete things
such
as programming language statements, database schemas,
and reusable software
components."
The
important point to note here is that UML is a 'language' for specifying
and not a method or procedure. The UML is used to define a software
system; to detail the artifacts in the system, to document and
construct - it is the language that the blueprint is written in. The
UML may be used in a variety of ways to support a software
development methodology (such as the Rational Unified
Process) - but in itself it does not specify that methodology or
process.
UML defines the notation and semantics for
the following domains:
| -
| The User Interaction or Use
Case Model - describes the boundary and interaction between
the system and users. Corresponds in some respects to a requirements
model. |
| - | The Interaction or
Communication Model - describes how objects in the system will interact
with each other to get work done. |
| - | The
State or Dynamic
Model
- State charts describe the states or conditions that classes assume
over time. Activity graphs describe the workflow's the system will
implement. |
| - | The Logical
or Class Model - describes the classes and objects that will
make up the system. |
| - | The
Physical Component
Model - describes the software (and sometimes hardware
components) that make up the system. |
| - | The
Physical
Deployment Model - describes the physical architecture and
the deployment of components on that hardware architecture. |
The UML also defines extension
mechanisms for extending the UML to meet specialized needs (for example
Business
Process Modeling extensions).
See also Business Process Modeling (pdf) .
If you have any suggestions or comments on the material here,
please forward your thoughts to sparks@sparxsystems.com.au.
UML
Tutorial - Continued - Use the UML to Define and Build Systems
We have established in Part 1 that the UML is a language for specifying
the artifacts and interactions of a software system. We have also seen
that it deals with 6 major domains - from Use Case models, through
dynamic and logical models to the final physical deployment model - and
that extension mechanisms have been included to allow for specialised
additions to the model notation.
So... How do you
use the UML?
The UML is typically used as a part of
a software
development process, with the support of a suitable CASE
tool,
to define the requirements, the interactions and the elements of the
proposed software system. The exact nature of the process depends on
the development methodology used. An example process might look
something like the following:
| 1.
| Capture a Business Process Model.
This will be used to define the high level business activities and
processes that occur in an organization and to provide a foundation for
the Use Case model. The Business
Process Model will typically capture more than a software
system will implement (ie. it includes manual and other processes). |
| 2. |
Map a Use Case Model to the Business
Process Model
to define exactly what functionality you are intending to provide from
the business user perspective. As each Use Case is added, create a
traceable link from the appropriate business processes to the Use Case
(ie. a realisation connection). This mapping clearly states what
functionality the new system will provide to meet the business
requirements outlined in the process model. It also ensures no Use
Cases exist without a purpose. |
| 3. | Refine
the Use Cases - include requirements, constraints, complexity rating,
notes and scenarios. This information unambiguously describes what the
Use Case does, how it is executed and the constraints on its execution.
Make sure the Use Case still meets the business process requirements.
Include the definition of system tests for each use case to define the
aceptance criteria for each use case. Also include some user acceptance
test scripts to define how the user will test this functionality and
what the acceptance criteria are. |
| 4. | From
the inputs and outputs of the Business
Process Model
and the details of the use cases, begin to construct a domain model
(high level business objects), sequence diagrams, collaboration
diagrams and user interface models. These describe the 'things' in the
new system, the way those things interact and the interface a user will
use to execute use case scenarios. |
| 5. | From
the domain model, the user interface model and the scenario diagrams
create the Class Model.
This is a precise specification of the objects in the system, their
data or attributes and their behaviour or operations. Domain objects
may be abstracted into class hierarchies using inheritance. Scenario
diagram messages will typically map to class operations. If an existing
framework or design pattern is to be used, it may be possible to import
existing model elements for use in the new system. For each class
define unit tests and integration tests to thoroughly test i) that the
class functions as specified internally and that ii) the class
interacts with other related classes and components as expected. |
| 6. |
As
the Class Model develops it may be broken into discrete packages and
components. A component represents a deployable chunk of software that
collects the behaviour and data of one or more classes and exposes a
strict interface to other consumers of its services. So from the Class
Model a Component Model
is built to define the logical packaging of classes. For each component
define integration tests to confirm that the component's interface
meets the specifcation given it in relation to other software elements.
|
| 7. | Concurrent
with the work you have already done, additional requirements should
have been captured and documented. For example - Non Functional
requirements, Performance requirements, Security requirements,
responsibilities, release plans & etc. Collect these within the
model and keep up to date as the model matures. |
| 8. |
The Deployment model
defines the physical architecture of the system. This work can be begun
early to capture the physical deployment characteristics - what
hardware, operating systems, network capabilities, interfaces and
support software will make up the new system, where it will be deployed
and what parameters apply to disaster recovery, reliability, back-ups
and support. As the model develops the physical architecture will be
updated to reflect the actual system being proposed. |
| 9. |
Build
the system: Take discrete pieces of the model and assign to one or more
developers. In a Use Case driven build this will mean assigning a Use
Case to the development team, having them build the screens, business
objects, database tables, and related components necessary to execute
that Use Case. As each Use Case is built it should be accompanied by
completed unit, integration and system tests. A Component driven build
may see discrete software components assigned to development teams for
construction. |
| 10. | Track
defects that emerge in the testing phases against the related model
elements - eg. System test defects against Use Cases, Unit Test defects
against classes & etc. Track any changes against the related
model
elements to manage 'scope creep'. |
| 11. | Update
and refine the model as work proceeds - always assessing the impact of
changes and model refinements on later work. Use an iterative approach
to work through the design in discrete chunks, always assessing the
current build, the forward requirements and any discoveries that come
to light during development. |
| 12. | Deliver
the complete and tested software into a test then production
environment. If a phased delivery is being undertaken, then this
migration of built sofware from test to production may occur several
times over the life of the project. |
Note that the above process is necessarily brief in
description, leaves
much unsaid and may not be how you work or follow the process you have
adopted. It is given as an example of how the UML may be used to
support a software development project.
by Randy
MillerAbstract: This
tutorial provides a quick introduction to the Unified Modeling
Language™
The heart of
object-oriented problem
solving is the construction of a model. The model abstracts the
essential details of the underlying problem from its usually
complicated real world. Several modeling tools are wrapped under the
heading of the UML™,
which stands for Unified Modeling Language™. The purpose of
this
course is to present important highlights of the UML.
At
the center of the UML are its nine kinds of modeling diagrams, which we
describe here.
Some
of the sections of this course contain links to pages with more
detailed information. And every section has short questions. Use them
to test your understanding of the section topic.
Why
is UML important?
Let's
look at this question from the point of view of the construction trade.
Architects design buildings. Builders use the designs to create
buildings. The more complicated the building, the more critical the
communication between architect and builder. Blueprints are the
standard graphical language that both architects and builders must
learn as part of their trade.
Writing
software is not unlike constructing a building. The more complicated
the underlying system, the more critical the communication among
everyone involved in creating and deploying the software. In the past
decade, the UML has emerged as the software blueprint language for
analysts, designers, and programmers alike. It is now part of the
software trade. The UML gives everyone from business analyst to
designer to programmer a common vocabulary to talk about software
design.
The UML is applicable to
object-oriented problem solving. Anyone interested in learning UML must
be familiar with the underlying tenet of object-oriented problem
solving -- it all begins with the construction of a model. A model is an
abstraction of the underlying problem. The domain
is the actual world from which the problem comes.
Models
consist of objects
that interact by sending each other messages.
Think of an object as "alive." Objects have things they know (attributes)
and things they can do (behaviors
or operations).
The values of an object's attributes determine its state.
Classes
are the "blueprints" for objects. A class wraps attributes (data) and
behaviors (methods or functions) into a single distinct entity. Objects
are instances
of classes.
Technorati Tags: uml, uml tutorial
Popularity: 20% [?]
Share and Enjoy:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Related Posts:Lots of Tutorials and 2 .Net Learning Sites3 Free Software Development Training and Coaching SitesAn Excellent Free Computer Book and Training Link SiteFree Training and Books on Java, EJB, .Net, and C# (C Sharp)2 Excellent Database Learning Sites: 1 Oracle and 1 SQL Server
