Basic Modelling Concepts

From HaFrWiki
Jump to: navigation, search

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[edit]

Basic OO Elements are:

Association[edit]

BidirectionalAssociation.png UnidirectionalAssociation.png
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[edit]

Aggregation-Composition3.png
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[edit]

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[edit]

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[edit]

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[edit]

UML Sequence Diagrams

UML Sequence Diagram [1] 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-Arrows.jpg
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[edit]

classDiagramAnalysisVsDesign.gif top

Reference[edit]

top

  1. UML Diagrams Sequence Diagrams, Overview of Sequence Diagrams on UML Diagrams