Topic 17: UML Notation

Synopsis

• What is UML?
  
• Graphical Components of UML
  
• Use Cases
  
• Representing classes
  
• Representing inheritance
  
• Representing association
  
• Operations
  
• Representing aggregation
  
• Reference and Value Objects
  
• Constraints
  
• Interfaces and abstract classes
  
• Qualified Associations
  
• Representing other classlike entities
  
• Putting it all together
  
• Representing objects
  
• Representing object interactions: the Sequence Diagram
  
• Reading

What is UML?

• Unified Modeling Language – combines the methods of Booch, Rumbaugh(OMT) and Jacobson ("the three amigos")
  
• A (mainly graphical) notation that OO design methods can use to express designs, but not a method in itself.
  
• More precise than spoken language — less detailed than code
  
• "A language for:
  • Visualizing
  • Specifying
  • Constructing
  • Documenting

  the artifacts of a software-intensive system" (Booch et. al. 1999)

• Graphic notation + Semantic Rules. (Things / Relationships / Diagrams)

• A way of thinking about the relationships in an OO design.
   
• But not (by itself) equivalent to an OO design
   
• ...also need text to explain the reasons for the structure, the purpose of various components, and the general nature of the interactions

Graphical Components of UML

• Class Diagram
• Object Diagram
• Use case Diagram
• Sequence Diagram
• Collaboration Diagram
• Statechart Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram

Use Cases

• Based on a set of scenarios (typical usage patterns) connected by a common user goal
  
• Scenarios can be described as a series of steps

---

Get a Drink from the Drink Machine

1. Customer selects type of drink (e.g. "Krap Cola")
2. Customer presses button corresponding to selection
3. System displays amount of $ to insert
4. Users inserts money into slot
5. When user has inserted enough money system issues drink
6. User enjoys drink

Alternative: No drinks of selected type available
At step 2, system displays message "None Available, make another selection"
Allow customer to select new drink type

Alternative: Not enough change
User does not have enough change at step 4
System allows user to press "Cancel" button while waiting for correct change. Any coins already inserted are returned.
Return to step 1.

---

• The amount of detail depends on risk, time available, detail required. More risk means more detail.

  

• Diagram Elements:
  
  • An actor is a role that the user plays with respect to the system. The same person can take on different roles (hence be different actors).
  • Actors don't need to be human (even though they are shown as stick figures)
  • Actors carry out use cases
    
• Relationships extend the basic connection between an actor and a use case.

Representing classes^¤

• You already know how to represent classes^¤ in UML^¤
   
• They are rectangular boxes...
   
• ...labeled with the class^¤ name..
   
• ...and possibly with its attributes and operations (methods)

• That corresponds to the C++ code:

  class Vehicle
  {
  public:
  	Vehicle(void);
  	virtual bool Register(string regnum);
  	string GetRego(void);
  
  private:
  	string myRegNum;
  };
  

• Or with more detail...

Class Diagrams from different perspectives:

• Conceptual: diagram of concepts in the domain under study (does not necessarily match class names). Often used in the analysis phase.
  
• Specification: software interfaces, not implementation ("type" and "class")
  
• Implementation: interface and implementation

Representing inheritance ^¤

• You know how to represent inheritance^¤ in UML^¤
   
• The arrow goes from the derived class back to the base class
   
• This relationship is often called a generalization

• That corresponds to the C++ code:

  class Vehicle
  {
  public:
  	Vehicle(void);
  	virtual bool Register(string regnum);
  	string GetRego(void);
  
  private:
  	string myRegNum;
  };
  
  class Car : public Vehicle
  {
  public:
  	Car(string make, string model);
  	virtual bool Register(string regnum);
  	string GetDescription(void);
  
  private:
  	string myMake;
  	string myModel;
  };
  

Representing association

• Classes have various associations with each other (a customer makes an order; a bus has several wheels; a cake has many ingredients)
   
• A line connecting two classes shows association
  
• Each association has two association ends (or roles) and each end may be explicitly named with a role name.
  
• An association end also has multiplicity showing how many objects of that class participate in the relationship.

• Association may be further detailed with the use of arrows at either end to show navigability:

Operations

• Operations are the processes that a class^¤ knows how to carry out
  
  visibility name(parameter_list) : return_type_expression {property_string}
  
• visibility: +(public) #(protected) or –(private)
• name: a string
• parameter_list: comma separated parameters in the form:
  name: type = default_value
• return_type_expression: comma separated list of return types (can have more than one)
• property_string: indicates property values that apply to a given operation
  
  Example: + assignOwner( theOwner: Owner ) : bool

Representing aggregation^¤

• Aggregation is different, but related to association
  
• UML also has a stronger variety of aggregation, known as composition^¤
   
• The aggregation^¤ relationship is the most common and represents the relationship where one class^¤ has members^¤ belonging to some other class^¤.

  class StudentRec
  {
  public:
  	StudentRec(StudentId& ID, string name);
  
  	StudentID    GetID(void);
  	string GetName(void);
     void AddMark(Mark * theMark)
  	Mark GetAverageMark(void);
  
  private:
  	StudentID&    myID;
  	string myName;
  	Mark * myMarks;
  };
  

  
   

• The aggregation^¤ relationship ("has a") is represented by a line with a hollow diamond at the "owner" object
  
• The composition relationship uses a filled diamond.
  

  

Reference and Value Objects^¤
 

• There are two "sub-types" of aggregation^¤: reference objects and value objects
  
  
• If one class^¤ aggregates another by value it actually has a member^¤ of that other class^¤:
  
  
• Reference objects are usually stored as a reference or pointer; they are compared by their identities
  
  
• Value objects may often have multiple instances representing the same thing in the real world (e.g. Date object). They are usually compared by value (rather than identity).
  
  
• Value objects are often immutable (frozen)
  
  

Constraints

• Constraints specify additional limitations on attributes or relationships
  
• For example, the {ordered} constraint implies an ordering to target objects
  
• The {frozen} constraint implies an immutable value

Putting it together:

• Deleting a Polygon object would cause all its associated Points to be deleted.
  
• Deleting a Polygon object would not cause its associated Style object to be deleted
  
• An individual Point object may appear in only one Polygon or Circle at a time
  
• Point is a value object (why?)

Interfaces and Abstract Classes

• An interface class has an interface but no concrete implementation: a pure interface in Java or Abstract Base Class in C++
  
• The UML convention is to italicise the abstract class or method
  
• Alternatively, you can use the {abstract} constraint

class Window       // abstract base class
{
	public:
		virtual void toFront() = 0;
     virtual void toBack() = 0;
	};

class WindowsWindow : public Window
{
 public:
     void toFront();
     void toBack();
};

class X11Window : public Window
{
 public:
	     void toFront();
      void toBack();
};

class MacWindow : public Window
{
 public:
     void toFront();
     void toBack();
};

Qualified Associations

• A qualified association relates two classes based on a look-up or key value.
  
• Commonly associated with programming constructs known as associative arrays, maps and dictionaries.

class Order
{
 private:
     Map <OrderLine, Product> lineItems;
	public:
		OrderLine getLineItem(Product aProduct);
     void addLineItem(Number amount, Product forProduct)
	};

class OrderLine
{
 private:
     Number amount;
};

class Product
{
 public:
	     .
      .
      .
};

Representing other class^¤-like entities

• Templates (e.g. List<Type>) are represented as boxes with "dashed boxes" for the various template parameters
  
• A specific binding of a template class is known as a bound element

  

  template <class TYPE>
           	class List
  {
  public:
  	bool First(void);
  	bool Next(void);
  	TYPE GetCurrent(void);
  	bool InsertCurrent(const TYPE& newelem);
  	bool DeleteCurrent(void);
  
  private:
  	TYPE* myArray;
  	int   mySize;
  	int   myNextFree;
  };
  

• Actual classes^¤ specialized from a template (e.g. List<string>) are represented like templates in C++.

  template <bool>
           	class List<bool>
  {
  public:
  	bool First(void);
  	bool Next(void);
  	TYPE GetCurrent(void);
  	bool InsertCurrent(const TYPE& newelem);
  	bool DeleteCurrent(void);
  
  private:
  	long* myPackedArray;
  };

   

Putting it all together

• Of course, in a real design (even a simple one) you need to use most of these notations (and more) in the same diagram:

Representing objects

• In order to make clear the way in which a design is structured it is not enough just to show the class^¤ relationships
   
• It is often also important to show the actual objects that will be instantiated
   
• Object diagrams show a snapshot of the objects in a system at a particular point in time

Representing object interactions: the Sequence Diagram

• Another approach emphasizes the time-line of calls
   
• It is called an Sequence Diagram:

• Note that data is assumed to flow back up the arrows implicitly
   
• Can also "thicken" the object life-lines to indicate which object(s) are the focus of control at any point:

Reading

• Fowler (Chapters 1-6)