Disclaimer. CSUSB and the CS Dept have no responsibility for the content of this page.
Copyright. Richard J. Botting ( Fri May 12 15:30:28 PDT 2006 ). Permission is granted to quote and use this document as long as the source is acknowledged.
Package diagrams are used to help control a complex set of UML diagrams by providing grouping and a name space mechanism. They may also indicate the organization of source code in packages (Java and Ada) or name spaces (C++?).
Here is a classic logical architecture [Larman]
Class and Object Diagrams
Aggregation <>---. Avoid because it means very little.
You might as well just write has on the association instead.
Use a navigable association to show pointers ---->
Default Multiplicities. Confusing.
Object diagrams give examples of how objects are connected. Simple and obvious:
Notice that the name and type is underlined in the objects. Also note
the ":" colon separating the name of the object from it's class.
Objects + Messages helps design classes.
The syntax for components has been improved with the old shape now
an icon in the top-right hand corner.
Components a encapsulate pieces of compiled code with defined interfaces. Each defines the interfaces it provides and the interfaces it requires. Plug Compatible.
New notation: cup = required, ball = provided.
Composite Structure Diagrams
A detailed description of a set of components and the dependencies
between them shown by ball-and-socket links.
Component Diagrams can now express DFDs
Many object-oriented fanatics consider Data Flow Diagrams as a cardinal sin
or even heresy.
Physical and data flows remain an important tool for everybody else.
UML2.0 has features to handle this
For more some of the alternate ways of expressing DFDs see [ rjb04bDFDs/ ] some early drafts for Yang05.
Vertical life lines with messages connecting them horizontally.
New syntax: we don't underline the boxes at the top of the life lines any more because they are not objects any more!
New idea: Interaction frames
|alt||Alternative sets of interactions only one of which may occur|
|loop||A set of interactions that can be repeated|
|neg||A negative set of interactions that must not occur|
|opt||A set of interactions that may or may not occur (once)|
|par||A set of sequences that can occur in parallel|
|ref||A reference to another diagram|
|region||A set of sequences that can only be executed by one thread at a time|
|sd||A named sequence diagram that can be referred to elsewhere|
But activity diagrams use Petri Net style token passing semantics.
Activities start when all incoming tokens are present.
Activities output tokens as they terminate.
We can even use an object to pass control tokens to an activity.
Also allows asynchronous object streams. This means that an activity can start before an object arrives and can continue after it has output its objects:
Unexpected use: Critical path analysis, because the fork and join a synchronizing connectors: all the actions leading to them must have completed and none of the following ones can start.
modeling a CSci curriculum.
Artifacts vs Components vs Packages
|Package||Collection of UML classifiers etc||Anywhere|
|Component||An encapsulated(plug-and-play) network of run-time objects||Component & composite structure diagrams.|
|Artifact||Something produced during development||Deployment diagram|
An artifact manifests some components and components may implement packages (roughly).
Nodes used to be hardware, now they can be anything that can execute an
artifact. They can be nested.
No more components, only artifacts.
I added one non-standard artifact stereotype: <<applet>>. The
standard artifact stereotypes
are: file, document, script, executable, library, and source.
Notation for Diagrams
The new specification also has a formal way of giving a name to a diagram.
It lists all the different official types of diagram.
Interaction Overview Diagram
Allows you to place sequence diagrams as boxes inside activity diagrams!
See Fowler's 3rd Edition.
See Fowler's 3rd Edition.
Is anything missing?
I would like to see UML contain And/Or tables for conditions
or else Decision Tables for complex logic.
Goal. To define ways for tools to share information about and in
Too many acronyms.
New version of the OCL.
MDA - Tomorrow the World
Model Driven Architecture
Arlow and Neustadt show there are common patterns that emerge when modeling most enterprises.
OMG wants to document these and make them available (for a price?) to people.
OMG also has a scheme to connect general Platform Independent Models to Platform Specific Models to code -- automatically.
I have to update all my UML documentation.
The department needs to decide when it cuts over to the new notations.
Back to Outline
[ 20050502Outline.html ]
. . . . . . . . . ( end of section A Few Changes in the Unified Modeling Language) <<Contents | End>>