Topic 17: UML Notation
Synopsis
- Class Diagram
- Object Diagram
- Use case Diagram
- Sequence Diagram
- Collaboration Diagram
- Statechart Diagram
- Activity Diagram
- Component Diagram
- Deployment Diagram
- 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 required increases with an increase in the risk for that use case.
- 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. These are sets of scenarios tied together by a common user goal.
- Relationships extend the basic connection between an actor and
a use case e.g. <<include>> where one use case includes another... but don't spend too much time detailing these diagrams.
- Your time is better spent capturing the essence of the situation (probably in text) clearly and simply, rather than drawing copious use case diagrams.
- 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)
Class Diagrams from different perspectives:
- Conceptual Modelling: diagram of concepts in the domain under study
(does not necessarily match class names). Often used in the analysis phase.
- Software Implementation: used as a tool to design the system. Elements of the diagrams relate directly to elements in a software system.
- 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;
};
- 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 are the processes that a class¤
knows how to carry out (usually its methods)
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: the return type of the operation
- property_string: indicates property values that apply to a given operation (e.g. {query} indicates that the operation does not change the state of the system.)
Example: + assignOwner( theOwner: Owner ) : bool
- There are two "sub-types" of aggregation¤:
reference objects and value objects.
- Reference objects are usually stored as a reference or pointer; they
are compared by their identities.
- If one class¤ aggregates another by value it actually has a member¤ of that other class¤.
- 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). If you want (for instance) a Date object to store a date other than the one you curently have, do not change the value of the object you currently have, make a new Date object with the correct date.
- In your diagrams, use composition when associating with a value object. You can also label the object <<value>>.
- 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?)
- 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();
};
- 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:
.
.
.
};
- 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;
};
- Of course, in a real design (even a simple one) you need to use most
of these notations (and more) in the same diagram:
- 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
- Another approach emphasizes the time-line of calls
in a 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:
- Note that these diagrams are not good for understanding the flow of control (this is not their purpose). They are intended to show the interaction between objects in a program.
This material is part of the CSE2305 - Object-Oriented
Software Engineering course.
Copyright © Alan Dorin, Jon McCormack & Damian Conway, 1998–2006. All rights
reserved.