UML
These are my personal notes that I use as a quick help in my work.
You are welcome to read them.
|
|
|
Contents
Introduction
These are my personal notes
See also index.html
UML is overseen by the Object Management Group (OMG): www.omg.org.
Stands for Unified
Modeling Language.
See basics of data modelling in SQL notes
UML
Object (static) <-- link --> message (dynamic)
Often three types of objects: actors that send messages, agents that are between
and servers that generally repond to messages.
Object = state (set of attributes) + behavior (set of operations, triggered
by messages from the outside) + identity
Objects are grouped into classes:
| Classe name |
|
+Public Attribute: data type
#Protected Attribute: data type
-Private Attribute: data type
|
|
+Public Operation( )
#Protected Operation( )
-Private Operation( )
|
| Responsabilities |
| Exceptions |
As objects are instances of classes, so are links instances of relationships.
Persistence is not well handled by programming languages. Generally, data bases
are used.
| Links |
- Dependance: a - - - - -> uses b
- Association: ----------
- Generalization: ------|> (opposite: inheritence)
- Realization (contract) / inclusion:
element that is extended - - - -|> element that is included
Generally through the implementation of an interface
|
Message
sSynchronization
![--> [next] --><-> [next] ----| [next] o--> [next] --\](uml/uml_links.GIF) |
- Simple: message in one direction only -->
- Synchronous: both directions, the sender is blocked until the answer
is received --><->
- Balking: the sender assumes that the receiver is waiting for messages,
therefore the sender does not check if the receiver is ready __<-_-_-|
- Timeout: the sender is blocked only until it times out --°-->
- Asynchronous: the sender sends the message without knowing when the
response will come __\
|
| |
Collaboration diagrams (show relations but no notion of time) and sequece
diagrams. |
|
Associations are bidirectional links.
Each extremity is a role.
An association may only be navigable in one direction; bi-directional
by default.
Cardinality: 0..1, 1..1, 0..*, m..n
|
|
A qualifier introduces a type of key.
For each value of the qualifier,
there are four instances of the object on the right. |
 |
Aggregations describe stronger links, of the master-slave
type.
Aggregations are asymetrical associations where one side
plays a stronger role than the other.
Could be read as "<main class> consists of <details>".
Note that in aggregations, each part can have an existence on its own. |
 |
Composition: the "detail" is an attribute;
the cardinality is 0 or 1 (the attribute has a value or is null).
Note that in a composition, the parts have no separate existence. |
 |
|
Generalization - inheritance
The super class can be abstract.
Abstract classes group characteristics of several classes;
this forms a tree of sub-classes, with the leaves as concrete classes.
Abstract classes have abstract operations and abstract attributes,
which must be implemented by the sub-classes.
Not all programming laguages offer multiple inheritance.
|
 |
|
Interface
(use the image 
uml_object_representation.GIF ??)
|
 |
An association may have a class
that contains attributes of the association.
Particularly useful for M to N cardinality. |
 |
| Packages allow a definition of a name space |
|
|
Types of classes:
- actor
- boundary: an entry form
- interface
- control
- entity: a record
|
 |
| Logical view |
|
Component view
|
| |
Use case view |
|
| (view of processes) |
|
Deployment view |
Nine diagrams:
Structural diagrams
- Class diagram
- Object: objects and relations, but without the messages (with messages =
collaboration)
- Component: physical components of an application
- Deployment of components
Dynamic diagrams:
- Sequence
- Collaboration: spatial representation of objects and interactions
- Use case: system functions from the point of vue of the user
- Activities (e.g. workflow)
- Transition-states: shows life-cycle
- Valeur marquée
- name-value pair (paire nom-valeur)
- Constraint
- semantical relation that must always be true.
Categories of objects:
- Application objects
- Functional objects (objets métier)
- Implementation objects
Metaclassification:
- <<abstract>>
- <<constructor>>
- <<interface>>
Navigation:
- entity.selector --> descendants
- entity.~selector --> parents
- entity[condition] --> sub-set
- entity[value] --> one entity with key "value"
- source.class^target.Event(arguments) --> a source class sends an event
to a target class:
|
A collaboration is a set of classes and other elements that describe
a use case.
Patterns are generic collaborations.
|
 |
|
Use case diagram: each use case is a set of scenarios.
- communication
- inclusion (mandatory scenario mandatory)
- extend: the scenario extends the main scenario, eventually with a
condition
- generalization
|
 |
|
Object representation (objects as instances of classes):
- objectA:classA --> object A as instance of class A
- objectB --> object without a specified class
- :classC --> anonymous instance of class C
|
|
|
State diagrams
- Inital state is mandatory
- 0..N final states are possible
- Guard Condition: boolean condition
- Concurrent sub-states: the state is one of the combinations of the
sub-states.
- operations correspond to actions and activities
- <<do>>activity (linked to a state). Can be interrupted.
- action (is instantaneous): entry/action; exit/action; event .../action;
transition/action
|
 |
An activity diagram is a type of state-transition diagram
that shows the workflow.
A bar indicates simultaneous triggers. Either several incoming triggers
are synchronized, or several outgoing triggers (but not both).
Swimlanes (travées) are like columns indicating the activities of
one actor. |
|
Component diagrams show the physical elements of a system
(code, script, file, ...).
Five standard "stereotypes": <<document>>, <<executable>>,
<<file>>, <<library>>, <<table>>.
Dependancies show with arrows indicating an element - - - - uses services
- - -> of another element.
In the case of an interface or API, an element - - - uses - - -> interface
represented by a circle ---- element.
A task has a seperate execution flow (thread). |
|
Deployment diagrams show the physical layout.
Each physical resource is shown as a node. Generally, each node has memory
and most have execution capabilities.
A component - - - uses or resides on - - -> a node.
One node is connected --- type of cable --- to another. |
|
Bibliography
Martin Fowler: UML Distilled