UML Distilled by Martin Folwler

Chapter 5,6,7 presented by Robert Jakubov

 


Interaction Diagrams: Sequence and Collaboration Diagrams

q       Both specify the same information.

q       Both explore the interaction among objects within a single problem domain.

q       However, each emphasizes different aspects.

Figure 1:  Sequence diagram

Figure 2:  Collaboration diagram

 

q       CRC Cards (Class-Responsibility-Collaboration Cards)

·        A quick and simple alternative to Sequence and Collaboration diagram.

·       Usually 4 by 6 index cards that demonstrate the behavior, characteristics, and purpose of a class.

Figure 3: CRC Card

Class Diagrams: Advanced Concepts

Stereotype

 
  • Extends the vocabulary of UML.

 

·        Java, COM, or CORBA interfaces are an example of Stereotypes.

 
  • E.g.:     <<exception>>, <<include>>. <<create>> etc.

 

 

 

 

Object Diagram (Figure 1)

  • Snapshot of cooperating objects at an instance in time.

·        With the value of their attributes and their links.

  • Links are relationships between existing objects.
  • Notation
  • Object: Class.

·        E.g.: Fred: Person.

  • Attribute = Value.
  • E.g.:  location = Sydney.

Figure 1

 

Class Operations and Attributes

·        An operation or attribute that is a property of the class is underlined.

  • E.g.:  a C++ or Java static members such as countOfInstances.

 

 

Aggregation and Composition (Figure 2)

 

q       Parts and wholes

  • Aggregation is “Part-Of” or “Has-A” relationship.

·        A looser coupling between the whole and the part via sharing of parts.

  • Composition is a stronger form of aggregation.

o       A part may belong to only one whole.

    • The part lives or dies with the whole.
    • The whole is responsible for initiating the creation and
      destruction of the part.

§         E.g.: A car has an engine.

 

 

Frozen (Constraints) (Figure 2)

·        A Constraint {i.e.: Read only attribute}.

·        Constant cannot change.

o       E.g.: A person’s SS# cannot change once set.

·        Association or association end cannot change.

 

Derived Associations and Attributes (Figure 2)

  • Calculated from other associations and attributes on a class diagram.
    • E.g.: an age attribute of a person can be derived if you know that person’s DOB.

Association Class (Figure 2)

·        An intermediate class among two or classes.

o       E.g.: A Person object might be related to a Company object via an Employment
object  (Association class).

Figure 2

 

 

Multiple and Dynamic Classification

·        Refers to the relationship between an object and its type.

·        Single Classification: an object belongs to a single type.

·        Multiple Classification: an object may belong to many types may or may
not be related.

·        Dynamic Classification allows objects to change type within an inheritance
structure; Static Classification does not.

Miscellaneous

q       Abstract Class

·        Use Italic or the constraint {abstract}.

·        Interfaces in Java and Abstract Base Classes in C++.

·        Provides the important OOD concept of implementation hiding.

q       Reference Object and Value Objects

Reference Object

·              Only one object is permitted.

·              To see if two object handles refer to the same reference object,
compare object handles.

Value Objects

·        Multiple copies are allowed.

·        Compare their values.

q       Specialization (Classification) and Generalization  (Figure 3)

·        Beware! Class responsibilities can be confused.

·        Generalization is transitive.

·        Specialization is not.

q       "is-a"

    • Generalization

·        "is-a-kind-of", "is-a-type-of".

    • Car is a type of vehicle.

q       Specialization

·        "is-an-instance-of".

      • Bill smith is an instance of a student.

q              Qualified Association (Figure 3)

·        UML’s ways to deal with concepts such as Maps, Associative Arrays,
Dictionaries, etc.

 


Figure 3

 

q             Parameterized Class (Figure 4)

    • Generic programming or C++ templates (e.g. STL).
    • Code reuse among semantically similar families of classes.
      • Associative arrays, maps, dictionaries, etc.

 


Figure 4

 

q         Visiblity (Figure 5)

·        Simply is the Encapsulation and Information Hiding concept in OOP.

 Figure 5

Package Diagram (Figure 1)

·        Package diagrams provide a mechanism for dividing and grouping model elements (e.g., classes, use cases). In UML, a package is represented as a folder.


Figure 1: Package Diagram 

For a FREE UML Seminar on CD go to: http://www.rational.com/uml/index.jsp