A tutorial and reference description
Alejandro Ramirez
Philippe Vanpeperstraete
Andreas Rueckert
Kunle Odutola
Jeremy Bennett
Linus Tolke
Michiel van der
Wulp
Copyright © 2004, 2005, 2006, 2007, 2008 Michiel van der Wulp
Copyright © 2003 Linus Tolke
Copyright © 2001, 2002 Jeremy
Bennett
Copyright © 2001 Kunle
Odutola
Copyright © 2000 Philippe
Vanpeperstraete
Copyright © 2000 Alejandro
Ramirez
Copyright © 2000 Andreas
Rueckert
Abstract
This version of the manual is intended to describe the
version PRE-0.25.5 of ArgoUML.
Software design is a cognitively challenging task. Designers
must manually enter designs, but the primary difficulty is
decision-making rather than data-entry. If designers improved their
decision-making capabilities, it would result in better
designs.
Current CASE tools provide automation and graphical user
interfaces that reduce the manual work of entering a design and
transforming a design into code. They aid designers in
decision-making mainly by providing visualization of design
diagrams and simple syntactic checks. Also many CASE tools provide
substantial benefits in the area of version control and concurrent
design mechanisms. One area of design support that has been not
been well supported is analysis of design decisions.
Current CASE tools are usable in that they provide a GUI that
allows designers to access all the features provided by the tool.
And they support the design process in that they allow the designer
to enter diagrams in the style of popular design methodologies. But
they typically do not provide process support to guide the designer
through the design task. Instead, designers typically start with a
blank page and must remember to cover every aspect of the
design.
ArgoUML is a domain-oriented design environment that provides
cognitive support of object-oriented design. ArgoUML provides
some of the same automation features of a commercial CASE tool,
but it focuses on features that support the cognitive needs of
designers. These cognitive needs are described by three cognitive
theories:
reflection-in-action;
opportunistic design; and
comprehension and problem solving.
ArgoUML is based directly on the UML 1.4 specification. The
core model repository is an implementation of the Java Metadata
Interface (JMI) which directly supports MOF and uses the
machine readable version of the UML 1.4 specification provided
by the OMG.
Furthermore, it is our goal to provide comprehensive support
for OCL (the Object Constraint Language) and XMI (the XML Model
Interchange format).
ArgoUML was originally developed by a small group of people
as a research project. ArgoUML has many features that make it
special, but it does not implement all the features that commercial
CASE tools provide.
The current version (PRE-0.25.5) of ArgoUML implements all the
diagram types of the
UML 1.4
standard (versions of ArgoUML prior to 0.20 implemented the
UML 1.3
standard). It is written in Java and runs on every computer
which provides a Java platform version 5 or newer. It uses the
open file formats
XMI (XML Metadata Interchange format) (for model
information) and
PGML (Precision Graphics Markup Language) (for graph
information) for storage. When ArgoUML implements UML 2.0, PGML
will be replaced by the UML Diagram Interchange specification.
This manual is the cumulative work of several people and has
been evolving over several years. Connected to the release 0.10 of
ArgoUML, Jeremy Bennett, wrote a lot of the new material that was
added to the earlier versions by Alejandro Ramirez, Philippe
Vanpeperstraete and Andreas Rueckert. He also added things from
some of the other documents namely the developers cookbook by
Markus Klink and Linus Tolke, the Quick Guide by Kunle Odutola, and
the FAQ by Dennis Daniels. Connected to the release 0.14 changes
were made by Linus Tolke, and by Michiel van der Wulp. These
changes were mostly to adopt the manual to the new functions and
appearance of ArgoUML version 0.14, and introduction of the index.
The users and developers that have contributed by providing
valuable input, such as review comments or observations while
reading and using this manual are too many to name.
ArgoUML is available for free and can be used in commercial
settings. For terms of use, see the license agreement presented
when you download ArgoUML. We are providing the source code for
ArgoUML for you to review, customize to your needs, and improve.
Over time, we hope that ArgoUML will evolve into a powerful and
useful tool for everyone to use.
This User Manual is aimed at the working designer, who wishes
to make use of ArgoUML. The manual is presently written assuming
familiarity with UML, but eventually it will support those new to
UML.
The manual is written in DocBook/XML and available as both
HTML and PDF.
The ArgoUML project welcomes those who want to get more
involved. Look at the
project website
to find out more.
Tell us what you think about this User Manual! Your comments
will help us improve things. See
Section 1.3.3, “User Feedback”
.
Chapter 2. Introduction (being written)
This tutorial will be taking you through a tour of the use of
ArgoUML to model a system.
First you will become familiar with the feel of the product and then
we will go through an analysis and development process for a test case.
Not every nook and cranny of the product will be demonstrated.
That degree of detail is given in the reference materials to be
found in subsequent parts of this document.
The state of the model at the end of key sections will be available in
.zargo files.
These are available so that you can play with various aspects not
specifically covered in this tutorial and then
restore yourself back to the proper state of the model in your work area.
These .zargo files will be identified at the end of the sections whose
work they represent.
An ATM (automated teller machine) project has been chosen as a case study
to demonstrate the various aspects of modeling that ArgoUML offers.
In subsequent sections we are going to develop the ATM example into
a complete description in UML.
The tutorial, however, will only walk you through part of it.
At this point you should create a directory to contain your project.
Name the directory anything you feel is consistent with the rest of your
file system.
You should name the contents and any subdirectories as directed for reasons
that will become apparent.
The case study will be an ATM system.
Your company is FlyByNight Industries.
You are going to play two roles.
That of the Project Manager and that of the Designer Analyst.
We are not going to build a physical ATM, of course.
The product that we will build as a case study will be an ATM simulator
to be used for testing the design of a physical ATM.
How your company arranges its work into projects is usually determined as
much by politics as anything else and is, therefore, out of the scope of
this document.
We will go into how you structure the project itself once one has been
defined.
Chapter 3. UML Based OOA&D
In this chapter, we look at how UML as a notation is used
within OOA&D.
Object orientation as a concept has
been around since the 1960's, and as a design concept
since 1972. However it was in the 1980's that it started
to develop as a credible alternative to a functional
approach in analysis and design. We can identify a
number of drivers.
The emergence of mainstream OO programming languages
like SmallTalk and particularly C++. C++ was a pragmatic OO
language derived from C, widely used because of its
association with Unix.
The development of powerful workstations, and with
them the emergence into the mainstream of windowing
operating user environments. Graphical User Interfaces
(GUI) have an inherent object structure.
A number of very public major project failures,
suggesting that current approaches were not
satisfactory.
A number of researchers proposed OOA&D processes, and
with them notations. Those that