Basic Modelling Concepts

Modelling tools have their own interpretation of how diagrams, icons are used. This webpage tries to give some clues on how this implementation are made.

Diagram Elements	Sterotypes
Class Diagram Elements Class Diagram Elements	Standard Icons Stereotypes. Standard Icons Stereotypes.

Object Orientation Basic Elements

Basic OO Elements are:

• Associaton
• Aggregation
• Composition

Association

A bidirectional association	Unless otherwise specified, navigation across an association is bidirectional, although it may be limited to just one direction by adorning some end with an arrowhead pointing to the direction of traversal.
Description
Association defines a relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf.

Aggregation

A bidirectional association, first a composition, the second is an aggregation.
Description
Association defines a relationship between classes of objects that allows one object instance to cause another to perform an action on its behalf. A "uses" B = Aggregation : B exists independently (conceptually) from A. Example: A Company is an aggregation of People. A Company is a composition of Accounts. When a Company ceases to do business its Accounts cease to exist but its People continue to exist.

Composition

1-directional composition
Description
A "owns" B = Composition : B has no meaning or purpose in the system without A. The arrowhead on the other end of the relationship denotes that the relationship is navigable in only one direction. That is, Point does not know about Circle. Example: Each instance of type Circle contains instance(s) of type Point. A Text Editor owns a Buffer (composition). A Text Editor uses a File (aggregation). The university has faculties which exists on its departments (composition). Departments uses employees/members (aggregation).

In Java:

public class Point { private float x; private float y; /** * Constructor * @param x Value for the x-axis. * @param y Value for the y-axis. */ public Point(float x, float y) { this.x = x; this.y = y; } ... }

width="525" public class Circle { private float radius; private Point center; /** * Constructor * @param center Instance of class point * @param radius Length of the radius. */ public Circle(Point center, float radius) { this.center = center; this.radius = radius; } ... }

Design of Class Diagrams

Ontwerpbeslissingen	Development design decisions
Introductie	Introduction
De basis vuistregels voor het ontwerpen van Class Diagrams voor beginnende en gevorderde ontwikkelaars.	Basics guidelines for designing Class Diagrams for beginners and experts.
- 1 -
Attributen zijn private Getters en Setters toevoegen (Alleen indien nodig)	Attributes are private Add only the necessary Getters and Setters
- 2 -
Constructor heeft parameters: Identificerende attributen Verplichte attributen Optioneel extra constructors Indien vaak meer parameters gewenst zijn.	Constructor has parameters: Identifying attributes Required attributes Optional extra (alternative) constructors When often more parameters are required
- 3 -
Associatie met lage multipliciteit Kies één of meer attributen van enkelvoudig type Associatie met hoge multipliciteit Kies voor een attribuut van type Collection	Association with low multiplicity Choose one or more attributes of base type Association with high multiplicity Choose an attribute of type Collection
- 4 -
Afleidbare informatie Definieer een functie om de waarde te berekenen (of sla de waarde op in een attribuut). Vermijd redundantie	Derivable / deductable Information Define a method to calculate the value (or use an attribute)
- 5 -
Als een associatie Attributen heeft Operaties heeft Associaties heeft met andere classes Introduceer dan een associatie class!	If an association has Attributes Operations / Methods Associations with other classes Then Introduce an association class.
- 6 -
Administratieve verplicting Bij een aggregatie kunnen onderdelen van een object zelfstandig blijven voortbestaan Bij een compositie verdwijnen onderdelen van een object als het betreffende object verdwijnt levensduur onderdeel ≤ levensduur object
- 7 -
Liskov substitutieprincipe: Overal waar een instantie van een class gebruikt kan worden, kan ook altijd een willekeurige instantie van een willekeurige subclass of subtype gebruikt worden	Barbara Liskov: Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S, where S is a subtype of T.
- 8 -
Programmeer tegen een interface, niet tegen een implementatie	Program against an interface, not against an implementation
- 9 -
Abstract class of Interface? Als de nadruk ligt op attributen/kenmerken >> abstracte class Als de nadruk ligt op methoden/gedrag >> interface	Abstract class or Interface? If emphasis on attributen/kenmerken >> abstracte class If emphasis on methoden/gedrag >> interface

Class Visibility

To specify the visibility of a class member (i.e., any attribute or method), these notations must be placed before the member's name:

+	Public
-	Private
#	Protected
/	Derived (can be combined with one of the others)
~	Package

Sequence Diagrams

UML Sequence Diagrams

UML Sequence Diagram is the most common kind of interaction diagram, which focuses on the message interchange between a number of lifelines.
Sequence diagram describes an interaction by focusing on the sequence of messages that are exchanged, along with their corresponding occurrence specifications on the lifelines.
The following nodes and edges are typically drawn in a UML sequence diagram: lifeline, execution specification, message, combined fragment, interaction use, state invariant, continuation, destruction occurrence. Major elements of the sequence diagram are shown on the picture on the right.

• Lifeline is a named element which represents an individual participant in the interaction. While parts and structural features may have multiplicity greater than 1, lifelines represent only one interacting entity ( More... ).
  • Syntax:
    lifeline-ident ::= [ connectable-element-name [ '[' selector ']' ]] [ ':' class-name ] [ decomposition ] | 'self'
    selector ::= expression
    decomposition ::= 'ref' interaction-ident [ 'strict' ]
• Message is a named element that defines one specific kind of communication between lifelines of an interaction. The message specifies not only the kind of communication, but also the sender and the receiver. Sender and receiver are normally two occurrence specifications (points at the ends of messages). ( More... ).

UML Sequence Diagram Arrows.

• • Syntax:
    message ::= [ attribute '=' ] signal-or-operation-name [ arguments ] [ ':' return-value ] | '*'
    arguments ::= '(' [argument [ ',' argument]* ')'
    argument ::= [ parameter-name '='] argument-value | attribute '=' out-parameter-name [ ':' argument-value ] | ' -'
• A Gate is a message end, connection point for relating a message outside of an interaction fragment with a message inside the interaction fragment. ( More... )
• An Interaction fragment is a named element representing the most general interaction unit. Each interaction fragment is conceptually like an interaction by itself.

There is no general notation for an interaction fragment. Its subclasses define their own notation.

• An Occurrence Specification, i.e. "event description", is an interaction fragment which represents a moment in time (event) at the beginning or end of a message or at the beginning or end of an execution.
• An Execution (full name - execution specification, informally called activation) is an interaction fragment which represents a period in the participant's lifetime when it is:
  • executing a unit of behavior or action within the lifeline,
  • sending a signal to another participant,
  • waiting for a reply message from another participant.
• A state invariant is an interaction fragment which represents a runtime constraint on the participants of the interaction. It may be used to specify different kinds of constraints, such as values of attributes or variables, internal or external states, etc.
  The constraint is evaluated immediately prior to the execution of the next occurrence specification such that all actions that are not explicitly modeled have been executed. If the constraint is true, the trace is a valid trace, otherwise the trace is an invalid trace.
• Interaction use is an interaction fragment which allows to use (or call) another interaction. Large and complex sequence diagrams could be simplified with interaction uses. It is also common reusing some interaction between several other interactions.

See also

• Agile Modeling, Class Diagrams Guidelines. See example above.
• UML-Diagrams, Sequence Diagrams Reference.