Introduction to the Unified Modeling Language (UML) Class Diagram
Visualizing the Problem Visualizing Design
Need for basic modelling?
Modelling helps you understand the problem and provide a basis for design.
You need to communicate your design ideas with colleagues, often before there is code.
Software engineers’ often sketch in rough UML – it’s faster than sketching in code and is a language most developers understand.
Quick way to evaluate and spot problems in your designs before committing to code.
COMP3297: Software Engineering 2
The UML Diagrams
The Unified Modeling Language provides:
diagrams that depict static structure without concern for time diagrams that depict dynamic behaviour
Current version, UML 2.5.1, was released in Dec 2017 and describes 14 diagram types.
Most modelling in a project can be done using just a few of the diagrams. Architects and developers typically use the class diagram, and the sequence diagram if needed.
COMP3297: Software Engineering 3
Classification of UML 2.5 Diagrams
BTW, this is a UML class diagram
COMP3297: Software Engineering 4
The key diagrams
Typically use Class Diagrams to model static structure.
They describes the types of objects in the system (the classes) and
the various kinds of static relationships among them.
They also show the attributes and, in design, operations of the classes
Mostly use Sequence Diagrams to model dynamic aspects.
In design, for example, to describe how objects collaborate to produce particular system behaviour.
COMP3297: Software Engineering 5
Object Oriented Analysis
UML Class Diagram and the Domain Model
What do we model here?
Analyse the problem. Find and model:
Conceptual classes (‘real world objects’ in the problem domain)
Associations between conceptual classes
Attributes of conceptual classes
(what the requirements suggest each class needs to remember).
Why build a domain model?
Many of the concepts and relationships we model in analysis will carry through into design and implementation. For example, it is the basis for your Model designs in Django.
COMP3297: Software Engineering 7
Example of a Domain model: ParknShop Point of Sales system Larman
Process Sale Epic
Domain object
Attribute Association
0..1
Records-sale-of
* 1..*
1
1
3 Works-on 111
Contained-in
1 Houses
1
1..*
Ledger
Product Catalog
1
Used-by *
Stocks
1..*
Contains
Product Description
itemID description price
11
1 for
Records- accounts-
Describes *
Sales LineItem
Store
Item
quantity
name address
1
Logs- completed
Captured-on
1..*
1
*
Sale
dateTime / total
Register
id
Customer
Cashier
id
Assuming the customer pays by cash here
Paid-by
11
Is-for
0..1
CashPayment
amountTendered
COMP3297: Software Engineering
8
Basics of the UML Class
Class name
Attributes
Operations
These are added as part of the design process
Indicate public, protected or private accessibility of operations and attributes with access modifier prefixes {+, #, -}, or by custom colours and icons as here.
COMP3297: Software Engineering 9
Compartments can be omitted – good for sketching
Student
Student
– student_number – surname
– given_name
– date_of_birth
– email
COMP3297: Software Engineering 10
Concept to Implementation
Attributes. Values represent Domain object’s “state”
concept
Class name
reg_number assigned_route_name
Visualized as a UML class
An abstraction of the real world concept
Ultimately represented in code in our implementation. Examples:
class ShuttleBus:
def __init__(self, reg_number, route):
self.reg_number = reg_number self.assigned_route_name = route
#…
or
class ShuttleBus(models.Model):
reg_number = models.CharField(max_length=8, unique=True) assigned_route_name = models.CharField(max_length=10)
#…
COMP3297: Software Engineering 11
Associations
Use associations to represent relationships between instances of classes to indicate some meaningful and interesting connection that we need to remember.
12
Account
1..* 1, 2 holder
Customer
Can consider the optional end name (“holder”) as a label for the cardinality constraint (1, 2). An attribute of the class furthest away from where it is written.
COMP3297: Software Engineering
Multiplicity
As on the previous slide, the end of the association may show multiplicity (and, we`ll see later, navigability)
That is, the number of instances that can validly be associated with another. Often at a particular moment rather than over a span of time, depending on the info needs.
Examples:
1 0..* * 1..* 4 1..4
these are equivalent
* is an unbounded upper limit read as “1 or more”
The default is “1” if not explicitly specified
They are domain constraints that ultimately may be reflected in our software
COMP3297: Software Engineering 13
Continuity in structure
Base the structure of the software on the structure of the problem domain
This is the OO “reduction of the representation gap”
In the end, the static structure of the design will reflect the static structure of the problem.
But remember, the domain objects are not software objects. They are the real-world concepts. During analysis we model only the problem domain.
Nothing from the software domain is modelled. For example, no database, no helper classes, etc.
And some conceptual classes may be discarded – not all of the conceptual classes become incorporated into the software design.
COMP3297: Software Engineering 14
Conceptual classes
Some of the domain objects represent real, physical entities in the domain
Example:
But some equally important domain objects represent concepts rather than physical entities
Example:
The Domain Model captures both types
COMP3297: Software Engineering 15
a domain model for an airline reservation service might include objects like aircraft, passenger, etc.
reservation, schedule, etc.
Building the Domain Model
Steps
Work through user stories/requirements and:
Identify conceptual classes
In iterative development, often model only the stories being developed in the current iteration, building on those developed previously.
The model is built incrementally.
Add associations and constraints
Add attributes
COMP3297: Software Engineering
17
How to Identify Conceptual Classes
Two common techniques. Use both together:
1. Use a class category list. This is a list of common categories that often form conceptual classes.
2. Identify nouns or noun phrases in requirements descriptions, remembering that not all of these will be good candidates – they may just be attributes, aliases, an instance of a class, not of direct interest in this iteration, or too vague.
COMP3297: Software Engineering 18
Category List – partial example
Class Category
Example
Physical objects
Register (the machine at checkout), ShuttleBus, Item
Specifications or descriptions of things
ProductDescription
Places
Shop, Depot
Transactions
Sale, Reservation, Order
Records of finance, work, etc.
Receipt, MaintenanceLog
Other categories include:
Transaction line items, product or service the transaction is for, roles of people, containers of things, things in a container, collaborating systems, financial instruments, schedules.
COMP3297: Software Engineering
19
Associations – only what’s useful
Usually many connections between domain concepts. Modelling them all leads to a very cluttered and unclear visual model. The important associations will be difficult to see.
To keep the class diagram clean and useful, model only “meaningful or interesting” connections
Usually means knowledge of a relationship needs to be remembered for some time.
For a management tool for agile, do we need to remember the relationship between a PBI and the Development Team members who collaborated to estimate its size?
It is not wrong – the relationship does exist – but showing it would complicate the domain model for little benefit.
How about PBI and Product Backlog?
P
O
COMP3297: Software Engineering
20
Common Categories of Useful Associations
X is a part of Y
X is contained in Y
X is recorded/logged/captured in Y X belongs to Y
Don’t waste too much time on this – the conceptual classes are more important than the associations.
Keep the model simple: focus on “need to know”, then add extra associations if they will help understand the model
COMP3297: Software Engineering 21
These are generally useful. There are many other possibilities – owned by, described by, etc.
Attributes
What the requirements suggest we need to remember.
Common mistake – modelling a complex concept an attribute. Better to model it as a conceptual class and associate it with the original class.
Project O PProductBacklog
11
But can also make the mistake in the other direction. If a conceptual class does not have interesting behavior or attributes of its own, it may be better modelled as an attribute.
Title is just simple text – it would be wrong to model it as a class.
COMP3297: Software Engineering 22
Project
title
title product_backlog …
Attributes – keep simple
Should be simple value objects
Primitive predefined types and user- defined types that lack identity
Equality tests based on value, not identity
Examples: Numbers, strings, time, enumerations.
But some types for which identity is not meaningful may not be good attributes if they are:
– composed of separate sections and we need to access them (like Address), – have associated operations such as validation (like HKID),
– is a quantity with a unit (like Money),
– has attributes of its own.
If in doubt, make it a class
In code we may implement associations with attributes (they are both “properties”),
but we are not interested in implementation issues during analysis
COMP3297: Software Engineering 23
class ShuttleBus:
def __init__(self, reg_number, route):
self.reg_number = reg_number self.assigned_route_name = route
#…
class ShuttleBus(models.Model):
reg_number = models.CharField(max_length=8, unique=True) assigned_route_name = models.CharField(max_length=10)
#…
May discover that Route is a significant concept. Then model as a class associated to ShuttleBus Association implemented as reference or by foreign key
Example
COMP3297: Software Engineering 24
Process Sale Epic
Records-sale-of
COMP3297: Software Engineering
25
0..1
Ledger
* 1..*
1
1
3 Works-on 111
Contained-in
1 Houses
0..1
Product Catalog
1
1..*
Contains
Product Description
No references or foreign keys shown as attributes.
They are implementation details implied by the associations.
quantity
11
1 for
Records- accounts-
Describes *
itemID description price
1
Used-by *
Stocks
1..*
Sales LineItem
1
Logs- completed
Captured-on
Store
name address
Item
1..*
1
*
Sale
Register
dateTime / total
id
Paid-by
11
Is-for
CashPayment
amountTendered
Customer
Cashier
id
Association Classes
It’s common, particularly with many-to-many relationships, that we have data that belongs on the relationship rather than either of the classes involved.
SkillLevel?
Date/time of reservation?
COMP3297: Software Engineering
26
Association Classes
We can add a class to hold a corresponding attribute and resolve the many-to-many relationship into two one-to-many relationships.
27
But there are some problems with this approach:
– Resolving into two one-to-many relationships makes the important relationship, which is between GameCharacter and Skill, more difficult to see.
–
Interpreted literally, the model allows a GameCharacter to have many LevelAttained objects for the same Skill. That is not the intention here, although it could be fine for the Reservation example.
–
UML has an Association Class to more accurately model such cases.
COMP3297: Software Engineering
Association Classes
Association Class
LevelAttained is now an Association Class connected by a dashed line to its association.
It prevents an GameCharacter from having multiple levels for the same Skill. Also, the important many-to-many relationship is easy to see again.
Both representations are common and you’ll see both. The earlier version is
used more frequently when sketching informally.
COMP3297: Software Engineering 28
Building the Domain Model: Exercise 1
Analyse the user story and build the partial domain model
For the drone delivery system:
Order Supplies: As a clinic manager I want to view a list of supplies available for drone delivery so that I can order items.
Confirmation
view by category
see items of supplies page by page
see details and a thumbnail image for each item of supplies specify quantity, and add to order
order recorded
…
COMP3297: Software Engineering 30
Abstraction in the Domain Model: Generalization-Specialization
The UML is a rich language and there are many additional class diagram notations.
Class diagrams are used a lot. When sketching ideas in agile development, we mostly use only the key notations – those already introduced last week – and the Generalization-Specialization notation introduced here.
The less well-known notations are not used often in agile development. It would defeat the purpose which is better communication and collaboration.
In analysis, often discover concepts that are similar yet also have differences.
At ParknShop, every completed Sale must have a payment.
Payment
Sale
amount
There are several ways a customer may make the payment.
CashPayment
amount
ChequePayment
amount
CreditPayment
amount
As a cashier I want to take payment so that I can complete the customer’s sale
11
As a cashier I want to take cash payment…
As a cashier I want to take cheque payment… As a cashier I want to take credit card payment…
COMP3297: Software Engineering
…VISA payWave…Apple Pay…EPS…Octopus… 32
We can organize the concepts into a generalization- specialization (superclass-subclass) hierarchy
Similarities are pulled up into a superclass, differences stay in the subclasses
Why?
We use generalization in the domain model to express and understand concepts in more general, abstract terms.
Can reason about Payments in general, and then only the differences for specific kinds of payments
Often become software class hierarchies in design and implementation.
COMP3297: Software Engineering 33
Generalization
UML Superclass represents a more general concept
Subclass represents a more specialized concept.
This is an Abstract class (in UML, the name is in italics) – every actual payment must be an instance of one of the subclasses
COMP3297: Software Engineering
34
Relationship indicated in the UML class diagram by a hollow triangle
The key to getting the relationship right is set membership.
IsA Rule
The class Payment is a generalization of CashPayment because, conceptually, every CashPayment is a kind of Payment.
All members of the set CashPayment are also members of the set Payment
So, if some property of the domain holds for an arbitrary Payment it must hold for an arbitrary CashPayment too.
Payment
Payment
CreditPayment
CashPayment CreditPayment
If Payment is non-abstract
ChequePayment
CashPayment
ChequePayment
COMP3297: Software Engineering
35
If Payment is abstract
100% Rule
All of a superclass’s definition should be applicable to its subclasses. The subclass must conform to 100% of the superclass’s attributes and
associations.
To get it right:
A good subclass must conform to both the IsA rule and the 100% rule
COMP3297: Software Engineering 36
When to Specialize: Relevant and Useful?
Should we define a subclass? Consider this example for the
ParknShop POS system
Given current requirements
Partition into subclasses when:
The subclass has additional attributes of interest in this domain The subclass has additional associations of interest in this domain
The subclass concept is handled differently or behaves differently than superclass or other subclasses in ways of interest…
…while still conforming to IsA and 100% rules
û
?
Legal? Useful?
COMP3297: Software Engineering
37
38
Good generalization
Common attribute
Common association
Handled differently
Different associations
COMP3297: Software Engineering
Building the Domain Model: Exercise 2
40
Exercise
Departmental Teaching Management System – used to manage allocation of teaching staff to courses for an academic year.
Two kinds of courses are offered: Advanced Courses and General Courses. Each course has a course code, course name, credit value and a total course enrolment quota.
Advanced Courses are taken only by CS majors and enrolment is small. Each course is taught by a single Instructor without TA support. In contrast, General Courses are open to all students in the university and enrolment is high. They are taught by a team consisting of an Instructor and at least one Student TA.
Teaching staff (Instructors and Student TAs) are identified by their University ID and their name. Student TAs are recruited to work as a member of only one teaching team per year to avoid excessive impact on their own studies. Each teaching team teaches a single General Course per year.
Construct a domain model for the requirement to establish courses and assign
teaching staff to them.
COMP3297: Software Engineering