Software Construction: UML Part 1

Attributes are "variables" that hold specific values.

Operations are "functions" that (can) operate on the arrtibutes.

+ for public

- for private

# for protected

italic for abstract

... signals further entries are not shown

underlined attributes have class scope (?)

In the header: <<Stereotype>> (i.e. interface, utility,...) & {User-defined properties} (i.e. abstract)

Constraints are restrictions on values attached to classes or
associations. A constraint is depicted by a dotted line and usually annotated.

An association is a structural relationship that represents objects can be connected or associated with another object inside the system (e.g. usage).

Usually binary (but may be ternary, etc.)

Optional name and direction

(unique) role names and multiplicities at end points

It is denoted by a solid line.

A dependency describes the dependent elements & the direction of dependency.

Dependency is represented by a dotted arrow. The arrow head represents the independent element and the other end represents the dependent element.

As the name suggests, the directed / navigable association is related to the direction of flow within association classes. The association from one class to another class flows in a single direction only.

It is denoted using a solid line with an arrowhead.

Within a realization relationship, one element describes some responsibility, which is not implemented and the other one implements them. This relationship exists in case of interfaces. It is represented by a dotted arrow with a hollow arrow head pointing to the responsibility (e.g. an interface).

Generalization describes the inheritance relationship of the object-oriented world. It is a parent & child relationship.

Generalization is represented by an arrow with a hollow arrow head. The arrow head end represents the parent element and the other end represents the child element.

We also speak of a subclass (child) that specializes its superclass (parent).

An aggregation relationship can be described in simple words as "an object of one class can own or access the objects of another class.". In an aggregation relationship, the dependent object remains in the scope of a relationship even when the source object is destroyed.

Composite aggregation is described as a binary association decorated with a filled black diamond at the aggregate (whole) end.

Aggregation implies a relationship where the child can exist independently of the parent. Example: Class (parent) and Student (child). Delete the Class and the Students still exist.

Composition implies a relationship where the child cannot exist independent of the parent. Example: House (parent) and Room (child). Rooms don't exist separate to a House.

Interfaces, equivalent to abstract classes with no attributes, are represented as classes with the stereotype <<interface>> (explicit style) or, alternatively with the “Lollipop-Notation” (implicit style).

Parameterized (“template” or “generic”) classes are depicted with their parameters shown in a dashed box.

A utility is a grouping of global attributes and operations. It is represented as a class with the stereotype <<utility>>. Utilities may be parameterized.

ATTENTION: A utility’s attributes are already interpreted as being in class scope, so it is redundant to underline them.

Objects are shown as rectangles with their name and type underlined in one compartment, and attribute values optionally in a second compartment.

At least one of the name or the type must be present

• 0..1 : Zero or one entity
• 1 : Exacty one entity
• * : Any numbers of entities (0 possible)
• 1..* : One or more entities
• 1..n : One to n entities

The multiplicity of an association constrains how many entities one may be associated with.

{ordered}

{xor}

{implicit} : specifies that the relationship is not manifest but, rather, is only conceptual.

{changeable}: Links between objects may be added, removed, and changed freely.

{addonly}: New links may be added from an object on the opposite end of the association.

{frozen}: A link, once added from an object on the opposite end of the association, may not be modified or deleted.

Objects of distinct, but related, classes may be uniformly treated by clients.

Conceptually related classes can be organized into a specialization hierarchy.

E.g. people, employees, managers; geometric objects; etc.

Related classes may share interfaces, data structures or behavior.

Remember: Using Inheritance for code reuse, or just because it looks nice is a dangerous practice!

An Association may be an instance of an association class. In many cases the association class only stores attributes, and its name can be left out.

A qualified association has a qualifier value that is used to select an object (or objects) from a larger set of related objects, based upon the qualifier key.

Informally, in a software perspective, it suggests looking things up by a key, such as objects in a HashMap.

NB (NoBrainer?): Qualifiers are part of the association, not the class.

Pros

• Useful to represent how types are defined and related
• They are useful to capture the essence of one or more design decisions

Cons

• Poor vehicle for capturing run-time property of the code