mirror of https://github.com/dspinellis/UMLGraph
Add documentation files.
This commit is contained in:
Diomidis Spinellis
parent
35ffe1e685
commit
cfd67610ab
|
|
@ -0,0 +1,81 @@
|
|||
# usage-example for the comment extensions to the
|
||||
# "Pic macros for drawing UML sequence diagrams"
|
||||
#
|
||||
# (C) Copyright 2005 Sebastian Setzer
|
||||
#
|
||||
# Permission to use, copy, and distribute this software and its
|
||||
# documentation for any purpose and without fee is hereby granted,
|
||||
# provided that the above copyright notice appear in all copies and that
|
||||
# both that copyright notice and this permission notice appear in
|
||||
# supporting documentation.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
|
||||
# WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
|
||||
# MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
actor(U, "");
|
||||
object(G,"g:GUI");
|
||||
placeholder_object(Dummy1); # more space
|
||||
placeholder_object(D);
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
active(G);
|
||||
step();
|
||||
|
||||
create_message(G,D,"db:DB");
|
||||
active(D);
|
||||
step();
|
||||
inactive(D);
|
||||
|
||||
async(); # use asynchrone messages (not-filled arrowheads)
|
||||
|
||||
comment(D,C,down 1 right, wid 1 ht 0.7 "waiting for" "condition" "dbMailbox")
|
||||
|
||||
message(U,G,"openBrowser");
|
||||
message(G,D,"query()"); active(D);
|
||||
message(D,G,"result"); inactive(D);
|
||||
|
||||
connect_to_comment(D,C)
|
||||
|
||||
message(U,G,"scroll");
|
||||
message(G,D,"query()"); active(D);
|
||||
message(D,G,"result"); inactive(D);
|
||||
|
||||
connect_to_comment(D,C)
|
||||
|
||||
message(U,G,"Exit");
|
||||
step();
|
||||
begin_frame(G,F,"OnExit");
|
||||
message(G,D,"shutdown()"); inactive(G); active(D);
|
||||
comment(G,C,down .2 right .2, wid 2 ht 0.25 "wait for cond. dbShutdown")
|
||||
step();
|
||||
comment(D,C,right, wid 2 ht 1 \
|
||||
"all queries preceeding the" \
|
||||
"shutdown in the mailbox" \
|
||||
"are answered already." \
|
||||
"DbQuery-Objects can" \
|
||||
"be destroyed")
|
||||
message(D,G,"done"); inactive(D); active(G);
|
||||
|
||||
sync();
|
||||
destroy_message(G,D,"");
|
||||
|
||||
step();
|
||||
end_frame(D,F);
|
||||
|
||||
step();
|
||||
inactive(G);
|
||||
|
||||
# Complete the lifelines
|
||||
step();
|
||||
complete(G);
|
||||
complete(U);
|
||||
.PE
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
PIC2PLOT=/app/plotutils/bin/pic2plot
|
||||
NETPBM=/app/netpbm/bin
|
||||
GS=/app/gs
|
||||
DESTDIR=/dds/pubs/web/home/sw/umlgraph
|
||||
THREAD=/dds/pubs/courses/intro/thread.pl
|
||||
GIF := $(shell sed -n 's/.*<img *src *= *"\([^.]*\.gif\)".*/\1/p' *.xml)
|
||||
XML := $(wildcard *.xml)
|
||||
|
||||
.SUFFIXES:.java .dot .ps .gif .pic .eps .png
|
||||
|
||||
.java.dot:
|
||||
javadoc -docletpath ../lib/UmlGraph.jar -doclet gr.spinellis.umlgraph.doclet.UmlGraph -private $<
|
||||
mv graph.dot $@
|
||||
|
||||
.dot.eps:
|
||||
dot -Teps -o$@ $<
|
||||
|
||||
.dot.gif:
|
||||
dot -Tps $< | \
|
||||
$(GS)/gs -I$(GS) -I$(GS)/fonts -q -r360 -dNOPAUSE -sDEVICE=pnm -sOutputFile=- - -c quit | \
|
||||
$(NETPBM)/pnmcrop | \
|
||||
$(NETPBM)/pnmscale 0.25 | \
|
||||
$(NETPBM)/ppmtogif >$@
|
||||
|
||||
.pic.eps:
|
||||
perl -p -e 'BEGIN {binmode(STDOUT);} s/\r//' $< | $(PIC2PLOT) -Teps >$@
|
||||
|
||||
# Could also use -Tgif, but going through Ghostscript produces a much better
|
||||
# anti-aliased image
|
||||
.pic.gif:
|
||||
perl -p -e 'BEGIN {binmode(STDOUT);} s/\r//' $< | \
|
||||
$(PIC2PLOT) -Tps | \
|
||||
$(GS)/gs -I$(GS) -I$(GS)/fonts -q -r360 -dNOPAUSE -sDEVICE=pnm -sOutputFile=- - -c quit | \
|
||||
$(NETPBM)/pnmcrop | \
|
||||
$(NETPBM)/pnmscale 0.25 | \
|
||||
$(NETPBM)/ppmtogif >$@
|
||||
|
||||
|
||||
all: sequence.pic $(GIF) $(XML)
|
||||
echo "Drawing UML Diagrams with UMLGraph" | perl $(THREAD) -n -h html -r -p ../index.html index ${DESTDIR}/doc
|
||||
|
||||
sequence.pic: ../sequence.pic
|
||||
perl -p -e 'BEGIN {binmode(STDOUT);} s/\r//' $< >$@
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
// Author: Vadim Nasardinov
|
||||
// Version: $Id$
|
||||
|
||||
import java.util.List;
|
||||
import java.util.Map;
|
||||
|
||||
/**
|
||||
* @assoc "1..1" - "0..n" Adapter
|
||||
* @assoc "" - "0..n" ObjectType
|
||||
* @assoc "" - "0..n" ObjectMap
|
||||
* @assoc "" - "0..n" Table
|
||||
* @assoc "" - "0..n" DataOperation
|
||||
**/
|
||||
class Root {
|
||||
private Map m_adapters;
|
||||
private List m_types;
|
||||
private List m_maps;
|
||||
private List m_tables;
|
||||
private List m_ops;
|
||||
|
||||
public Adapter getAdapter(Class klass) {}
|
||||
}
|
||||
|
||||
class Adapter {
|
||||
public Root getRoot();
|
||||
}
|
||||
|
||||
abstract class Element {
|
||||
Root getRoot() {}
|
||||
}
|
||||
|
||||
class ObjectType extends Element {}
|
||||
|
||||
/**
|
||||
* @has "1..1" - "1..1" ObjectType
|
||||
**/
|
||||
class ObjectMap extends Element {
|
||||
private ObjectType m_type;
|
||||
}
|
||||
|
||||
class Table extends Element {}
|
||||
|
||||
class DataOperation extends Element {}
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following individuals have constributed useful comments and code.
|
||||
UMLGraph would not be in its current state without their contributions.
|
||||
<ul>
|
||||
<li>Nascif Abousalh-Neto</li>
|
||||
<li>Andrea Aime</li>
|
||||
<li>Yves Bossel</li>
|
||||
<li>Nick Efthymiou</li>
|
||||
<li>Antti Hakala</li>
|
||||
<li>Art Hampton</li>
|
||||
<li>Scott Johnson</li>
|
||||
<li>Vadim Nasardinov</li>
|
||||
<li>Olek Poplavskyy</li>
|
||||
<li>Alessandro Riva</li>
|
||||
<li>Arnaud Rogues</li>
|
||||
<li>Jonathan R. Santos</li>
|
||||
<li>Sebastian Setzer</li>
|
||||
</ul>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
/*
|
||||
* Advanced relationships
|
||||
* UML User Guide p. 137
|
||||
* $Id$
|
||||
*/
|
||||
|
||||
/**
|
||||
* @opt attributes
|
||||
* @opt operations
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
class Controller {}
|
||||
class EmbeddedAgent {}
|
||||
class PowerManager {}
|
||||
|
||||
/**
|
||||
* @extends Controller
|
||||
* @extends EmbeddedAgent
|
||||
* @navassoc - - - PowerManager
|
||||
*/
|
||||
class SetTopController implements URLStreamHandler {
|
||||
int authorizationLevel;
|
||||
void startUp() {}
|
||||
void shutDown() {}
|
||||
void connect() {}
|
||||
}
|
||||
|
||||
/** @depend - <friend> - SetTopController */
|
||||
class ChannelIterator {}
|
||||
|
||||
interface URLStreamHandler {
|
||||
void OpenConnection();
|
||||
void parseURL();
|
||||
void setURL();
|
||||
void toExternalForm();
|
||||
}
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
// $Id$
|
||||
|
||||
/**
|
||||
* Associations with visibility
|
||||
* UML User Guide p. 145
|
||||
*
|
||||
* @opt horizontal
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/** @assoc * - "*\n\n+user " User */
|
||||
class UserGroup {}
|
||||
|
||||
/** @navassoc "1\n\n+owner\r" - "*\n\n+key" Password */
|
||||
class User{}
|
||||
|
||||
class Password{}
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
@Article{GKNK93,
|
||||
author = "Emden R. Gasner and Eleftherios Koutsofios and Stephen C. North and Kiem-Phong Vo",
|
||||
Title="A Technique for Drawing Directed Graphs",
|
||||
Journal=ieeese,
|
||||
Pages="124--230",
|
||||
Volume="19",
|
||||
Number="3",
|
||||
Month=may,
|
||||
Year="1993"
|
||||
}
|
||||
|
||||
@Article{Spi03e,
|
||||
Title="On the Declarative Specification of Models",
|
||||
Author="Diomidis Spinellis",
|
||||
Journal="IEEE Software",
|
||||
Month="March/April",
|
||||
Year=2003,
|
||||
Volume=20,
|
||||
Pages="94--96",
|
||||
Number=2,
|
||||
URL="http://www.dmst.aueb.gr/dds/pubs/jrnl/2003-IEEESW-umlgraph/html/article.html"
|
||||
}
|
||||
|
||||
@Book {Spi03i,
|
||||
Author="Diomidis Spinellis",
|
||||
Title="Code Reading: The Open Source Perspective",
|
||||
Publisher="Addison-Wesley",
|
||||
Address="Boston, MA",
|
||||
URL="http://www.spinellis.gr/codereading",
|
||||
Year=2003
|
||||
}
|
||||
|
||||
@TechReport {TRPIC,
|
||||
Author="Brian W. Kernighan",
|
||||
Title="{PIC}---A Graphics Language for typesetting: Revised User Manual",
|
||||
Type="Computer Science Technical Report",
|
||||
Note="Available online at http://cm.bell-labs.com/cm/cs/cstr",
|
||||
Number="116",
|
||||
Month=dec,
|
||||
Year="1984",
|
||||
Institution="Bell Laboratories",
|
||||
Address="Murray Hill, NJ"
|
||||
}
|
||||
|
||||
@Book {FS00,
|
||||
Author="Martin Fowler and Kendall Scott",
|
||||
Title="{UML} Distilled: Applying the Standard Object Modeling Language",
|
||||
Publisher="Addison-Wesley",
|
||||
ISBN="0-201-65783-X",
|
||||
Address="Boston, MA",
|
||||
Edition="second",
|
||||
Year=2000
|
||||
}
|
||||
|
||||
@Book{BRJ99,
|
||||
Title="The Unified Modeling Language User Guide",
|
||||
Author="Grady Booch and James Rumbaugh and Ivar Jacobson",
|
||||
Publisher="Addison-Wesley",
|
||||
Address="Reading, MA",
|
||||
Year="1999",
|
||||
ISBN="0-201-57168-4"
|
||||
}
|
||||
|
||||
@Book{RJB99,
|
||||
Title="The Unified Modeling Language Reference Manual",
|
||||
Author="James Rumbaugh and Ivar Jacobson and Grady Booch",
|
||||
Publisher="Addison-Wesley",
|
||||
Address="Reading, MA",
|
||||
Year="1999",
|
||||
ISBN="0-201-30998-X",
|
||||
Where="dds-CD1"
|
||||
}
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<!-- BEGIN BIBLIOGRAPHY tmp -->
|
||||
<!--
|
||||
DO NOT MODIFY THIS BIBLIOGRAPHY BY HAND! IT IS MAINTAINED AUTOMATICALLY!
|
||||
YOUR CHANGES WILL BE LOST THE NEXT TIME IT IS UPDATED!
|
||||
-->
|
||||
<!-- Generated by: bib2xhtml -u -m /dds/bib/macro tmp.bib -->
|
||||
<ul>
|
||||
|
||||
<!-- Authors: Grady Booch and James Rumbaugh and Ivar Jacobson -->
|
||||
<li><a name="BRJ99">Grady</a> Booch, James
|
||||
Rumbaugh, and Ivar Jacobson.
|
||||
<a href="http://www.amazon.com/exec/obidos/ASIN/0201571684/dds-20"><cite>The
|
||||
Unified Modeling Language User Guide</cite></a>.
|
||||
Addison-Wesley, Reading, MA, 1999.<p /></li>
|
||||
|
||||
<!-- Authors: Martin Fowler and Kendall Scott -->
|
||||
<li><a name="FS00">Martin</a> Fowler and
|
||||
Kendall Scott.
|
||||
<a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/dds-20"><cite>UML
|
||||
Distilled: Applying the Standard Object Modeling Language</cite></a>.
|
||||
Addison-Wesley, Boston, MA, second edition, 2000.<p /></li>
|
||||
|
||||
<!-- Authors: Emden R Gasner and Eleftherios Koutsofios and Stephen C North and
|
||||
Kiem Phong Vo -->
|
||||
<li><a name="GKNK93">Emden</a> R. Gasner,
|
||||
Eleftherios Koutsofios, Stephen C. North, and Kiem-Phong Vo.
|
||||
A technique for drawing directed graphs.
|
||||
<cite>IEEE Transactions on Software Engineering</cite>, 19(3):124–230, May
|
||||
1993.<p /></li>
|
||||
|
||||
<!-- Authors: Brian W Kernighan -->
|
||||
<li><a name="TRPIC">Brian</a> W. Kernighan.
|
||||
PIC—a graphics language for typesetting: Revised user manual.
|
||||
Computer Science Technical Report 116, Bell Laboratories, Murray Hill, NJ,
|
||||
December 1984.
|
||||
Available online at http://cm.bell-labs.com/cm/cs/cstr.<p /></li>
|
||||
|
||||
<!-- Authors: James Rumbaugh and Ivar Jacobson and Grady Booch -->
|
||||
<li><a name="RJB99">James</a> Rumbaugh, Ivar
|
||||
Jacobson, and Grady Booch.
|
||||
<a href="http://www.amazon.com/exec/obidos/ASIN/020130998X/dds-20"><cite>The
|
||||
Unified Modeling Language Reference Manual</cite></a>.
|
||||
Addison-Wesley, Reading, MA, 1999.<p /></li>
|
||||
|
||||
<!-- Authors: Diomidis Spinellis -->
|
||||
<li><a name="Spi03i">Diomidis</a> Spinellis.
|
||||
<a href="http://www.spinellis.gr/codereading"><cite>Code Reading: The Open
|
||||
Source Perspective</cite></a>.
|
||||
Addison-Wesley, Boston, MA, 2003.<p /></li>
|
||||
|
||||
<!-- Authors: Diomidis Spinellis -->
|
||||
<li><a name="Spi03e">Diomidis</a> Spinellis.
|
||||
<a href="http://www.dmst.aueb.gr/dds/pubs/jrnl/2003-IEEESW-umlgraph/html/article.html">On the declarative specification of models</a>.
|
||||
<cite>IEEE Software</cite>, 20(2):94–96, March/April 2003.<p /></li>
|
||||
|
||||
</ul>
|
||||
|
||||
<!-- END BIBLIOGRAPHY tmp -->
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
// $Id$
|
||||
|
||||
class Tyre {}
|
||||
class Engine {}
|
||||
class Body {}
|
||||
|
||||
/**
|
||||
* @composed 1 - 4 Tyre
|
||||
* @composed 1 - 1 Engine
|
||||
* @composed 1 - 1 Body
|
||||
*/
|
||||
class Car {}
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
/*
|
||||
* Interface and generalization relationships in Jakarta Catalina
|
||||
* $Id$
|
||||
*/
|
||||
|
||||
class HttpResponseBase
|
||||
extends ResponseBase
|
||||
implements HttpResponse, HttpServletResponse {}
|
||||
|
||||
abstract class HttpResponseWrapper
|
||||
extends ResponseWrapper
|
||||
implements HttpResponse {}
|
||||
|
||||
class HttpResponseFacade
|
||||
extends ResponseFacade
|
||||
implements HttpServletResponse {}
|
||||
|
||||
abstract class ResponseWrapper implements Response {}
|
||||
abstract interface HttpResponse extends Response {}
|
||||
abstract class ResponseBase implements Response, ServletResponse {}
|
||||
abstract interface HttpServletResponse {}
|
||||
class ResponseFacade implements ServletResponse {}
|
||||
|
||||
abstract interface ServletResponse {}
|
||||
abstract interface Response {}
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
<?xml version="1.0" encoding="ISO-8859-7" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
One specifies a class diagram using the Java syntax complemented by
|
||||
<a href="http://java.sun.com/j2se/javadoc/"><em>javadoc</em></a>
|
||||
tags.
|
||||
Running the UmlGraph doclet on the specification will generate
|
||||
a
|
||||
<a href="http://www.research.att.com/sw/tools/graphviz/">Graphviz</a>
|
||||
diagram specification that can be automatically processed to
|
||||
create Postscript, GIF, SVG, JPEG, fig, or Framemaker drawings.
|
||||
<p />
|
||||
The following is an example of a specification and the resulting UML class
|
||||
diagram:
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
class Person {
|
||||
String Name;
|
||||
}
|
||||
|
||||
class Employee extends Person {}
|
||||
|
||||
class Client extends Person {}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="class-eg.gif" alt="Simple UML class diagram" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The UMLGraph class diagrams allows you to model
|
||||
<ul>
|
||||
<li>classes (specified as Java classes)
|
||||
</li>
|
||||
<li>attributes (specified as Java class fields)
|
||||
</li>
|
||||
<li>operations (specified as Java class methods)
|
||||
</li>
|
||||
<li>stereotypes (using the <code>@stereotype</code> <em>name</em> tag)
|
||||
</li>
|
||||
<li>tagged values (using the <code>@tagvalue</code> <em>name</em> <em>value</em> tag)
|
||||
</li>
|
||||
<li>implementation relationships (specified using the Java <code>implements</code> declaration)
|
||||
</li>
|
||||
<li>generalization relationships (specified using the Java <code>extends</code> declaration or (for multiple inheritance) the <em>javadoc</em> <code>@extends</code> tag)
|
||||
</li>
|
||||
<li>association relationships (specified using the <em>javadoc</em> <code>@assoc</code> tag)
|
||||
</li>
|
||||
<li>navigatable (directed) association relationships (specified using the <em>javadoc</em> <code>@navassoc</code> tag)
|
||||
</li>
|
||||
<li>aggregation relationships (specified using the <em>javadoc</em> <code>@has</code> tag)
|
||||
</li>
|
||||
<li>composition relationships (specified using the <em>javadoc</em> <code>@composed</code> tag)
|
||||
</li>
|
||||
<li>dependency relationships (specified using the <em>javadoc</em> <code>@depend</code> tag)
|
||||
</li>
|
||||
</ul>
|
||||
All relationship tags appart from <code>@extends</code> take four arguments:
|
||||
<ol>
|
||||
<li> The source adornments (role, multiplicity, and visibility)
|
||||
</li>
|
||||
<li> The relationship name
|
||||
</li>
|
||||
<li> The target adornments (role, multiplicity, and visibility)
|
||||
</li>
|
||||
<li> The target class
|
||||
</li>
|
||||
</ol>
|
||||
Arguments can be space-separated, or enclosed in quotes if they
|
||||
need to contain the space character.
|
||||
The - character is used as a placeholder to denote empty arguments.
|
||||
You can use the \n sequence to separate the first three adornments
|
||||
in separate centered lines;
|
||||
the \l and \r sequences can also be used to generate left and right
|
||||
aligned lines.
|
||||
You can use the < and > characters in the relationship name
|
||||
to enclose stereotype names.
|
||||
These will be automatically enclosed in guillemots.
|
||||
Note that a relationship's target class is not implicitly
|
||||
defined; it should also be specified using the Java class syntax.
|
||||
The following is an example of a relationship
|
||||
specification and the resulting UML diagram:
|
||||
<table>
|
||||
<tr><td>
|
||||
<pre>
|
||||
class Tyre {}
|
||||
class Engine {}
|
||||
class Body {}
|
||||
|
||||
/**
|
||||
* @composed 1 - 4 Tyre
|
||||
* @composed 1 - 1 Engine
|
||||
* @composed 1 - 1 Body
|
||||
*/
|
||||
class Car {}
|
||||
</pre>
|
||||
</td><td>
|
||||
<img src="car.gif" alt="UML relationship diagram" />
|
||||
</td></tr></table>
|
||||
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
To use UMLGraph class drawing facility you need to have
|
||||
<a href="http://java.sun.com/j2se/javadoc/"><em>javadoc</em></a>
|
||||
and
|
||||
<a href="http://www.research.att.com/sw/tools/graphviz/">Graphviz</a>
|
||||
installed on your computer.
|
||||
Both programs are freely available, from Sun and AT&T respectively,
|
||||
for many platforms including Unix and Windows.
|
||||
UMLGraph's input follows the Java syntax and semantics.
|
||||
However,
|
||||
since the main purpose of UMLGraph is the declarative specification of
|
||||
UML diagrams there is no need to flesh-out each class's methods,
|
||||
to completely specify each class, or to specify package information.
|
||||
You only specify the details you want to appear on the graph.
|
||||
If you wish your (Java) implementation to evolve together with the
|
||||
design feel free to include code or additional details.
|
||||
You can hide these details from the UML diagram using the <em>javadoc</em>
|
||||
<code>@hidden</code> tag applied to classes, methods, and fields.
|
||||
In theory you can also use UMLGraph to reverse engineer existing
|
||||
Java code.
|
||||
Note however that UMLGraph is not designed for this purpose;
|
||||
the resulting graphs may be large and unwieldy.
|
||||
<p />
|
||||
UMLGraph is implemented as a <em>javadoc</em> doclet (a program satisfying the
|
||||
doclet API that specifies the content and format of the output
|
||||
generated by the <em>javadoc</em> tool).
|
||||
<em>Javadoc</em> is part of the Sun JDK, so a typical JDK installation will also
|
||||
include <em>javadoc</em>.
|
||||
Before running <em>javadoc</em> you need to place the <code>UmlGraph.jar</code>
|
||||
file in a location accessible by <em>javadoc</em>
|
||||
(e.g. the Java class path or the current directory).
|
||||
You then run <em>javadoc</em> with arguments <code>-doclet gr.spinellis.umlgraph.doclet.UmlGraph</code>
|
||||
<code>-docletpath /path/to/UmlGraph.jar</code>
|
||||
and append at the end the file(s) that contain your diagram
|
||||
specification.
|
||||
You can of course use any of the <em>javadoc</em> general options;
|
||||
<code>-private</code> is usually needed to avoid having to explicitly
|
||||
specify public elements.
|
||||
<p />
|
||||
Specifying some packages before the list of source files will designate
|
||||
those packages as <em>local</em>.
|
||||
When you specify a package list,
|
||||
the SVG output UmlGraph generates will contain
|
||||
local hyperlinks for the local classes
|
||||
and hyperlinks to the Sun Java API documentation for all other classes.
|
||||
<p />
|
||||
Example:
|
||||
<fmtcode ext="sh">
|
||||
javadoc -docletpath UmlGraph.jar -doclet gr.spinellis.umlgraph.doclet.UmlGraph -private Simple.java
|
||||
</fmtcode>
|
||||
<em>javadoc</em> will create by default a file named <code>graph.dot</code>
|
||||
in the current directory; option to
|
||||
this is a text file that can be processed by the <em>Graphviz</em>
|
||||
<em>dot</em> program to layout and draw the graph.
|
||||
A command line like the following will convert the <code>graph.dot</code>
|
||||
file into Postscript:
|
||||
<fmtcode ext="sh">
|
||||
dot -Tps -ograph.ps graph.dot
|
||||
</fmtcode>
|
||||
Refer to the <em>dot</em> documentation for information on creating other file formats
|
||||
or adjusting the UMLGraph output.
|
||||
<p />
|
||||
Note that when you use <em>dot</em> for generating SVG diagrams your
|
||||
should specify the <code>-outputencoding UTF-8</code> option to UMLGraph.
|
||||
This option will correctly render the stereotype guillemot characters
|
||||
in the <em>dot</em> output and the corresponding SVG file.
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,124 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
A number of command-line options contol the operation of UMLGraph
|
||||
class diagram generator:
|
||||
<dl>
|
||||
<dt>-output</dt><dd>Specify the output file name (default <code>graph.dot</code>).
|
||||
</dd>
|
||||
<dt>-outputencoding</dt><dd>Specify the output encoding character set (default <code>ISO-8859-1</code>).
|
||||
When using <em>dot</em> to generate SVG diagrams you should specify
|
||||
<code>UTF-8</code> as the output encoding, to have guillemots correctly
|
||||
appearing in the resulting SVG.
|
||||
</dd>
|
||||
<dt>-qualify</dt><dd>Produce fully-qualified class names.
|
||||
</dd>
|
||||
<dt>-horizontal</dt><dd>Layout the graph in the horizontal direction.
|
||||
</dd>
|
||||
<dt>-attributes</dt><dd>Show class attributes (Java fields)
|
||||
</dd>
|
||||
<dt>-operations</dt><dd>Show class operations (Java methods)
|
||||
</dd>
|
||||
<dt>-constructors</dt><dd>Show a class's constructors
|
||||
</dd>
|
||||
<dt>-visibility</dt><dd>Adorn class elements according to their
|
||||
visibility (private, public, protected, package)
|
||||
</dd>
|
||||
<dt>-types</dt><dd>Add type information to attributes and operations
|
||||
</dd>
|
||||
<dt>-enumerations</dt><dd>Show enumarations as separate stereotyped primitive
|
||||
types.
|
||||
</dd>
|
||||
<dt>-enumconstants</dt><dd>When showing enumerations, also show the values they can take.
|
||||
</dd>
|
||||
<dt>-all</dt><dd>Same as
|
||||
<code>-attributes</code>
|
||||
<code>-operations</code>
|
||||
<code>-visibility</code>
|
||||
<code>-types</code>
|
||||
<code>-enumerations</code>
|
||||
<code>-enumconstants</code>
|
||||
</dd>
|
||||
<dt>-nodefillcolor</dt><dd>Specify the color to use to fill the shapes.
|
||||
</dd>
|
||||
<dt>-nodefontname</dt><dd>Specify the font name to use inside nodes.
|
||||
</dd>
|
||||
<dt>-nodefontabstractname</dt><dd>Specify the font name to use
|
||||
inside abstract class nodes.
|
||||
</dd>
|
||||
<dt>-nodefontsize</dt><dd>Specify the font size to use inside nodes.
|
||||
</dd>
|
||||
<dt>-nodefontcolor</dt><dd>Specify the font color to use inside nodes.
|
||||
</dd>
|
||||
<dt>-edgefontname</dt><dd>Specify the font name to use for edge labels.
|
||||
</dd>
|
||||
<dt>-edgefontsize</dt><dd>Specify the font size to use for edge labels.
|
||||
</dd>
|
||||
<dt>-edgefontcolor</dt><dd>Specify the font color to use for edge labels.
|
||||
</dd>
|
||||
<dt>-edgecolor</dt><dd>Specify the color for drawing edges.
|
||||
</dd>
|
||||
<dt>-bgcolor</dt><dd>Specify the graph's background color.
|
||||
</dd>
|
||||
<dt>-hide</dt><dd>Specify entities to hide from the graph.
|
||||
Matching is done against the end of each entity's name.
|
||||
For instance, "<code>-hide Widget</code>" would hide "<code>com.foo.widgets.Widget</code>" and
|
||||
"<code>com.foo.widgets.BigWidget</code>".
|
||||
</dd>
|
||||
<dt>-apidocroot</dt><dd>Specify the URL that should be used as the "root" for local classes.
|
||||
This URL will be used as a prefix, to which the page name for the local class or
|
||||
package will be appended (following the JavaDoc convention).
|
||||
For example, if the value <code>http://www.acme.org/apidocs</code> is
|
||||
provided, the class <code>org.acme.util.MyClass<code> will be mapped to the URL
|
||||
<code>http://www.acme.org/apidocs/org/acme/util/MyClass.html</code>.
|
||||
This URL will then be added to .dot diagram and can be surfaced in the
|
||||
final class diagram by setting the output to SVG, or by creating an HTML page
|
||||
that associates the diagram static image (a .gif or .png) with a client-side
|
||||
image map.
|
||||
</dd>
|
||||
<dt>-apidocmap</dt><dd>Specify the file name of the URL mapping table.
|
||||
The is a standard Java property file, where the property name is a regular
|
||||
expression (as defined in the java.util.regex package) and the property value is
|
||||
an URL "root" as described above.
|
||||
This table is used to resolved external class names (class names that do not
|
||||
belong to the current package being processed by UMLGraph). If no file is provided,
|
||||
external classes will just be mapped to the on-line Java API documentation.
|
||||
</dd>
|
||||
<dt>-noguillemot</dt><dd>Specify that guillemot characters should not
|
||||
be used to denote special terms like "interface" and stereotype names.
|
||||
This is used on some platforms to circumvent problems associated
|
||||
with displaying non-ASCII characters.
|
||||
</dd>
|
||||
</dl>
|
||||
<p />
|
||||
All colors can be either a symbolic name (e.g. blue),
|
||||
a tripple specifying hue-saturation-brightness as values 0-1
|
||||
(e.g. ".13 0.9 1"),
|
||||
or a tripple specifying red-green-blue values as hexadecimal
|
||||
digits prefixed by a # (e.g. "#ff8020").
|
||||
The symbolic color names are derived from the X Windows System;
|
||||
you can find a complete list in the Graphviz documentation.
|
||||
<p />
|
||||
Font names are passed directly to the dot graph generation back-end.
|
||||
In general the Postcript standard names Times, Helvetica, Courier, and
|
||||
Symbol are safe to use.
|
||||
<p />
|
||||
Since the options are really a part of the generated graph you
|
||||
want in many cases to include them in the diagram specification.
|
||||
You can do that by adding <em>javadoc</em> <code>@opt</code> tags in front
|
||||
of a class named <code>UMLOptions</code>, as in the following example:
|
||||
<fmtcode ext="java">
|
||||
/**
|
||||
* @opt horizontal
|
||||
* @opt all
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
</fmtcode>
|
||||
|
||||
You can also change the UMLGraph operation on a per-class basis by
|
||||
using <code>@opt</code> attributes on individual classes.
|
||||
In this case the <code>@opt</code> specification temporarily overrides
|
||||
the particular global setting for the class being processed.
|
||||
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
/*
|
||||
* Advanced relationships
|
||||
* UML User Guide p. 137
|
||||
*/
|
||||
|
||||
/**
|
||||
* @opt attributes
|
||||
* @opt operations
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
class Controller {}
|
||||
class EmbeddedAgent {}
|
||||
class PowerManager {}
|
||||
|
||||
/**
|
||||
* @extends Controller
|
||||
* @extends EmbeddedAgent
|
||||
* @navassoc - - - PowerManager
|
||||
*/
|
||||
class SetTopController implements URLStreamHandler {
|
||||
int authorizationLevel;
|
||||
void startUp() {}
|
||||
void shutDown() {}
|
||||
void connect() {}
|
||||
}
|
||||
|
||||
/** @depend - <friend> - SetTopController */
|
||||
class ChannelIterator {}
|
||||
|
||||
interface URLStreamHandler {
|
||||
void OpenConnection();
|
||||
void parseURL();
|
||||
void setURL();
|
||||
void toExternalForm();
|
||||
}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="advrel.gif" alt="UML diagram showing dependency and navigation relationships" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
/**
|
||||
* Associations with visibility
|
||||
* UML User Guide p. 145
|
||||
*
|
||||
* @opt horizontal
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/** @assoc * - "*\n\n+user " User */
|
||||
class UserGroup {}
|
||||
|
||||
/** @navassoc "1\n\n+owner\r" - "*\n\n+key" Password */
|
||||
class User{}
|
||||
|
||||
class Password{}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="assoc.gif" alt="UML diagram showing association types" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<fmtcode ext="java">
|
||||
/*
|
||||
* Interface and generalization relationships in Jakarta Catalina
|
||||
*/
|
||||
|
||||
class HttpResponseBase
|
||||
extends ResponseBase
|
||||
implements HttpResponse, HttpServletResponse {}
|
||||
|
||||
abstract class HttpResponseWrapper
|
||||
extends ResponseWrapper
|
||||
implements HttpResponse {}
|
||||
|
||||
class HttpResponseFacade
|
||||
extends ResponseFacade
|
||||
implements HttpServletResponse {}
|
||||
|
||||
abstract class ResponseWrapper implements Response {}
|
||||
abstract interface HttpResponse extends Response {}
|
||||
abstract class ResponseBase implements Response, ServletResponse {}
|
||||
abstract interface HttpServletResponse {}
|
||||
class ResponseFacade implements ServletResponse {}
|
||||
|
||||
abstract interface ServletResponse {}
|
||||
abstract interface Response {}
|
||||
</fmtcode>
|
||||
<img src="catalina.gif" alt="UML diagram of representative Cataline classes" /><br />
|
||||
</notes>
|
||||
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
/**
|
||||
* @opt edgecolor "yellow"
|
||||
* @opt nodefontname "Times"
|
||||
* @opt bgcolor ".7 .9 1"
|
||||
* @opt nodefillcolor "#a0a0a0"
|
||||
* @opt nodefontsize 14
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions{}
|
||||
|
||||
/**
|
||||
* @opt nodefontname "Helvetica-Bold"
|
||||
* @opt nodefontcolor "white"
|
||||
* @composed - - - Red
|
||||
* @composed - - - Green
|
||||
* @composed - - - Blue
|
||||
* @opt attributes
|
||||
* @opt visibility
|
||||
* @opt types
|
||||
*/
|
||||
class Pixel {
|
||||
private int x, y;
|
||||
public void setColor(ColorValue v) {}
|
||||
}
|
||||
|
||||
/** @opt nodefillcolor red */
|
||||
class Red {}
|
||||
|
||||
/** @opt nodefillcolor green */
|
||||
class Green {}
|
||||
|
||||
/** @opt nodefillcolor blue */
|
||||
class Blue {}
|
||||
|
||||
/** @hidden */
|
||||
class ColorValue{}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="color.gif" alt="UML diagram demonstrating the use of colors" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
/**
|
||||
* Attribute and operation visility
|
||||
* UML User Guide p. 123
|
||||
*
|
||||
* @opt operations
|
||||
* @opt attributes
|
||||
* @opt types
|
||||
* @opt visibility
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/** @hidden */
|
||||
class Tool {}
|
||||
|
||||
class Toolbar {
|
||||
protected Tool currentSelection;
|
||||
protected Integer toolCount;
|
||||
public void pickItem(Integer i) {}
|
||||
public void addTool(Tool t) {}
|
||||
public void removeTool(Integer i) {}
|
||||
public Tool getTool() {}
|
||||
protected void checkOrphans() {}
|
||||
private void compact() {}
|
||||
}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="vis.gif" alt="UML diagram showing attribute and operation visility" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
/*
|
||||
* Generalisation
|
||||
* UML User Guide p. 141
|
||||
*/
|
||||
|
||||
/* Basic categorisations */
|
||||
class Asset {}
|
||||
class InterestBearingItem {}
|
||||
class InsurableItem {}
|
||||
|
||||
/* Asset types */
|
||||
/**
|
||||
* @extends InsurableItem
|
||||
* @extends InterestBearingItem
|
||||
*/
|
||||
class BankAccount extends Asset {}
|
||||
/** @extends InsurableItem */
|
||||
class RealEstate extends Asset {}
|
||||
class Security extends Asset {}
|
||||
|
||||
/* Securities */
|
||||
class Stock extends Security {}
|
||||
class Bond extends Security {}
|
||||
|
||||
/* Bank accounts */
|
||||
class CheckingAccount extends BankAccount {}
|
||||
class SavingsAccount extends BankAccount {}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="general.gif" alt="UML diagram showing generalization relationships" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,169 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
Vadim Nasardinov noted that an advantage of UMLGraph over many
|
||||
GUI-oriented UML drawing tools is the ability
|
||||
to generate different views of a diagram
|
||||
from the same source description.
|
||||
The following two diagrams were generated from the same source;
|
||||
a Makefile illustrates a way to organize this process.
|
||||
<h2>Class Overview</h2>
|
||||
<img src="Root-small.png" alt="Class overview" />
|
||||
|
||||
<h2>Detailed Class View</h2>
|
||||
<img src="Root.png" alt="Detailed class view" />
|
||||
|
||||
<h2>Java Description</h2>
|
||||
<fmtcode ext="java">
|
||||
// Author: Vadim Nasardinov
|
||||
// Version: $Id$
|
||||
|
||||
import java.util.List;
|
||||
import java.util.Map;
|
||||
|
||||
/**
|
||||
* @assoc "1..1" - "0..n" Adapter
|
||||
* @assoc "" - "0..n" ObjectType
|
||||
* @assoc "" - "0..n" ObjectMap
|
||||
* @assoc "" - "0..n" Table
|
||||
* @assoc "" - "0..n" DataOperation
|
||||
**/
|
||||
class Root {
|
||||
private Map m_adapters;
|
||||
private List m_types;
|
||||
private List m_maps;
|
||||
private List m_tables;
|
||||
private List m_ops;
|
||||
|
||||
public Adapter getAdapter(Class klass) {}
|
||||
}
|
||||
|
||||
class Adapter {
|
||||
public Root getRoot();
|
||||
}
|
||||
|
||||
abstract class Element {
|
||||
Root getRoot() {}
|
||||
}
|
||||
|
||||
class ObjectType extends Element {}
|
||||
|
||||
/**
|
||||
* @has "1..1" - "1..1" ObjectType
|
||||
**/
|
||||
class ObjectMap extends Element {
|
||||
private ObjectType m_type;
|
||||
}
|
||||
|
||||
class Table extends Element {}
|
||||
|
||||
class DataOperation extends Element {}
|
||||
</fmtcode>
|
||||
<h2>Makefile</h2>
|
||||
<fmtcode ext="mak">
|
||||
# Author: Vadim Nasardinov (vadimn@redhat.com)
|
||||
# Since: 2004-05-26
|
||||
# Version: $Id$
|
||||
|
||||
# Requires: graphviz
|
||||
# Requires: transfig
|
||||
# Requires: libxslt
|
||||
# Requires: javac
|
||||
# Requires: javadoc
|
||||
# Requires: JAVA_HOME/lib/tools.jar
|
||||
|
||||
.PHONY : clean all build jar dot png debug
|
||||
|
||||
BUILD=build
|
||||
|
||||
jar_dir:=$(BUILD)/jars
|
||||
diagrams := notes/diagrams
|
||||
|
||||
java_files := $(shell find $(diagrams) -name *.java)
|
||||
dot_files := $(subst .java,.dot,$(java_files))
|
||||
dot_files := $(foreach dot, $(dot_files), $(BUILD)/$(dot))
|
||||
dot_files += $(subst .dot,-small.dot,$(dot_files))
|
||||
|
||||
png_files := $(subst .dot,.png,$(dot_files))
|
||||
|
||||
fig_files := $(shell find $(diagrams) -name *.fig)
|
||||
|
||||
png_files += $(subst .fig,.png,$(foreach fig, $(fig_files), $(BUILD)/$(fig)))
|
||||
|
||||
|
||||
premade_src_png := $(shell find $(diagrams) -name *.png)
|
||||
png_files += $(foreach png, $(premade_src_png), $(BUILD)/$(png))
|
||||
|
||||
xml_files:=$(shell find notes -name *.xml)
|
||||
html_files:=$(subst notes/,$(BUILD)/notes/,$(xml_files))
|
||||
html_files:=$(subst .xml,.html,$(html_files))
|
||||
stylesheet:= notes/notes.xsl
|
||||
|
||||
javac_dest:=$(BUILD)/classes
|
||||
|
||||
classpath:=
|
||||
javac=javac -classpath $(JAVA_HOME)/lib/tools.jar -d $(javac_dest)
|
||||
|
||||
timestamp:=$(BUILD)/.timestamp
|
||||
|
||||
uml_graph:=$(jar_dir)/UmlGraph.jar
|
||||
|
||||
jd:=javadoc
|
||||
jd_flags := -docletpath $(uml_graph) -doclet gr.spinellis.umlgraph.doclet.UmlGraph -private
|
||||
jd_flags += -nodefontname luxisr -nodefontabstractname luxisri
|
||||
jd_flags += -edgefontname luxisr
|
||||
jd_flags += -nodefontsize 8 -edgefontsize 8
|
||||
jd_flags += -nodefillcolor LemonChiffon
|
||||
detailed_flags := -attributes -operations -types
|
||||
|
||||
all: doc
|
||||
|
||||
clean:
|
||||
rm -rf $(BUILD)
|
||||
|
||||
jar: $(uml_graph)
|
||||
|
||||
build: $(timestamp)
|
||||
|
||||
$(timestamp): src/UmlGraph.java
|
||||
mkdir -p $(javac_dest)
|
||||
$(javac) $?
|
||||
touch $(timestamp)
|
||||
|
||||
$(uml_graph): $(timestamp)
|
||||
mkdir -p $(jar_dir)
|
||||
jar cf $(uml_graph) -C $(BUILD)/classes .
|
||||
jar i $(uml_graph)
|
||||
|
||||
|
||||
build/%.dot : %.java $(uml_graph)
|
||||
mkdir -p $(dir $@)
|
||||
$(jd) $(jd_flags) $(detailed_flags) -output $@ $<
|
||||
|
||||
build/%-small.dot : %.java $(uml_graph)
|
||||
mkdir -p $(dir $@)
|
||||
$(jd) $(jd_flags) -output $@ $<
|
||||
|
||||
%.png : %.dot $(uml_graph)
|
||||
dot -Nheight=0.2 -Elabelfontcolor=DarkSlateBlue -Elabelfontsize=8 -Tpng -o $@ $<
|
||||
|
||||
build/%.png : %.fig
|
||||
mkdir -p $(dir $@)
|
||||
fig2dev -L png -S 4 $< $@
|
||||
|
||||
png: $(png_files)
|
||||
|
||||
build/%.png : %.png
|
||||
mkdir -p $(dir $@)
|
||||
cp $< $@
|
||||
|
||||
build/%.html: %.xml $(stylesheet)
|
||||
mkdir -p $(dir $@)
|
||||
xsltproc -o $@ $(stylesheet) $<
|
||||
|
||||
doc: $(html_files) $(png_files)
|
||||
|
||||
debug:
|
||||
@echo $(dot_files)
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
/*
|
||||
* Schema model
|
||||
* UML User Guide p. 112
|
||||
*/
|
||||
|
||||
/**
|
||||
* @opt operations
|
||||
* @opt attributes
|
||||
* @opt types
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/* Define some types we use */
|
||||
/** @hidden */
|
||||
class Name {}
|
||||
/** @hidden */
|
||||
class Number {}
|
||||
|
||||
/**
|
||||
* @has 1..* Member * Student
|
||||
* @composed 1..* Has 1..* Department
|
||||
*/
|
||||
class School {
|
||||
Name name;
|
||||
String address;
|
||||
Number phone;
|
||||
void addStudent() {}
|
||||
void removeStudent() {}
|
||||
void getStudent() {}
|
||||
void getAllStudents() {}
|
||||
void addDepartment() {}
|
||||
void removeDepartment() {}
|
||||
void getDepartment() {}
|
||||
void getAllDepartments() {}
|
||||
}
|
||||
|
||||
/**
|
||||
* @has 1..* AssignedTo 1..* Instructor
|
||||
* @assoc 1..* - 1..* Course
|
||||
* @assoc 0..* - "0..1 chairperson" Instructor
|
||||
*/
|
||||
class Department {
|
||||
Name name;
|
||||
void addInstructor() {}
|
||||
void removeInstructor() {}
|
||||
void getInstructor() {}
|
||||
void getAllInstructors() {}
|
||||
}
|
||||
|
||||
/**
|
||||
* @assoc * Attends * Course
|
||||
*/
|
||||
class Student {
|
||||
Name name;
|
||||
Number studentID;
|
||||
}
|
||||
|
||||
class Course {
|
||||
Name name;
|
||||
Number courseID;
|
||||
}
|
||||
|
||||
/**
|
||||
* @assoc 1..* Teaches * Course
|
||||
*/
|
||||
class Instructor {
|
||||
Name name;
|
||||
}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="schema.gif" alt="UML diagram showing a database scheme model" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="java">
|
||||
/*
|
||||
* Class stereotypes and tagged values
|
||||
* UML User Guide p. 439
|
||||
*/
|
||||
|
||||
/**
|
||||
* @opt attributes
|
||||
* @opt operations
|
||||
* @opt types
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/** @hidden */
|
||||
class Action {}
|
||||
|
||||
/**
|
||||
* @stereotype container
|
||||
* @tagvalue version 3.2
|
||||
*/
|
||||
class ActionQueue {
|
||||
void add(Action a) {};
|
||||
/** @tagvalue version 1.0 */
|
||||
void add(Action a, int n) {};
|
||||
void remove(int n) {};
|
||||
/** @stereotype query */
|
||||
int length() {};
|
||||
/** @stereotype "helper functions" */
|
||||
void reorder() {};
|
||||
}
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="classadd.gif" alt="UML diagram of class stereotypes and tagged values" />
|
||||
</td></tr></table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
// $Id$
|
||||
|
||||
/**
|
||||
* @opt nodefillcolor ".13 .9 1"
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions{}
|
||||
|
||||
class Person {
|
||||
String Name;
|
||||
}
|
||||
|
||||
class Employee extends Person {}
|
||||
|
||||
class Client extends Person {}
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
/*
|
||||
* Class stereotypes and tagged values
|
||||
* UML User Guide p. 439
|
||||
* $Id$
|
||||
*/
|
||||
|
||||
/**
|
||||
* @opt attributes
|
||||
* @opt operations
|
||||
* @opt types
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/** @hidden */
|
||||
class Action {}
|
||||
|
||||
/**
|
||||
* @stereotype container
|
||||
* @tagvalue version 3.2
|
||||
*/
|
||||
class ActionQueue {
|
||||
void add(Action a) {};
|
||||
/** @tagvalue version 1.0 */
|
||||
void add(Action a, int n) {};
|
||||
void remove(int n) {};
|
||||
/** @stereotype query */
|
||||
int length() {};
|
||||
/** @stereotype "helper functions" */
|
||||
void reorder() {};
|
||||
}
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
// $Id$
|
||||
|
||||
/**
|
||||
* @opt edgecolor "yellow"
|
||||
* @opt nodefontname "Times"
|
||||
* @opt bgcolor ".7 .9 1"
|
||||
* @opt nodefillcolor "#a0a0a0"
|
||||
* @opt nodefontsize 14
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions{}
|
||||
|
||||
/**
|
||||
* @opt nodefontname "Helvetica-Bold"
|
||||
* @opt nodefontcolor "white"
|
||||
* @composed - - - Red
|
||||
* @composed - - - Green
|
||||
* @composed - - - Blue
|
||||
* @opt attributes
|
||||
* @opt visibility
|
||||
* @opt types
|
||||
*/
|
||||
class Pixel {
|
||||
private int x, y;
|
||||
public void setColor(ColorValue v) {}
|
||||
}
|
||||
|
||||
/** @opt nodefillcolor red */
|
||||
class Red {}
|
||||
|
||||
/** @opt nodefillcolor green */
|
||||
class Green {}
|
||||
|
||||
/** @opt nodefillcolor blue */
|
||||
class Blue {}
|
||||
|
||||
/** @hidden */
|
||||
class ColorValue{}
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
# UML Distilled: Figure 5-2 p. 70
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
boxwid = 1.3;
|
||||
|
||||
# Define the objects
|
||||
pobject(X);
|
||||
pobject(T);
|
||||
pobject(C);
|
||||
pobject(A1);
|
||||
pobject(A2);
|
||||
|
||||
# Message sequences
|
||||
cmessage(X,T,"a: Transaction");
|
||||
active(T);
|
||||
async();
|
||||
cmessage(T,C,"a: TransCoord");
|
||||
inactive(T);
|
||||
active(C);
|
||||
cmessage(C,A1,"a1: TransCheck");
|
||||
active(A1);
|
||||
cmessage(C,A2,"a2: TransCheck");
|
||||
active(A2);
|
||||
message(A1,C,"ok");
|
||||
sync();
|
||||
step();
|
||||
active(C);
|
||||
message(C,C,"all done?");
|
||||
inactive(C);
|
||||
async();
|
||||
step();
|
||||
delete(A1);
|
||||
inactive(C);
|
||||
step();
|
||||
message(A2,C,"ok");
|
||||
active(C);
|
||||
sync();
|
||||
step();
|
||||
active(C);
|
||||
message(C,C,"all done?");
|
||||
inactive(C);
|
||||
async();
|
||||
step();
|
||||
delete(A2);
|
||||
message(C,T,"beValid");
|
||||
inactive(C);
|
||||
active(T);
|
||||
step();
|
||||
|
||||
complete(T);
|
||||
complete(C);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following diagram, based on the diagram appearing on p. 70 of
|
||||
UML Distilled, contains self calls, object activation,
|
||||
self-deleted objects, and asynchronous messages.
|
||||
<h2>Diagram</h2>
|
||||
<img src="dist-52.gif" alt="UML Distilled: Concurrent processes and activations" />
|
||||
<h2>Diagram Source Code</h2>
|
||||
<fmtcode ext="pic">
|
||||
# UML Distilled: Figure 5-2 p. 70
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
boxwid = 1.3;
|
||||
|
||||
# Define the objects
|
||||
pobject(X);
|
||||
pobject(T);
|
||||
pobject(C);
|
||||
pobject(A1);
|
||||
pobject(A2);
|
||||
|
||||
# Message sequences
|
||||
cmessage(X,T,"a: Transaction");
|
||||
active(T);
|
||||
async();
|
||||
cmessage(T,C,"a: TransCoord");
|
||||
inactive(T);
|
||||
active(C);
|
||||
cmessage(C,A1,"a1: TransCheck");
|
||||
active(A1);
|
||||
cmessage(C,A2,"a2: TransCheck");
|
||||
active(A2);
|
||||
message(A1,C,"ok");
|
||||
sync();
|
||||
step();
|
||||
active(C);
|
||||
message(C,C,"all done?");
|
||||
inactive(C);
|
||||
async();
|
||||
step();
|
||||
delete(A1);
|
||||
inactive(C);
|
||||
step();
|
||||
message(A2,C,"ok");
|
||||
active(C);
|
||||
sync();
|
||||
step();
|
||||
active(C);
|
||||
message(C,C,"all done?");
|
||||
inactive(C);
|
||||
async();
|
||||
step();
|
||||
delete(A2);
|
||||
message(C,T,"beValid");
|
||||
inactive(C);
|
||||
active(T);
|
||||
step();
|
||||
|
||||
complete(T);
|
||||
complete(C);
|
||||
|
||||
.PE
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following diagram, illustrates the operating system calls of
|
||||
a typical DNS query.
|
||||
It will appear in the book
|
||||
<a href="http://www.spinellis.gr/codequality">Code Quality: The Open Source Perspective</a> (Addison-Wesley 2006).
|
||||
The diagram was the original motivation behind the UMLGraph sequence diagram
|
||||
drawing facility.
|
||||
<h2>Diagram</h2>
|
||||
<img src="dnsq.gif" alt="DNS Query Messages" />
|
||||
<h2>Diagram Source Code</h2>
|
||||
<fmtcode ext="pic">
|
||||
#/usr/bin/pic2plot -Tps
|
||||
#
|
||||
# Run as pic filename | groff | ps2eps
|
||||
#
|
||||
# DNS query collaboration diagram
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
boxwid = 1.3;
|
||||
|
||||
# Define the objects
|
||||
object(B,":Web Browser");
|
||||
object(W,":Workstation Kernel");
|
||||
object(S,":Server Kernel");
|
||||
object(D,":DNS Server");
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
active(B);
|
||||
active(D);
|
||||
active(W);
|
||||
active(S);
|
||||
message(D,S,"select");
|
||||
inactive(D);
|
||||
message(B,W,"socket");
|
||||
message(B,W,"connect");
|
||||
message(B,W,"sendto");
|
||||
message(W,W,"send packet");
|
||||
message(W,S,"DNS A query");
|
||||
message(B,W,"recvfrom");
|
||||
inactive(B);
|
||||
message(S,S,"receive packet");
|
||||
rmessage(S,D,"select returns");
|
||||
active(D);
|
||||
message(D,S,"recvfrom");
|
||||
message(D,S,"sendto");
|
||||
message(S,S,"send packet");
|
||||
message(S,W,"DNS A reply");
|
||||
message(W,W,"receive packet");
|
||||
rmessage(W,B,"recvfrom returns");
|
||||
active(B);
|
||||
message(B,W,"close");
|
||||
|
||||
complete(B);
|
||||
complete(W);
|
||||
complete(S);
|
||||
complete(D);
|
||||
|
||||
.PE
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
#/usr/bin/pic2plot -Tps
|
||||
#
|
||||
# Run as pic filename | groff | ps2eps
|
||||
#
|
||||
# DNS query collaboration diagram
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
boxwid = 1.3;
|
||||
|
||||
# Define the objects
|
||||
object(B,":Web Browser");
|
||||
object(W,":Workstation Kernel");
|
||||
object(S,":Server Kernel");
|
||||
object(D,":DNS Server");
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
active(B);
|
||||
active(D);
|
||||
active(W);
|
||||
active(S);
|
||||
message(D,S,"select");
|
||||
inactive(D);
|
||||
message(B,W,"socket");
|
||||
message(B,W,"connect");
|
||||
message(B,W,"sendto");
|
||||
message(W,W,"send packet");
|
||||
message(W,S,"DNS A query");
|
||||
message(B,W,"recvfrom");
|
||||
inactive(B);
|
||||
message(S,S,"receive packet");
|
||||
rmessage(S,D,"select returns");
|
||||
active(D);
|
||||
message(D,S,"recvfrom");
|
||||
message(D,S,"sendto");
|
||||
message(S,S,"send packet");
|
||||
message(S,W,"DNS A reply");
|
||||
message(W,W,"receive packet");
|
||||
rmessage(W,B,"recvfrom returns");
|
||||
active(B);
|
||||
message(B,W,"close");
|
||||
|
||||
complete(B);
|
||||
complete(W);
|
||||
complete(S);
|
||||
complete(D);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
|
||||
<!--
|
||||
To update the table of contents execute the following vim command from a register
|
||||
/^<h2>Contents
jjma/ul>
kmb/^$
"qyy:g/^<a name/s,<a name="\([^>]*\)><h2>\(.*\)</h2></a>,<li> <a href="\#\1>\2</a>,|y Q|u
'ad'b"qP
|
||||
-->
|
||||
|
||||
<h2>Contents</h2>
|
||||
<ul>
|
||||
|
||||
<li> <a href="#utfsvg">Why are the SVG diagrams dot generates malformed?</a>
|
||||
<li> <a href="#antialias">How can I improve the quality of the bitmap images I generate?</a>
|
||||
<li> <a href="#layout">How can I improve the layout of my class diagrams?</a>
|
||||
<li> <a href="#mclass">A class appears multiple times in a class diagram. Why?</a>
|
||||
<li> <a href="#static">Shouldn't static fields appear underlined?</a>
|
||||
<li> <a href="#winpic">Where can I find a <em>pic2plot</em> executable for Windows?</a>
|
||||
<li> <a href="#cr">Under Windows the output of <em>pic2plot</em> appears empty. Why?</a>
|
||||
<li> <a href="#maven">I have a problem with Maven's Dotuml plugin. Can you help me?</a>
|
||||
<li> <a href="#autopic">How can I make the UMLGraph doclet generate sequence diagrams?</a>
|
||||
<li> <a href="#packname">Why the vanity package name? Why not name the package org.umlgraph?</a>
|
||||
</ul>
|
||||
|
||||
<a name="utfsvg"><h2>Why are the SVG diagrams dot generates malformed?</h2></a>
|
||||
UMLGraph uses guillemot characters for representing the angle brackets around
|
||||
stereotypes, as in «interface».
|
||||
By default these are encoded as ISO-8859-1 characters, which are illegal
|
||||
in the UTF-8 output that dot generates for SVG.
|
||||
When using dot to generate SVG output, you should also specify
|
||||
<code>-outputencoding utf8</code> to UMLGraph.
|
||||
|
||||
<a name="antialias"><h2>How can I improve the quality of the bitmap images I generate?</h2></a>
|
||||
|
||||
Both
|
||||
<em>dot</em> and
|
||||
<em>pic2plot</em> can directly produce bitmap images in
|
||||
formats like GIF, PNG and PNM.
|
||||
However, if you want to produce presentation-quality output
|
||||
the a vector output format like Postscript or SVG is preferable.
|
||||
If you do require a bitmap format, it might be worth to create
|
||||
it at a higher resolution from a Postscript image, and then downsample it.
|
||||
This procedure (used for the diagrams appearing on the UMLGraph web site)
|
||||
will create an antialiased image of a higher quality than what the default
|
||||
bitmap output options produce.
|
||||
The following pipeline is an example of how you can achieve this
|
||||
effect:
|
||||
<fmtcode ext="sh">
|
||||
dot -Tps FILENAME.dot |
|
||||
gs -q -r360 -dNOPAUSE -sDEVICE=pnm -sOutputFile=- - -c quit |
|
||||
pnmcrop |
|
||||
pnmscale 0.25 |
|
||||
ppmtogif >FILENAME.gif
|
||||
</fmtcode>
|
||||
(David Griffiths reports that he had to add to the <em>gs</em> command
|
||||
<code>-sPAPERSIZE=a4</code> or
|
||||
<code>-dDEVICEHEIGHTPOINTS=1000</code> to avoid getting
|
||||
his resutls chopped-off.)
|
||||
|
||||
<p />
|
||||
One other possibility for converting the sequence diagram into Postscript
|
||||
is to pass it through <em>pic</em> and <em>groff</em>.
|
||||
Tools like <em>ps2epsi</em> and <em>ps2eps</em> can then be used to
|
||||
convert the Postscript into encapsulated Postscript.
|
||||
Of course, <em>groff</em> users will just use the <em>pic</em>
|
||||
program as part of their processing pipeline.
|
||||
|
||||
<a name="layout"><h2>How can I improve the layout of my class diagrams?</h2></a>
|
||||
Try manipulating the <em>dot</em> parameters ratio, minlen, ranksep, and
|
||||
nodesep.
|
||||
For example, Arnaud Rogues recommends running <em>dot</em> with
|
||||
command-line arguments as follows.
|
||||
<fmtcode ext="sh">
|
||||
dot -Gratio=0.7 -Eminlen=2
|
||||
</fmtcode>
|
||||
|
||||
<a name="mclass"><h2>A class appears multiple times in a class diagram. Why?</h2></a>
|
||||
Most probably your class diagram uses packages, and you are not
|
||||
qualifying the classes with the respective package names in the
|
||||
tags you use.
|
||||
The tags are not smart enough to do the package resolution,
|
||||
so you will have to prepend the package name to the class,
|
||||
or avoid using packages.
|
||||
<p />
|
||||
<h3>Problematic Specification</h3>
|
||||
<fmtcode ext="java">
|
||||
package test;
|
||||
abstract class AbstractNode {}
|
||||
/** @composed 1 has * AbstractNode */
|
||||
class InnerNode extends AbstractNode {}
|
||||
class Leaf extends AbstractNode {}
|
||||
</fmtcode>
|
||||
<h3>First Approach: Class Name Qualified with the Package</h3>
|
||||
<fmtcode ext="java">
|
||||
package test;
|
||||
abstract class AbstractNode {}
|
||||
/** @composed 1 has * test.AbstractNode */
|
||||
class InnerNode extends AbstractNode {}
|
||||
class Leaf extends AbstractNode {}
|
||||
</fmtcode>
|
||||
<h3>Second Approach: No Package Specification</h3>
|
||||
<fmtcode ext="java">
|
||||
abstract class AbstractNode {}
|
||||
/** @composed 1 has * test.AbstractNode */
|
||||
class InnerNode extends AbstractNode {}
|
||||
class Leaf extends AbstractNode {}
|
||||
</fmtcode>
|
||||
|
||||
<a name="static"><h2>Shouldn't static fields appear underlined?</h2></a>
|
||||
Yes they should.
|
||||
Unfortunately, <em>dot</em> does not (yet) support a way to underline
|
||||
single labels, and thus <em>UMLGraph</em> can not show the static fields
|
||||
underlined.
|
||||
|
||||
|
||||
<a name="winpic"><h2>Where can I find a <em>pic2plot</em> executable for Windows?</h2></a>
|
||||
A port of <em>pic2plot</em> for Windows can be found in
|
||||
GNU PlotUtils, which is part of the
|
||||
<a href="http://gnuwin32.sourceforge.net/packages.html">GnuWin32</a>
|
||||
project.
|
||||
|
||||
<a name="cr"><h2>Under Windows the output of <em>pic2plot</em> appears empty. Why?</h2></a>
|
||||
On Windows platforms note that the current version of
|
||||
<em>pic2plot</em> appears to be very picky about carriage return (CR - \r)
|
||||
characters (by default, CR is part of the platform's end of line sequence)
|
||||
appearing in its input file.
|
||||
Therefore, you will probably want to instruct your editor to create
|
||||
Unix-style files, or filter the files to remove the carriage return
|
||||
characters.
|
||||
The following Perl invocation is such a filter:
|
||||
<fmtcode ext="sh">
|
||||
perl -p -e "BEGIN {binmode(STDOUT);} s/\r//"
|
||||
</fmtcode>
|
||||
You can remove the CR characters in-place by running:
|
||||
<fmtcode ext="sh">
|
||||
perl -pi.bak -e "BEGIN {binmode(STDOUT);} s/\r//" FILENAME.pic
|
||||
</fmtcode>
|
||||
In addition, <em>pic2plot</em> appears to require that the last input file
|
||||
be properly terminated (with a newline).
|
||||
Apparently, some Windows editors may leave the last line unterminated,
|
||||
so if your editor is in this category it may be safer to add a blank line
|
||||
in the end.
|
||||
|
||||
<a name="maven"><h2>I have a problem with Maven's Dotuml plugin. Can you help me?</h2></a>
|
||||
Sorry, I did not develop this plugin, and therefore can not offer help.
|
||||
Have a look at the project's documentation and mailing lists available through
|
||||
<a href="http://maven-plugins.sourceforge.net/maven-dotuml-plugin/">plugin web page</a>.
|
||||
|
||||
<a name="autopic"><h2>How can I make the UMLGraph doclet generate sequence diagrams?</h2></a>
|
||||
You can't.
|
||||
You have to write the <em>pic</em> code for the sequence diagrams by hand.
|
||||
|
||||
<a name="packname"><h2>Why the vanity package name? Why not name the package org.umlgraph?</h2></a>
|
||||
The package names are supposed to be unique.
|
||||
If everybody names their project under the org.* namespace there's
|
||||
no mechanism for ensuring that the name will be unique,
|
||||
unless the developer also registers the corresponding domain name.
|
||||
Registering a different domain name for each project is not practical,
|
||||
therefore I name the packages I develop using the domain name I own.
|
||||
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
/*
|
||||
* Generalisation
|
||||
* UML User Guide p. 141
|
||||
* $Id$
|
||||
*/
|
||||
|
||||
/* Basic categorisations */
|
||||
class Asset {}
|
||||
class InterestBearingItem {}
|
||||
class InsurableItem {}
|
||||
|
||||
/* Asset types */
|
||||
/**
|
||||
* @extends InsurableItem
|
||||
* @extends InterestBearingItem
|
||||
*/
|
||||
class BankAccount extends Asset {}
|
||||
/** @extends InsurableItem */
|
||||
class RealEstate extends Asset {}
|
||||
class Security extends Asset {}
|
||||
|
||||
/* Securities */
|
||||
class Stock extends Security {}
|
||||
class Bond extends Security {}
|
||||
|
||||
/* Bank accounts */
|
||||
class CheckingAccount extends BankAccount {}
|
||||
class SavingsAccount extends BankAccount {}
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following sequence diagram demonstrates the use of the frame and comment elements.
|
||||
<h2>Diagram</h2>
|
||||
<img src="GUI-DB.gif" alt="Database GUI interface" />
|
||||
<h2>Diagram Source Code</h2>
|
||||
<fmtcode ext="pic">
|
||||
# usage-example for the comment extensions to the
|
||||
# Written by Sebastian Setzer
|
||||
|
||||
.PS
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
actor(U, "");
|
||||
object(G,"g:GUI");
|
||||
placeholder_object(Dummy1); # more space
|
||||
placeholder_object(D);
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
active(G);
|
||||
step();
|
||||
|
||||
create_message(G,D,"db:DB");
|
||||
active(D);
|
||||
step();
|
||||
inactive(D);
|
||||
|
||||
async(); # use asynchrone messages (not-filled arrowheads)
|
||||
|
||||
comment(D,C,down 1 right, wid 1 ht 0.7 "waiting for" "condition" "dbMailbox")
|
||||
|
||||
message(U,G,"openBrowser");
|
||||
message(G,D,"query()"); active(D);
|
||||
message(D,G,"result"); inactive(D);
|
||||
|
||||
connect_to_comment(D,C)
|
||||
|
||||
message(U,G,"scroll");
|
||||
message(G,D,"query()"); active(D);
|
||||
message(D,G,"result"); inactive(D);
|
||||
|
||||
connect_to_comment(D,C)
|
||||
|
||||
message(U,G,"Exit");
|
||||
step();
|
||||
begin_frame(G,F,"OnExit");
|
||||
message(G,D,"shutdown()"); inactive(G); active(D);
|
||||
comment(G,C,down .2 right .2, wid 2 ht 0.25 "wait for cond. dbShutdown")
|
||||
step();
|
||||
comment(D,C,right, wid 2 ht 1 \
|
||||
"all queries preceeding the" \
|
||||
"shutdown in the mailbox" \
|
||||
"are answered already." \
|
||||
"DbQuery-Objects can" \
|
||||
"be destroyed")
|
||||
message(D,G,"done"); inactive(D); active(G);
|
||||
|
||||
sync();
|
||||
destroy_message(G,D,"");
|
||||
|
||||
step();
|
||||
end_frame(D,F);
|
||||
|
||||
step();
|
||||
inactive(G);
|
||||
|
||||
# Complete the lifelines
|
||||
step();
|
||||
complete(G);
|
||||
complete(U);
|
||||
.PE
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<index>
|
||||
<ch><ti>Introduction</ti><fi>intro</fi></ch>
|
||||
<ch><ti>Class Diagrams</ti><fi>cd-intro</fi></ch>
|
||||
<ch><ti>Class Diagram Operations</ti><fi>cd-oper</fi></ch>
|
||||
<ch><ti>Class Modelling</ti><fi>cd-model</fi></ch>
|
||||
<ch><ti>Class Diagram Options</ti><fi>cd-opt</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Generalisation Relationships</ti><fi>ceg-gen</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Advanced Relationships</ti><fi>ceg-adv</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Schema</ti><fi>ceg-schema</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Element Visibility</ti><fi>ceg-ev</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Association Types</ti><fi>ceg-at</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Real Example (Catalina Classes)</ti><fi>ceg-cat</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Class Stereotypes and Tagged Values</ti><fi>ceg-ster</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Colors, Global and Local Options</ti><fi>ceg-color</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Multiple Views</ti><fi>ceg-mv</fi></ch>
|
||||
<ch><ti>Sequence Diagrams</ti><fi>seq-intro</fi></ch>
|
||||
<ch><ti>Syntax of Sequence Diagram Definitions</ti><fi>seq-syntax</fi></ch>
|
||||
<ch><ti>Defining a Simple Sequence Diagram</ti><fi>seq-simple</fi></ch>
|
||||
<ch><ti>An Improved Sequence Diagram</ti><fi>seq-impr</fi></ch>
|
||||
<ch><ti>Creating and Destroying Objects</ti><fi>seq-cd</fi></ch>
|
||||
<ch><ti>Sequence Diagram Operations</ti><fi>seq-ops</fi></ch>
|
||||
<ch><ti>Sequence Diagram Variables</ti><fi>seq-var</fi></ch>
|
||||
<ch><ti>Sequence Diagram Example: Nested Activation and Complex Interactions</ti><fi>uml-appa</fi></ch>
|
||||
<ch><ti>Sequence Diagram Example: Concurrent Processes and Activations</ti><fi>dist-52</fi></ch>
|
||||
<ch><ti>Sequence Diagram Example: Create and Destroy</ti><fi>uml-182</fi></ch>
|
||||
<ch><ti>Sequence Diagram Example: Lifeline Constraints</ti><fi>uml-184</fi></ch>
|
||||
<ch><ti>Sequence Diagram Example: External Actor</ti><fi>uml-71</fi></ch>
|
||||
<ch><ti>Sequence Diagram Example: A DNS Query</ti><fi>dns</fi></ch>
|
||||
<ch><ti>Sequence Diagram Example: A Comments and Frames</ti><fi>gui-db</fi></ch>
|
||||
<ch><ti>Frequently Asked Questions</ti><fi>faq</fi></ch>
|
||||
<ch><ti>Bibliography</ti><fi>bib</fi></ch>
|
||||
<ch><ti>Version History</ti><fi>ver</fi></ch>
|
||||
<ch><ti>Acknowledgements</ti><fi>ack</fi></ch>
|
||||
</index>
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
UMLGraph allows the declarative specification and drawing of
|
||||
UML class and sequence diagrams.
|
||||
The specification is done in text diagrams, that are then
|
||||
transformed into the appropriate graphical representations.
|
||||
<p />
|
||||
There is no rule specifying that models should appear in a graphical
|
||||
form. A model is a simplification of reality, so a model for a software
|
||||
artifact could really be an outline of that artifact; think of a class
|
||||
definition without code in the method bodies. However, we usually
|
||||
prefer to examine many of our models in a graphical representation: UML
|
||||
employs ten different diagrams for visualizing different perspectives
|
||||
of a system.
|
||||
<p />
|
||||
Designers typically create their model diagrams using a drawing editor.
|
||||
However, all drawing editors require the tedious placing and manipulation of drawing shapes on the canvas. The effort and the motor coordination skills required for this activity are mostly irrelevant to the end result: unlike architectural or mechanical engineering models the appearance of a software system's model diagram is only marginally related to the quality of the represented software design.
|
||||
<p />
|
||||
Computer power and automatic graph drawing algorithms have now
|
||||
sufficiently advanced so as to allow the automatic placement of graph
|
||||
nodes on the canvas and the near optimal routing of the respective
|
||||
edges. We can therefore design models using a declarative textual
|
||||
representation and subsequently view, publish, and share them in
|
||||
graphical form.
|
||||
UMLGraph's support for
|
||||
declaratively specifying class and sequence diagrams
|
||||
is part of an ongoing effort aiming to support all ten types of UML diagrams.
|
||||
<p />
|
||||
Creating models in a declarative, textual notation offers a number of advantages.
|
||||
<ul>
|
||||
<li> First of all, the model composition mechanism matches well both a programmer's high-level skills, the textual abstract formalization of concrete concepts, and the associated low-level skills, the manipulation of text using an editor and other text-based tools.</li>
|
||||
<li> The declarative notation, by being closer to the program's representation (the notation I experimented with is based on the Java syntax and semantics), forces the designer to distinguish between the model and the respective implementation, between the essential system characteristics and the trivial adornments.
|
||||
It is more difficult for designers to get away, as they often do now, with drawing for a model a nice picture of the implementation they have in mind.</li>
|
||||
<li> The declarative representation is also highly malleable, the existing visual structure does not hinder drastic changes, nor is effort wasted on the tidy arrangement of graph nodes a psychological barrier against massive design refactoring.</li>
|
||||
<li> Declarative models are also highly automatable: they can be easily generated from even higher-level descriptions by trivial scripts and tools operating on design process inputs such as database schemas, existing code, or structured requirements documents.</li>
|
||||
<li> Text macro processors can be used for configuration management, while revision control and team integration activities can utilize the same proven tools and processes that are currently used for managing source code.
|
||||
Thus with a tool like CVS or RCS one can keep track of design revisions, create and merge branches, and monitor model changes, while a system like CVS can allow work to be split into teams.</li>
|
||||
<li> Finally, the declarative approach can readily utilize existing text processing tools for tasks that a drawing editor system may not provide.</li>
|
||||
</ul>
|
||||
Consider how your favorite model editor handles the following tasks and how you could handle them using a simple Perl script or a text-processing pipeline applied to the declarative model specification:
|
||||
<ul>
|
||||
<li>identify all classes containing a given field (as a prelude to an aspect-oriented cross-cut);</li>
|
||||
<li>count the total number of private fields in a given design;</li>
|
||||
<li>order methods appearing in multiple classes by their degree of commonality;</li>
|
||||
<li>identify differences between two designs.</li>
|
||||
</ul>
|
||||
All the above tasks can be easily performed in text files using Unix commands
|
||||
such as
|
||||
<em>grep</em>,
|
||||
<em>wc</em>,
|
||||
<em>grep ... | sort ...</em>, and
|
||||
<em>diff</em>.
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
/*
|
||||
* Schema model
|
||||
* UML User Guide p. 112
|
||||
* $Id$
|
||||
*/
|
||||
|
||||
/**
|
||||
* @opt operations
|
||||
* @opt attributes
|
||||
* @opt types
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/* Define some types we use */
|
||||
/** @hidden */
|
||||
class Name {}
|
||||
/** @hidden */
|
||||
class Number {}
|
||||
|
||||
/**
|
||||
* @has 1..* Member * Student
|
||||
* @composed 1..* Has 1..* Department
|
||||
*/
|
||||
class School {
|
||||
Name name;
|
||||
String address;
|
||||
Number phone;
|
||||
void addStudent() {}
|
||||
void removeStudent() {}
|
||||
void getStudent() {}
|
||||
void getAllStudents() {}
|
||||
void addDepartment() {}
|
||||
void removeDepartment() {}
|
||||
void getDepartment() {}
|
||||
void getAllDepartments() {}
|
||||
}
|
||||
|
||||
/**
|
||||
* @has 1..* AssignedTo 1..* Instructor
|
||||
* @assoc 1..* - 1..* Course
|
||||
* @assoc 0..* - "0..1 chairperson" Instructor
|
||||
*/
|
||||
class Department {
|
||||
Name name;
|
||||
void addInstructor() {}
|
||||
void removeInstructor() {}
|
||||
void getInstructor() {}
|
||||
void getAllInstructors() {}
|
||||
}
|
||||
|
||||
/**
|
||||
* @assoc * Attends * Course
|
||||
*/
|
||||
class Student {
|
||||
Name name;
|
||||
Number studentID;
|
||||
}
|
||||
|
||||
class Course {
|
||||
Name name;
|
||||
Number courseID;
|
||||
}
|
||||
|
||||
/**
|
||||
* @assoc 1..* Teaches * Course
|
||||
*/
|
||||
class Instructor {
|
||||
Name name;
|
||||
}
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
#
|
||||
# $Id$
|
||||
#
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
object(S,"s:Switch");
|
||||
object(P,"p:Pump");
|
||||
placeholder_object(F);
|
||||
step();
|
||||
active(S);
|
||||
active(P);
|
||||
|
||||
# Message sequences
|
||||
message(S,P,"run()");
|
||||
create_message(P,F,"f:Flow");
|
||||
active(F);
|
||||
message(S,P,"stop()");
|
||||
destroy_message(P,F);
|
||||
|
||||
step();
|
||||
complete(S);
|
||||
complete(P);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
Objects do not always appear at the top of a UML sequence diagram;
|
||||
they are often constructed by other objects.
|
||||
In this case, a placeholder object is defined at the beginning
|
||||
of the diagram, to leave the appropriate space of the object.
|
||||
Later a create message will actually create an object with the
|
||||
given label.
|
||||
Any object can also receive a destroy message, that will stop
|
||||
its life.
|
||||
The lifeline of destroyed messages is not typically completed.
|
||||
<p />
|
||||
The following definition extends our previous diagram with a
|
||||
dynamically created flow object.
|
||||
<fmtcode ext="pic">
|
||||
# Define the objects
|
||||
object(S,"s:Switch");
|
||||
object(P,"p:Pump");
|
||||
placeholder_object(F);
|
||||
step();
|
||||
active(S);
|
||||
active(P);
|
||||
|
||||
# Message sequences
|
||||
message(S,P,"run()");
|
||||
create_message(P,F,"f:Flow");
|
||||
active(F);
|
||||
message(S,P,"stop()");
|
||||
destroy_message(P,F);
|
||||
|
||||
# Object completion
|
||||
step();
|
||||
complete(S);
|
||||
complete(P);
|
||||
</fmtcode>
|
||||
<p />
|
||||
The resultant diagram is<br />
|
||||
<img src="seq-cd.gif" alt="Sequence diagram with object construction and destruiction" />
|
||||
<p />
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
# UML User Guide: Appendix A,p. 436
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
object(O,"o:Toolkit");
|
||||
placeholder_object(P);
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
active(O);
|
||||
step();
|
||||
active(O);
|
||||
message(O,O,"callbackLoop()");
|
||||
inactive(O);
|
||||
create_message(O,P,"p:Peer");
|
||||
message(O,P,"handleExpose()");
|
||||
active(P);
|
||||
return_message(P,O,"");
|
||||
inactive(P);
|
||||
destroy_message(O,P);
|
||||
inactive(O);
|
||||
|
||||
# Complete the lifelines
|
||||
step();
|
||||
complete(O);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
#
|
||||
# $Id$
|
||||
#
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
object(S,"s:Switch");
|
||||
object(P,"p:Pump");
|
||||
step();
|
||||
active(S);
|
||||
active(P);
|
||||
|
||||
# Message sequences
|
||||
message(S,P,"run()");
|
||||
message(S,P,"stop()");
|
||||
|
||||
step();
|
||||
complete(S);
|
||||
complete(P);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
Let us try to improve the simple sequence diagram.
|
||||
<fmtcode ext="pic">
|
||||
# Object definition
|
||||
object(S,"s:Switch");
|
||||
object(P,"p:Pump");
|
||||
step();
|
||||
active(S);
|
||||
active(P);
|
||||
|
||||
# Message exchange
|
||||
message(S,P,"run()");
|
||||
message(S,P,"stop()");
|
||||
|
||||
# Object lifeline completion
|
||||
step();
|
||||
complete(S);
|
||||
complete(P);
|
||||
</fmtcode>
|
||||
Here, we have manually advanced the timeline of our diagrams
|
||||
with a <code>step();</code> call after we defined the objects,
|
||||
to provide them with a bit of breathing space.
|
||||
We also added a similar step call at the end of the diagram.
|
||||
Finally, we made both objects active, after their definition.
|
||||
Calling active on a given object will change the drawing of its
|
||||
lifeline, from the dashed format indicating an inactive object,
|
||||
to a thick swimming-lane, active object, format.
|
||||
<p />
|
||||
The resultant diagram is<br />
|
||||
<img src="seq-impr.gif" alt="Improved sequence diagram" />
|
||||
<p />
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
One specifies a sequence diagram using <em>pic</em> macros to define
|
||||
objects and method invocations.
|
||||
The <a href="http://www.gnu.org/software/plotutils/plotutils.html">GNU plotutils</a>
|
||||
<em>pic2plot</em> program can then process the sequence diagram to create a
|
||||
PNG, PNM, (pseudo)GIF, SVG, AI, Postscript, CGM, FIG, PCL, HPGL, Regis, or TEK
|
||||
drawing.
|
||||
<p />
|
||||
The following is an example of a specification and the resulting UML sequence
|
||||
diagram:
|
||||
<table>
|
||||
<tr><td>
|
||||
<fmtcode ext="pic">
|
||||
.PS
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
object(O,"o:Toolkit");
|
||||
placeholder_object(P);
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
active(O);
|
||||
step();
|
||||
active(O);
|
||||
message(O,O,"callbackLoop()");
|
||||
inactive(O);
|
||||
create_message(O,P,"p:Peer");
|
||||
message(O,P,"handleExpose()");
|
||||
active(P);
|
||||
return_message(P,O,"");
|
||||
inactive(P);
|
||||
destroy_message(O,P);
|
||||
inactive(O);
|
||||
|
||||
# Complete the lifelines
|
||||
step();
|
||||
complete(O);
|
||||
.PE
|
||||
</fmtcode>
|
||||
</td><td>
|
||||
<img src="seq-eg.gif" alt="Simple UML sequence diagram" />
|
||||
</td></tr></table>
|
||||
The diagram is drawn from its source code specification using a command
|
||||
like:
|
||||
<fmtcode ext="sh">
|
||||
pictplot -Tgif FILENAME.pic >FILENAME.gif
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following calls can be used to define a sequence diagram.
|
||||
<dl>
|
||||
<dt>object(name,label);</dt>
|
||||
<dd>Defines an object with the given name, labeled on the diagram
|
||||
as specified.</dd>
|
||||
<dt>placeholder_object(name)</dt>
|
||||
<dd>Defines a place where the named object will later be
|
||||
created.
|
||||
Can also be written as <code>pobject</code>.
|
||||
</dd>
|
||||
<dt>actor(name,label);</dt>
|
||||
<dd>Defines an actor with the given name, labeled on the diagram
|
||||
as specified.
|
||||
Actors are typically used instead of objects to indicate operations
|
||||
initiated by human actions. </dd>
|
||||
<dt>complete(name);</dt>
|
||||
<dd>Completes the lifeline of a given object (or actor)
|
||||
by drawing its lifeline to the bottom of the diagram.</dd>
|
||||
<dt>message(from_object,to_object,label)</dt>
|
||||
<dd>Draws a message between two objects, with the given label.
|
||||
Self messages (where an objects sends a message to itself)
|
||||
are supported.
|
||||
</dd>
|
||||
<dt>return_message(from_object,to_object,label)</dt>
|
||||
<dd>Draws a return message between two objects, with the given label.
|
||||
Can also be written as <code>rmessage</code>.
|
||||
</dd>
|
||||
<dt>create_message(from_object,to_object,object_label);</dt>
|
||||
<dd>Has from_object create the to_object, labeled
|
||||
with object_label.
|
||||
The message is labeled with the <code>«create»</code> stereotype.
|
||||
Can also be written as <code>cmessage</code>.
|
||||
</dd>
|
||||
<dt>destroy_message(from_object,to_object);</dt>
|
||||
<dd>Sends a message
|
||||
labeled with the <code>«destroy»</code> stereotype
|
||||
from the from_object to the to_object.
|
||||
The object to_object is marked as destroyed, with an X at the
|
||||
end of its lifeline.
|
||||
The object's lifeline need not be otherwise completed.
|
||||
Can also be written as <code>dmessage</code>.
|
||||
</dd>
|
||||
<dt>active(object);</dt>
|
||||
<dd>Changes the object's status to active, and
|
||||
changes its lifeline drawing style correspondingly.
|
||||
An active call in an already active object will result
|
||||
in a swimlane showing a nested object activation.</dd>
|
||||
<dt>inactive(object);</dt>
|
||||
<dd>Changes the object's status to inactive, and
|
||||
changes its lifeline drawing style correspondingly.
|
||||
An inactive call on a nested object invocation will
|
||||
result in showing a simple active swimlane.</dd>
|
||||
<dt>delete(object);</dt>
|
||||
<dd>The object deletes itself, drawing an X at the end
|
||||
of its lifeline.
|
||||
The object's lifeline need not be otherwise completed.
|
||||
</dd>
|
||||
<dt>lifeline_constraint(object,label);</dt>
|
||||
<dd>Displays a constraint label (typically given inside curly braces)
|
||||
for the given object.
|
||||
The constraint will appear on the right of the object's lifeline
|
||||
at the time it appears.
|
||||
Can also be used to place an message label on the left of a
|
||||
message arrow, rather than its center.
|
||||
Can also be written as <code>lconstraint</code>.
|
||||
</dd>
|
||||
<dt>lconstraint_below(object,label);</dt>
|
||||
<dd>same as <code>lconstraint</code>,
|
||||
but it will be shown below the current line instead of above.
|
||||
</dd>
|
||||
<dt>object_constraint(label)</dt>
|
||||
<dd>Displays an object constraint (typically given inside curly braces)
|
||||
for the last object defined.
|
||||
Can also be written as <code>oconstraint</code>.
|
||||
</dd>
|
||||
<dt>step();</dt>
|
||||
<dd>Steps the time by a single increment, extending all
|
||||
lifelines.</dd>
|
||||
<dt>async();</dt>
|
||||
<dd>All subsequent messages are asynchronous and will
|
||||
be drawn correspondingly.</dd>
|
||||
<dt>sync();</dt>
|
||||
<dd>All subsequent messages are synchronous and will
|
||||
be drawn correspondingly.</dd>
|
||||
<dt>begin_frame(left_object,name,label_text);</dt>
|
||||
<dd>Begins a frame with the upper left corner at
|
||||
<code>left_object</code> column and the current line.
|
||||
The specified <code>label_text</code> is shown in the upper left corner.
|
||||
</dd>
|
||||
<dt>end_frame(right_object,name);</dt>
|
||||
<dd>Ends a frame with the lower right corner at
|
||||
<code>right_object</code> column and the current line.
|
||||
The name must correspond to a <code>begin_frame</code>'s name.
|
||||
</dd>
|
||||
<dt>comment(object,[name],[line_movement],[box_size] text);</dt>
|
||||
<dd>Displays a comment about the object.
|
||||
The name can be used with
|
||||
<code>connect_to_comment(object2,name);</code> to get additional
|
||||
connecting lines to the comment.
|
||||
<code>line_movement</code> changes the position of the comment and
|
||||
<code>box_size</code> its size. Note that there's no comma between
|
||||
<code>box_size</code> and <code>text</code>.
|
||||
<code>text</code> is the (multiline) comment-text that will be displayed.
|
||||
<code>name</code>, <code>line_movement</code> and <code>box_size</code> are optional
|
||||
(but the commas must still appear).
|
||||
</dd>
|
||||
<dt>connect_to_comment(object2,name);</dt>
|
||||
<dd>See <code>comment</code>.
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
</notes>
|
||||
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
#
|
||||
# $Id$
|
||||
#
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
object(S,"s:Switch");
|
||||
object(P,"p:Pump");
|
||||
|
||||
# Message sequences
|
||||
message(S,P,"run()");
|
||||
message(S,P,"stop()");
|
||||
|
||||
complete(S);
|
||||
complete(P);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
A sequence diagram is defined in three main phases:
|
||||
<ol>
|
||||
<li> Object definition </li>
|
||||
<li> Message exchange </li>
|
||||
<li> Object lifeline completion</li>
|
||||
</ol>
|
||||
The following is an example of a very simple UMLGraph
|
||||
sequence diagram
|
||||
(from now on we will ommit the <code>.PS/.PE</code> and
|
||||
<code>copy "sequence.pic";</code>
|
||||
elements.)
|
||||
<fmtcode ext="pic">
|
||||
.PS
|
||||
copy "sequence.pic";
|
||||
|
||||
# Object definition
|
||||
object(S,"s:Switch");
|
||||
object(P,"p:Pump");
|
||||
|
||||
# Message exchange
|
||||
message(S,P,"run()");
|
||||
message(S,P,"stop()");
|
||||
|
||||
# Object lifeline completion
|
||||
complete(S);
|
||||
complete(P);
|
||||
|
||||
.PE
|
||||
</fmtcode>
|
||||
The above code, defines two objects, S and P,
|
||||
labeled as "s:Switch" and "p:Pump".
|
||||
Objects are placed in the diagram from left to right, in the
|
||||
order they are defined.
|
||||
All defined objects are initially inactive.
|
||||
<p />
|
||||
The code then sends a messages from S to P labeled "run()",
|
||||
and another one labeled "stop()".
|
||||
Each message automatically advances the sequence diagram timeline by a
|
||||
single step.
|
||||
<p />
|
||||
Finally, the code completes the lifelines of the two objects.
|
||||
<p />
|
||||
The resultant diagram is<br />
|
||||
<img src="seq-simple.gif" alt="Simple sequence diagram" />
|
||||
<p />
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
Sequence diagrams consist of objects, their lifelines
|
||||
(also known as smimming lanes),
|
||||
and the exchanged messages.
|
||||
Sequence diagrams are defined in UMLGraph using the <em>pic</em>
|
||||
syntax.
|
||||
<p />
|
||||
A sequence diagram file must start with the sequence:
|
||||
<fmtcode ext="pic">
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
</fmtcode>
|
||||
The <code>.PS</code> marks the beginning of <em>pic</em> commands.
|
||||
The sequence
|
||||
<code>copy "sequence.pic";</code>
|
||||
loads the macros defining the sequence diagram operations.
|
||||
The file <code>sequence.pic</code>, part of the UMLGraph distribution,
|
||||
must exist in the directory where <em>pic2plot</em> will be executed.
|
||||
<p />
|
||||
Sequence diagram files must end with the sequence:
|
||||
<fmtcode ext="pic">
|
||||
.PE
|
||||
</fmtcode>
|
||||
<p />
|
||||
The sequence diagrams are defined by calling function-like <em>pic</em>
|
||||
macros.
|
||||
Each function call is terminated with a semicolon.
|
||||
Space is not significant between macro calls; on the other hand
|
||||
adding a space character between a macro's arguments can lead
|
||||
to surprises and should be avoided.
|
||||
Objects are referenced using variable-like alphanumeric identifiers.
|
||||
Strings are enclosed in double quotes.
|
||||
<p />
|
||||
As an example, the following defines an object <code>O</code>
|
||||
that will be identified in the diagram as
|
||||
<code>o:Toolkit</code>
|
||||
<fmtcode ext="pic">
|
||||
object(O,"o:Toolkit");
|
||||
</fmtcode>
|
||||
<p />
|
||||
Comments start with a <code>#</code> character.
|
||||
<fmtcode ext="pic">
|
||||
# This is a comment
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The value of
|
||||
<em>pic</em> variables can sometimes be modified by assignment
|
||||
to achieve a better-looking result.
|
||||
The following two lines change the width of the object boxes to
|
||||
1.1" and the spacing between objects
|
||||
to 0.5".
|
||||
<fmtcode ext="pic">
|
||||
boxwid = 1.1;
|
||||
movewid = 0.5;
|
||||
</fmtcode>
|
||||
The following variables can be redefined to change the layout of
|
||||
a drawing.
|
||||
<p />
|
||||
<table border = "1">
|
||||
<tr><th>Variable Name</th><th>Default Value</th><th>Operation</th></tr>
|
||||
<tr><td>boxht</td><td>0.3</td><td>Object box height</td></tr>
|
||||
<tr><td>boxwid</td><td>0.75</td><td>Object box width</td></tr>
|
||||
<tr><td>awid</td><td>0.1</td><td>Active lifeline width</td></tr>
|
||||
<tr><td>spacing</td><td>0.25</td><td>Spacing between messages</td></tr>
|
||||
<tr><td>movewid</td><td>0.75</td><td>Spacing between objects</td></tr>
|
||||
<tr><td>dashwid</td><td>0.05</td><td>Interval for dashed lines</td></tr>
|
||||
<tr><td>maxpswid</td><td>11</td><td>Maximum width of picture</td></tr>
|
||||
<tr><td>maxpsht</td><td>11</td><td>Maximum height of picture</td></tr>
|
||||
</table>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,406 @@
|
|||
#/usr/bin/pic2plot -Tps
|
||||
#
|
||||
# Pic macros for drawing UML sequence diagrams
|
||||
#
|
||||
# (C) Copyright 2004-2005 Diomidis Spinellis.
|
||||
#
|
||||
# Permission to use, copy, and distribute this software and its
|
||||
# documentation for any purpose and without fee is hereby granted,
|
||||
# provided that the above copyright notice appear in all copies and that
|
||||
# both that copyright notice and this permission notice appear in
|
||||
# supporting documentation.
|
||||
#
|
||||
# THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
|
||||
# WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
|
||||
# MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
|
||||
# Default parameters (can be redefined)
|
||||
|
||||
# Spacing between messages
|
||||
spacing = 0.25;
|
||||
# Active box width
|
||||
awid = .1;
|
||||
# Box height
|
||||
boxht = 0.3;
|
||||
# Commend folding
|
||||
corner_fold=awid
|
||||
# Comment distance
|
||||
define comment_default_move {up 0.25 right 0.25};
|
||||
# Comment height
|
||||
comment_default_ht=0.5;
|
||||
# Comment width
|
||||
comment_default_wid=1;
|
||||
|
||||
|
||||
# Create a new object(name,label)
|
||||
define object {
|
||||
$1: box $2; move;
|
||||
# Could also underline text with \mk\ul\ul\ul...\rt
|
||||
{
|
||||
line from $1.w + (.1, -.07) to $1.e + (-.1, -.07);
|
||||
}
|
||||
move to $1.e;
|
||||
move right;
|
||||
# Active is the level of activations of the object
|
||||
# 0 : inactive : draw thin line swimlane
|
||||
# 1 : active : draw thick swimlane
|
||||
# > 1: nested : draw nested swimlane
|
||||
active_$1 = 0;
|
||||
lifestart_$1 = $1.s.y;
|
||||
}
|
||||
|
||||
# Create a new external actor(name,label)
|
||||
define actor {
|
||||
$1: [
|
||||
XSEQC: circle rad 0.06;
|
||||
XSEQL: line from XSEQC.s down .12;
|
||||
line from XSEQL.start - (.15,.02) to XSEQL.start + (.15,-.02);
|
||||
XSEQL1: line from XSEQL.end left .08 down .15;
|
||||
XSEQL2: line from XSEQL.end right .08 down .15;
|
||||
line at XSEQC.n invis "" "" "" $2;
|
||||
]
|
||||
move to $1.e;
|
||||
move right;
|
||||
active_$1 = 0;
|
||||
lifestart_$1 = $1.s.y - .05;
|
||||
}
|
||||
|
||||
# Create a new placeholder object(name)
|
||||
define placeholder_object {
|
||||
$1: box invisible;
|
||||
move;
|
||||
move to $1.e;
|
||||
move right;
|
||||
active_$1 = 0;
|
||||
lifestart_$1 = $1.s.y;
|
||||
}
|
||||
|
||||
define pobject {
|
||||
placeholder_object($1);
|
||||
}
|
||||
|
||||
define extend_lifeline {
|
||||
if (active_$1 > 0) then {
|
||||
# draw the left edges of the boxes
|
||||
move to ($1.x - awid/2, Here.y);
|
||||
for level = 1 to active_$1 do {
|
||||
line from (Here.x, lifestart_$1) to Here;
|
||||
move right awid/2
|
||||
}
|
||||
|
||||
# draw the right edge of the innermost box
|
||||
move right awid/2;
|
||||
line from (Here.x, lifestart_$1) to Here;
|
||||
} else {
|
||||
line from ($1.x, lifestart_$1) to ($1.x, Here.y) dashed;
|
||||
}
|
||||
lifestart_$1 = Here.y;
|
||||
}
|
||||
|
||||
# complete(name)
|
||||
# Complete the lifeline of the object with the given name
|
||||
define complete {
|
||||
extend_lifeline($1)
|
||||
if (active_$1) then {
|
||||
# draw bottom of all active boxes
|
||||
line right ((active_$1 + 1) * awid/2) from ($1.x - awid/2, Here.y);
|
||||
}
|
||||
}
|
||||
|
||||
# Draw a message(from_object,to_object,label)
|
||||
define message {
|
||||
down;
|
||||
move spacing;
|
||||
# Adjust so that lines and arrows do not fall into the
|
||||
# active box. Should be .5, but the arrow heads tend to
|
||||
# overshoot.
|
||||
if ($1.x <= $2.x) then {
|
||||
off_from = awid * .6;
|
||||
off_to = -awid * .6;
|
||||
} else {
|
||||
off_from = -awid * .6;
|
||||
off_to = awid * .6;
|
||||
}
|
||||
|
||||
# add half a box width for each level of nesting
|
||||
if (active_$1 > 1) then {
|
||||
off_from = off_from + (active_$1 - 1) * awid/2;
|
||||
}
|
||||
|
||||
# add half a box width for each level of nesting
|
||||
if (active_$2 > 1) then {
|
||||
off_to = off_to + (active_$2 - 1) * awid/2;
|
||||
}
|
||||
|
||||
if ($1.x == $2.x) then {
|
||||
arrow from ($1.x + off_from, Here.y) right then down .25 then left $3 ljust " " " " " " ;
|
||||
} else {
|
||||
arrow from ($1.x + off_from, Here.y) to ($2.x + off_to, Here.y) $3 " ";
|
||||
}
|
||||
}
|
||||
|
||||
# Display a lifeline constraint(object,label)
|
||||
define lifeline_constraint {
|
||||
off_from = awid;
|
||||
# add half a box width for each level of nesting
|
||||
if (active_$1 > 1) then {
|
||||
off_from = off_from + (active_$1 - 1) * awid/2;
|
||||
}
|
||||
|
||||
box at ($1.x + off_from, Here.y) invis $2 ljust " " ;
|
||||
}
|
||||
|
||||
define lconstraint {
|
||||
lifeline_constraint($1,$2);
|
||||
}
|
||||
|
||||
# Display an object constraint(label)
|
||||
# for the last object drawn
|
||||
define object_constraint {
|
||||
{ box invis with .s at last box .nw $1 ljust; }
|
||||
}
|
||||
|
||||
define oconstraint {
|
||||
object_constraint($1);
|
||||
}
|
||||
|
||||
# Draw a creation message(from_object,to_object,object_label)
|
||||
define create_message {
|
||||
down;
|
||||
move spacing;
|
||||
if ($1.x <= $2.x) then {
|
||||
off_from = awid * .6;
|
||||
off_to = -boxwid * .51;
|
||||
} else {
|
||||
off_from = -awid * .6;
|
||||
off_to = boxwid * .51;
|
||||
}
|
||||
|
||||
# add half a box width for each level of nesting
|
||||
if (active_$1 > 1) then {
|
||||
off_from = off_from + (active_$1 - 1) * awid/2;
|
||||
}
|
||||
|
||||
# See comment in destroy_message
|
||||
XSEQA: arrow from ($1.x + off_from, Here.y) to ($2.x + off_to, Here.y) "«create»" " ";
|
||||
if ($1.x <= $2.x) then {
|
||||
{ XSEQB: box $3 with .w at XSEQA.end; }
|
||||
} else {
|
||||
{ XSEQB: box $3 with .e at XSEQA.end; }
|
||||
}
|
||||
{
|
||||
line from XSEQB.w + (.1, -.07) to XSEQB.e + (-.1, -.07);
|
||||
}
|
||||
lifestart_$2 = XSEQB.s.y;
|
||||
move (spacing + boxht) / 2;
|
||||
}
|
||||
|
||||
define cmessage {
|
||||
create_message($1,$2,$3);
|
||||
}
|
||||
|
||||
# Draw an X for a given object
|
||||
define drawx {
|
||||
{
|
||||
line from($1.x - awid, lifestart_$1 - awid) to ($1.x + awid, lifestart_$1 + awid);
|
||||
line from($1.x - awid, lifestart_$1 + awid) to ($1.x + awid, lifestart_$1 - awid);
|
||||
}
|
||||
}
|
||||
|
||||
# Draw a destroy message(from_object,to_object)
|
||||
define destroy_message {
|
||||
down;
|
||||
move spacing;
|
||||
# The troff code is \(Fo \(Fc
|
||||
# The groff code is also \[Fo] \[Fc]
|
||||
# The pic2plot code is \Fo \Fc
|
||||
# See http://www.delorie.com/gnu/docs/plotutils/plotutils_71.html
|
||||
# To stay compatible with all we have to hardcode the characters
|
||||
message($1,$2,"«destroy»");
|
||||
complete($2);
|
||||
drawx($2);
|
||||
}
|
||||
|
||||
define dmessage {
|
||||
destroy_message($1,$2);
|
||||
}
|
||||
|
||||
# An object deletes itself: delete(object)
|
||||
define delete {
|
||||
complete($1);
|
||||
lifestart_$1 = lifestart_$1 - awid;
|
||||
drawx($1);
|
||||
}
|
||||
|
||||
# Draw a message return(from_object,to_object,label)
|
||||
define return_message {
|
||||
down;
|
||||
move spacing;
|
||||
# See comment in message
|
||||
if ($1.x <= $2.x) then {
|
||||
off_from = awid * .6;
|
||||
off_to = -awid * .6;
|
||||
} else {
|
||||
off_from = -awid * .6;
|
||||
off_to = awid * .6;
|
||||
}
|
||||
|
||||
# add half a box width for each level of nesting
|
||||
if (active_$1 > 1) then {
|
||||
off_from = off_from + (active_$1 - 1) * awid/2;
|
||||
}
|
||||
|
||||
# add half a box width for each level of nesting
|
||||
if (active_$2 > 1) then {
|
||||
off_to = off_to + (active_$2 - 1) * awid/2;
|
||||
}
|
||||
|
||||
arrow from ($1.x + off_from, Here.y) to ($2.x + off_to, Here.y) dashed $3 " ";
|
||||
}
|
||||
|
||||
define rmessage {
|
||||
return_message($1,$2,$3);
|
||||
}
|
||||
|
||||
# Object becomes active
|
||||
# Can be nested to show recursion
|
||||
define active {
|
||||
extend_lifeline($1);
|
||||
# draw top of new active box
|
||||
line right awid from ($1.x + (active_$1 - 1) * awid/2, Here.y);
|
||||
active_$1 = active_$1 + 1;
|
||||
}
|
||||
|
||||
# Object becomes inactive
|
||||
# Can be nested to show recursion
|
||||
define inactive {
|
||||
extend_lifeline($1);
|
||||
active_$1 = active_$1 - 1;
|
||||
# draw bottom of innermost active box
|
||||
line right awid from ($1.x + (active_$1 - 1) * awid/2, Here.y);
|
||||
}
|
||||
|
||||
# Time step
|
||||
# Useful at the beginning and the end
|
||||
# to show object states
|
||||
define step {
|
||||
down;
|
||||
move spacing;
|
||||
}
|
||||
|
||||
# Switch to asynchronous messages
|
||||
define async {
|
||||
arrowhead = 0;
|
||||
arrowwid = arrowwid * 2;
|
||||
}
|
||||
|
||||
# Switch to synchronous messages
|
||||
define sync {
|
||||
arrowhead = 1;
|
||||
arrowwid = arrowwid / 2;
|
||||
}
|
||||
|
||||
# same as lifeline_constraint, but Text and empty string are exchanged.
|
||||
define lconstraint_below{
|
||||
off_from = awid;
|
||||
# add half a box width for each level of nesting
|
||||
if (active_$1 > 1) then {
|
||||
off_from = off_from + (active_$1 - 1) * awid/2;
|
||||
}
|
||||
|
||||
box at ($1.x + off_from, Here.y) invis "" $2 ljust;
|
||||
}
|
||||
|
||||
# begin_frame(left_object,name,label_text);
|
||||
define begin_frame {
|
||||
# The lifeline will be cut here
|
||||
extend_lifeline($1);
|
||||
# draw the frame-label
|
||||
$2: box $3 invis with .n at ($1.x, Here.y);
|
||||
d = $2.e.y - $2.se.y;
|
||||
line from $2.ne to $2.e then down d left d then to $2.sw;
|
||||
# continue the lifeline below the frame-label
|
||||
move to $2.s;
|
||||
lifestart_$1 = Here.y;
|
||||
}
|
||||
|
||||
# end_frame(right_object,name);
|
||||
define end_frame {
|
||||
# dummy-box for the lower right corner:
|
||||
box invis "" with .s at ($1.x, Here.y);
|
||||
# draw the frame
|
||||
frame_wid = last box.se.x - $2.nw.x
|
||||
frame_ht = - last box.se.y + $2.nw.y
|
||||
box with .nw at $2.nw wid frame_wid ht frame_ht;
|
||||
# restore Here.y
|
||||
move to last box.s;
|
||||
}
|
||||
|
||||
# comment(object,[name],[line_movement], [box_size] text);
|
||||
define comment {
|
||||
old_y = Here.y
|
||||
# draw the first connecting line, at which's end the box wil be positioned
|
||||
move to ($1.x, Here.y)
|
||||
if "$3" == "" then {
|
||||
line comment_default_move() dashed;
|
||||
} else {
|
||||
line $3 dashed;
|
||||
}
|
||||
|
||||
# draw the box, use comment_default_xx if no explicit
|
||||
# size is given together with the text in parameter 4
|
||||
old_boxht=boxht;
|
||||
old_boxwid=boxwid;
|
||||
boxht=comment_default_ht;
|
||||
boxwid=comment_default_wid;
|
||||
if "$2" == "" then {
|
||||
box invis $4;
|
||||
} else {
|
||||
$2: box invis $4;
|
||||
}
|
||||
boxht=old_boxht;
|
||||
boxwid=old_boxwid;
|
||||
|
||||
# draw the frame of the comment
|
||||
line from last box.nw \
|
||||
to last box.ne - (corner_fold, 0) \
|
||||
then to last box.ne - (0, corner_fold) \
|
||||
then to last box.se \
|
||||
then to last box.sw \
|
||||
then to last box.nw ;
|
||||
line from last box.ne - (corner_fold, 0) \
|
||||
to last box.ne - (corner_fold, corner_fold) \
|
||||
then to last box.ne - (0, corner_fold) ;
|
||||
|
||||
# restore Here.y
|
||||
move to ($1.x, old_y)
|
||||
}
|
||||
|
||||
# connect_to_comment(object,name);
|
||||
define connect_to_comment {
|
||||
old_y = Here.y
|
||||
# start at the object
|
||||
move to ($1.x, Here.y)
|
||||
# find the best connection-point of the comment to use as line-end
|
||||
if $1.x < $2.w.x then {
|
||||
line to $2.w dashed;
|
||||
} else {
|
||||
if $1.x > $2.e.x then {
|
||||
line to $2.e dashed;
|
||||
} else {
|
||||
if Here.y < $2.s.y then {
|
||||
line to $2.s dashed;
|
||||
} else {
|
||||
if Here.y > $2.n.y then {
|
||||
line to $2.n dashed;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
# restore Here.y
|
||||
move to ($1.x, old_y)
|
||||
}
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
# UML User Guide: Figure 18-2
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
boxwid = 1.1;
|
||||
movewid = 0.5;
|
||||
|
||||
# Define the objects
|
||||
object(C,"c:Client");
|
||||
pobject(T);
|
||||
object(P,"p:ODBCProxy");
|
||||
|
||||
# Message sequences
|
||||
step();
|
||||
active(C);
|
||||
cmessage(C,T,":Transaction");
|
||||
oconstraint("{Transient}");
|
||||
step();
|
||||
message(C,T,"setActions(a,d,o)");
|
||||
active(T);
|
||||
message(T,P,"setValues(d,3.4)");
|
||||
active(P);
|
||||
step();
|
||||
inactive(P);
|
||||
message(T,P,"setValues(a,\"CO\")");
|
||||
active(P);
|
||||
rmessage(T,C,"committed");
|
||||
inactive(T);
|
||||
inactive(P);
|
||||
async(); dmessage(C,T);
|
||||
step();
|
||||
inactive(C);
|
||||
step();
|
||||
|
||||
complete(C);
|
||||
complete(P);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following diagram, based on the one appearing on p. 247 of the
|
||||
UML User Guide, illustrates the dynamic creation and destruction of
|
||||
objects, an object constraint, and the changing of the focus of control.
|
||||
<h2>Diagram</h2>
|
||||
<img src="uml-182.gif" alt="UML User Guide: Figure 18-2, p. 247" />
|
||||
<h2>Diagram Source Code</h2>
|
||||
<fmtcode ext="pic">
|
||||
# UML User Guide: Figure 18-2
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
boxwid = 1.1;
|
||||
movewid = 0.5;
|
||||
|
||||
# Define the objects
|
||||
object(C,"c:Client");
|
||||
pobject(T);
|
||||
object(P,"p:ODBCProxy");
|
||||
|
||||
# Message sequences
|
||||
step();
|
||||
active(C);
|
||||
cmessage(C,T,":Transaction");
|
||||
oconstraint("{Transient}");
|
||||
step();
|
||||
message(C,T,"setActions(a,d,o)");
|
||||
active(T);
|
||||
message(T,P,"setValues(d,3.4)");
|
||||
active(P);
|
||||
step();
|
||||
inactive(P);
|
||||
message(T,P,"setValues(a,\"CO\")");
|
||||
active(P);
|
||||
rmessage(T,C,"committed");
|
||||
inactive(T);
|
||||
inactive(P);
|
||||
async(); dmessage(C,T);
|
||||
step();
|
||||
inactive(C);
|
||||
step();
|
||||
|
||||
complete(C);
|
||||
complete(P);
|
||||
|
||||
.PE
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
# UML User Guide: Figure 18-4
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
movewid = 0.5;
|
||||
|
||||
# Define the objects
|
||||
object(S,"s:Caller");
|
||||
object(W,":Switch");
|
||||
pobject(C);
|
||||
object(R,"r:Caller");
|
||||
|
||||
# Message sequences
|
||||
step();
|
||||
active(W);
|
||||
async(); message(S,W,"liftReceiver"); sync();
|
||||
active(S);
|
||||
message(W,S,"setDialTone()");
|
||||
async(); message(S,W,"*dialDigit(d)"); sync();
|
||||
lconstraint(W,"{dialing.executionTime < 30s}");
|
||||
active(W);
|
||||
message(W,W,"routeCalls(s,n)");
|
||||
inactive(W);
|
||||
cmessage(W,C,"c:Convers");
|
||||
active(C);
|
||||
message(C,R,"ring()");
|
||||
active(R);
|
||||
async(); message(R,C,"liftReceiver"); sync();
|
||||
message(C,W,"connect(r,s)");
|
||||
message(W,S,"connect(r)");
|
||||
# Specify label as a "constraint" to allign on W
|
||||
message(W,R,""); lconstraint(W,"connect(s)");
|
||||
step();
|
||||
|
||||
complete(S);
|
||||
complete(W);
|
||||
complete(C);
|
||||
complete(R);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following diagram, based on Figure 18-4 appearing on p. 252 of the
|
||||
UML User Guide, illustrates constraints on an object's lifeline,
|
||||
used both as genuine constraints, and to place a message label
|
||||
on a particular position.
|
||||
In addition, this diagram also uses nested activation.
|
||||
<h2>Diagram</h2>
|
||||
<img src="uml-184.gif" alt="UML User Guide: Figure 18-4, p. 252" />
|
||||
<h2>Diagram Source Code</h2>
|
||||
<fmtcode ext="pic">
|
||||
# UML User Guide: Figure 18-4
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
movewid = 0.5;
|
||||
|
||||
# Define the objects
|
||||
object(S,"s:Caller");
|
||||
object(W,":Switch");
|
||||
pobject(C);
|
||||
object(R,"r:Caller");
|
||||
|
||||
# Message sequences
|
||||
step();
|
||||
active(W);
|
||||
async(); message(S,W,"liftReceiver"); sync();
|
||||
active(S);
|
||||
message(W,S,"setDialTone()");
|
||||
async(); message(S,W,"*dialDigit(d)"); sync();
|
||||
lconstraint(W,"{dialing.executionTime < 30s}");
|
||||
active(W);
|
||||
message(W,W,"routeCalls(s,n)");
|
||||
inactive(W);
|
||||
cmessage(W,C,"c:Convers");
|
||||
active(C);
|
||||
message(C,R,"ring()");
|
||||
active(R);
|
||||
async(); message(R,C,"liftReceiver"); sync();
|
||||
message(C,W,"connect(r,s)");
|
||||
message(W,S,"connect(r)");
|
||||
# Specify label as a "constraint" to allign on W
|
||||
message(W,R,""); lconstraint(W,"connect(s)");
|
||||
step();
|
||||
|
||||
complete(S);
|
||||
complete(W);
|
||||
complete(C);
|
||||
complete(R);
|
||||
|
||||
.PE
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
# UML User Guide Figure 7-1.
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
actor(A,"");
|
||||
object(T,":OTaker");
|
||||
object(F,":OFulfill");
|
||||
step();
|
||||
|
||||
message(A,T,"submitOrder");
|
||||
message(T,F,"placeOrder");
|
||||
message(F,A,"acknowledgeOrder");
|
||||
|
||||
step();
|
||||
complete(A);
|
||||
complete(T);
|
||||
complete(F);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following diagram, based on Figure 7-1 appearing on p. 102 of the
|
||||
UML User Guide, illustrates an interaction diagram with an
|
||||
external actor.
|
||||
<h2>Diagram</h2>
|
||||
<img src="uml-71.gif" alt="UML User Guide: Figure 7-1, p. 102" />
|
||||
<h2>Diagram Source Code</h2>
|
||||
<fmtcode ext="pic">
|
||||
# UML User Guide Figure 7-1.
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
actor(A,"");
|
||||
object(T,":OTaker");
|
||||
object(F,":OFulfill");
|
||||
step();
|
||||
|
||||
message(A,T,"submitOrder");
|
||||
message(T,F,"placeOrder");
|
||||
message(F,A,"acknowledgeOrder");
|
||||
|
||||
step();
|
||||
complete(A);
|
||||
complete(T);
|
||||
complete(F);
|
||||
|
||||
.PE
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
# UML User Guide: Appendix A,p. 436
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
pobject(E,"External Messages");
|
||||
object(T,"t:thread");
|
||||
object(O,":Toolkit");
|
||||
pobject(P);
|
||||
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
message(E,T,"a1: run(3)");
|
||||
active(T);
|
||||
message(T,O,"run()");
|
||||
active(O);
|
||||
message(O,O,"callbackLoop()");
|
||||
cmessage(O,P,"p:Peer"," ");
|
||||
active(O);
|
||||
message(O,P,"handleExpose()");
|
||||
active(P);
|
||||
rmessage(P,O,"");
|
||||
inactive(P);
|
||||
inactive(O);
|
||||
dmessage(O,P);
|
||||
inactive(T);
|
||||
inactive(O);
|
||||
|
||||
step();
|
||||
|
||||
complete(T);
|
||||
complete(O);
|
||||
|
||||
.PE
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
The following diagram, based on the one appearing on p. 436 of the
|
||||
UML User Guide, contains the most important elements
|
||||
of an interaction.
|
||||
It also uses nested
|
||||
<em>active</em> <em>inactive</em> calls to show a nested object activation.
|
||||
<h2>Diagram</h2>
|
||||
<img src="uml-appa.gif" alt="UML User Guide: Appendix A, p. 436" />
|
||||
<h2>Diagram Source Code</h2>
|
||||
<fmtcode ext="pic">
|
||||
# UML User Guide: Appendix A,p. 436
|
||||
|
||||
.PS
|
||||
|
||||
copy "sequence.pic";
|
||||
|
||||
# Define the objects
|
||||
pobject(E,"External Messages");
|
||||
object(T,"t:thread");
|
||||
object(O,":Toolkit");
|
||||
pobject(P);
|
||||
|
||||
step();
|
||||
|
||||
# Message sequences
|
||||
message(E,T,"a1: run(3)");
|
||||
active(T);
|
||||
message(T,O,"run()");
|
||||
active(O);
|
||||
message(O,O,"callbackLoop()");
|
||||
cmessage(O,P,"p:Peer"," ");
|
||||
active(O);
|
||||
message(O,P,"handleExpose()");
|
||||
active(P);
|
||||
rmessage(P,O,"");
|
||||
inactive(P);
|
||||
inactive(O);
|
||||
dmessage(O,P);
|
||||
inactive(T);
|
||||
inactive(O);
|
||||
|
||||
step();
|
||||
|
||||
complete(T);
|
||||
complete(O);
|
||||
|
||||
.PE
|
||||
</fmtcode>
|
||||
</notes>
|
||||
|
|
@ -0,0 +1,240 @@
|
|||
<?xml version="1.0" ?>
|
||||
<!-- $Id$ -->
|
||||
<notes>
|
||||
<dl>
|
||||
|
||||
<dt>Version 4.2 Under development</dt><dd>
|
||||
<ul>
|
||||
<li> Correct the handling of qualified class names following
|
||||
the extends keyword (Arnaud Rogues).</li>
|
||||
</ul>
|
||||
|
||||
<dt>Version 4.1 2005/11/15</dt><dd>
|
||||
<ul>
|
||||
<li> Major source code reorganization to move closer to the Java coding
|
||||
conventions.
|
||||
The user-visible change is that the doclet is now invoked as
|
||||
<fmtcode ext="sh">
|
||||
javadoc -docletpath UmlGraph.jar -doclet gr.spinellis.umlgraph.doclet.UmlGraph
|
||||
</fmtcode>
|
||||
</li>
|
||||
<li> Show package visibility for class members (Olek Poplavskyy). </li>
|
||||
<li> Prevent crash when processing erroneous relation specifications (Andrea Aime).</li>
|
||||
<li> Most loops were refarctored to use the typesafe Java 1.5 foreach construct. </li>
|
||||
<li> Fix Eclipse warning (Andrea Aime).</li>
|
||||
<li> Better control of class hiding.
|
||||
Now classes are hidden even when involved in a relationship with a visible class
|
||||
(Andrea Aime).</li>
|
||||
<li> Source code modifications to allow Java-based testing (Andrea Aime).</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 3.3 2005/10/19</dt><dd>
|
||||
<ul>
|
||||
<li> The sequence diagrams now include support for drawing
|
||||
comments and frames. (Contributed by Sebastian Setzer)</li>
|
||||
<li> The -noguillemot option will output two angle bracket pairs
|
||||
instead of round brackets around stereotypes.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 3.2 2005/07/19</dt><dd>
|
||||
<ul>
|
||||
<li> Display the template arguments of generic classes inside angle brackets.
|
||||
Note that according to the UML specification these arguments should
|
||||
be displayed in a dashed box on the top right of the class.
|
||||
However, such a display is currently not possible in GraphViz.</li>
|
||||
<li> Display the type parameters of fields and method arguments. </li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 3.1 2005/03/26</dt><dd>
|
||||
<ul>
|
||||
<li> <b>Note that from this version UMLGraph requires Java 1.5.</b></li>
|
||||
<li> First step of the Java 1.5 transition; more will follow.</li>
|
||||
<li> The container code in the source was changed to use the Java 1.5 generics.</li>
|
||||
<li> Will display enumerations as a stereotyped primitive type.
|
||||
Two new options <code>-enumerations</code> and <code>-enumconstants</code>
|
||||
control the corresponding operation.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.10 2004/11/19</dt><dd>
|
||||
<ul>
|
||||
<li> This is the last version compatible with Java 1.4.</li>
|
||||
<li> Corrected the interaction between the
|
||||
<code>-attributes</code> and
|
||||
<code>-operations</code> options and classes with no
|
||||
fields or methods.
|
||||
Many thanks to Jonathan Wright for this contribution. </li>
|
||||
<li>New documentation look, designed by George Zouganelis</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.9 2004/10/07</dt><dd>
|
||||
<ul>
|
||||
<li> Class diagrams can now include constructors, through the new
|
||||
<code>-constructors</code> option.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.8 2004/08/09</dt><dd>
|
||||
<ul>
|
||||
<li> Fixes to support the Maven plugin.</li>
|
||||
<li> From this version onward, use the appropriate options to create
|
||||
documentation links; no hyperlinks are created by default.</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.7 2004/08/06</dt><dd>
|
||||
<ul>
|
||||
<li> The -noguillemot option will output round brackets around stereotypes,
|
||||
instead of angle brackets.
|
||||
The angle brackets appear to be breaking some programs.
|
||||
</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.6 2004/08/03</dt><dd>
|
||||
<ul>
|
||||
<li> <b>Note that from this version UMLGraph requires Java 1.4.</b></li>
|
||||
<li> Documentation example: multiple views from the same source.
|
||||
Many thanks to Vadim Nasardinov for this contribution. </li>
|
||||
<li> Documentation now includes a FAQ section. </li>
|
||||
<li> Documented the fact that package names must be explicitly
|
||||
specified in tags. Arne Bayer noticed the associated problem. </li>
|
||||
<li> Correct handling of multiple space in tags.
|
||||
Noted by Jeffrey M. Thompson which the help of
|
||||
<a href="http://findbugs.sourceforge.net/">FindBugs</a>.
|
||||
</li>
|
||||
<li> Completed customization of URL mapping. Now the mapping is fully
|
||||
configurable and can be controlled by the use of two new options:
|
||||
"-apiDocRoot" and -"apiDocMapFileName".
|
||||
This change allows the creation of "clickable"
|
||||
diagrams fully integrated with web-based documentation
|
||||
(for example JavaDoc pages).
|
||||
The upcoming UMLGraph Maven plugin will take full advantage of this feature.
|
||||
Implementation contributed by Nascif Abousalh-Neto
|
||||
</li>
|
||||
<li> The -hide argument now accepts regular expressions. </li>
|
||||
<li> Removed copy-pasted Java code that was introduced in version 1.24.</li>
|
||||
<li> Some dot edges were missing a semicolon. This is now fixed. </li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.5 2004/06/15</dt><dd>
|
||||
The object swimlanes in a sequence diagram
|
||||
can now show nested object invocations.
|
||||
This very useful and non-trivial change was contributed by Jonathan R. Santos.
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.4 2004/05/29</dt><dd>
|
||||
Will now generate local URL hyperlinks for packages specified in
|
||||
the command line; and links to the Sun documentation for all
|
||||
other packages.
|
||||
Many thanks to Nascif Abousalh-Neto for contributing this change.
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.3 2004/05/27</dt><dd>
|
||||
<ul>
|
||||
<li>
|
||||
Remove hardcoded default node and edge fonts.
|
||||
Thanks to Vadim Nasardinov for submitting the corresponding patch.
|
||||
</li>
|
||||
<li>
|
||||
Generate javadoc hyperlink paths in a directory-tree structure;
|
||||
do not show arcs on hidden classes.
|
||||
Thanks to Alessandro Riva for submitting the corresponding patch.
|
||||
</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.2 2004/05/25</dt><dd>
|
||||
SVG class diagrams containing guillemot characters
|
||||
for stereotypes
|
||||
can now be made valid through a new -outputencoding option.
|
||||
Use "-outputencoding UTF-8" when using dot to generate SVG diagrams.
|
||||
Many thanks to Nascif Abousalh-Neto for bringing this problem to
|
||||
my attention.
|
||||
</dd>
|
||||
|
||||
<dt>Version 2.1 2004/05/16</dt><dd>
|
||||
The guillemot characters used for the create and destroy stereotypes
|
||||
are now portable between <em>groff</em> and <em>pic2plot</em>.
|
||||
Many thanks to Scott Johnson (Duluth, MN) for recommending the change.
|
||||
</dd>
|
||||
|
||||
|
||||
<dt>Version 2.0 2004/05/09</dt><dd>
|
||||
<ul>
|
||||
<li> Support for drawing sequence diagrams.</li>
|
||||
<li> New distribution format.</li>
|
||||
<li> Browsable and printable documentation.</li>
|
||||
<li> Removed the <em>ant</em>-based compilation and distribution
|
||||
system; it was proving a hindrance in organizing the project in
|
||||
a resonable manner.
|
||||
Compiling the documentation and distribution is now handled by
|
||||
a (non-distributed) Makefile; the compilation process is described
|
||||
in the README file.
|
||||
</li>
|
||||
</ul>
|
||||
</dd>
|
||||
|
||||
<dt>Version 1.24 2003/07/30</dt><dd>
|
||||
Changes by Art Hampton (thanks):
|
||||
<ul>
|
||||
<li> Create the appropriate label for relationship tags when referring to
|
||||
classes which were not parsed by javadoc.
|
||||
</li>
|
||||
<li> New "-hide <matchstring>" option, where <matchstring>
|
||||
matches the end of the name of an entity.
|
||||
Matched entities are removed from the graph.
|
||||
A regular expression matching facility will be added when Java 1.4
|
||||
becomes more widespread.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</dd>
|
||||
<dt>Version 1.23 2003/05/7</dt><dd>
|
||||
Added <code>-output</code> command-line option, and an <em>ant</em>-based
|
||||
build file.
|
||||
Modified the dot output to avoid triggering a graphviz bug that made escape codes visible.
|
||||
|
||||
</dd>
|
||||
<dt>Version 1.20 2003/04/25</dt><dd>
|
||||
Fixes by Nick Efthymiou (thanks):
|
||||
will generate SVG hyperlinks to Javadoc documentation,
|
||||
better handling of abstract class fonts,
|
||||
and correct listing of interfaces.
|
||||
</dd>
|
||||
<dt>Version 1.19 2002/09/20</dt><dd>
|
||||
New options:
|
||||
nodefontname,
|
||||
nodefontabstractname,
|
||||
nodefontsize,
|
||||
nodefontcolor,
|
||||
edgefontname,
|
||||
edgefontsize,
|
||||
edgefontcolor,
|
||||
edgecolor,
|
||||
bgcolor.
|
||||
|
||||
</dd>
|
||||
<dt>Version 1.18 2002/08/26</dt><dd>
|
||||
<ul>
|
||||
<li> Can now specify class-local options.
|
||||
</li>
|
||||
<li> Support for the @tagvalue tag.
|
||||
</li>
|
||||
<li> Support for the @stereotype tag.
|
||||
</li>
|
||||
<li> Added nodefillcolor option.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
</dd>
|
||||
<dt>Version 1.15 2002/07/26</dt><dd>First public release.
|
||||
</dd>
|
||||
</dl>
|
||||
</notes>
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
// $Id$
|
||||
|
||||
/**
|
||||
* Attribute and operation visility
|
||||
* UML User Guide p. 123
|
||||
*
|
||||
* @opt operations
|
||||
* @opt attributes
|
||||
* @opt types
|
||||
* @opt visibility
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions {}
|
||||
|
||||
/** @hidden */
|
||||
class Tool {}
|
||||
|
||||
class Toolbar {
|
||||
protected Tool currentSelection;
|
||||
protected Integer toolCount;
|
||||
public void pickItem(Integer i) {}
|
||||
public void addTool(Tool t) {}
|
||||
public void removeTool(Integer i) {}
|
||||
public Tool getTool() {}
|
||||
protected void checkOrphans() {}
|
||||
private void compact() {}
|
||||
}
|
||||
Loading…
Reference in New Issue