The Class Model
The Class Model
An Introduction to UML
The Logical
Model
by Geoffrey Sparks
All material (c) Geoffrey Sparks 2000
www.sparxsystems.com.au
Table of Contents
Introduction to UML
The Unified Modelling Language (UML) is, as its name implies, a modelling language
and not a method or process. UML is made up of a very specific notation and the
related grammatical rules for constructing software models. UML in itself does not
proscribe or advise on how to use that notation in a software development process or as
part of an object-oriented design methodology.
UML supports a rich set of graphical notation elements. It describes the notation for
classes, components, nodes, activities, work flow, Logicals, objects, states and how to
model relationships between these elements. UML also supports the notion of custom
extensions through stereotyped elements.
The UML provides significant benefits to software engineers and organisations by
helping to build rigorous, traceable and maintainable models, which support the full
software development lifecycle.
This paper focuses on the logical or static model.
You can find out more about UML from the books mentioned in the suggested reading
section and from the UML specification documents to be found at the Object
Management Groups UML resource pages: http://www.omg.org/technology/uml/ and
at http://www.omg.org/technology/documents/formal/
- for large systems the maintenance burden of code which has direct access to data
elements in many places is extremely high.
AccountItem
+ Notes: string
+ Order: OrderID
+ OrderBalance: Currency
+ OrderStatus: string
+* GetItemBalance() : Currency
+ GetOrderID() : OrderID
Customer:Fred Smith
Class Features
Note that the class has three distinct areas:
1. The class name (and stereotype if applied)
2. The class attributes area (that is internal data elements)
3. The behaviour - both private and public
The following image shows these three areas (Attributes in red, Operations in green):
Customer
+ Account: CustomerAccount
+ Address: string
+ City: string
+ Country: Country
+ CustomerID: string
+ FirstName: string
+ LastLogin: string
+ Login: string
+ Password: DateTime
+ Preferences: CustomerPreferences
+ Surname: string
+ Zip: Zip
+ AddCustomer() : bool
+ DeleteCustomer() : bool
+ GetAccount(dsd) : CustomerAccount
+ GetCustomerAsXML() : string
+ GetPreferences() : CustomerPreferences
+ UpdateCustomer(Fred) : bool
Symbol Meaning
+ Public
- Private
# Protected
$ Static
/ Derived (attribute - non standard)
* Abstract (operation - non standard)
A CASE tool will allow you to set numerous attribute details, as in the example below:
Interfaces
Interfaces are abstract classes with a behavioural component only. They specify an
operational contract that an implementor agrees to meet. For example, an interface may
be defined called IPerson with methods to access Address and Age as in the example
below:
<<interface>>
IPerson
+ GetAddress() : Address
+ GetAge()
+ SetAddress()
+ SetAge()
Relationships
Logical elements may be related in a variety of ways. The following are the most
common:
Association
Association relationships capture the static relationships between entities. These
generally relate to one object having an instance of another as an attribute or being
related in the sense of owning (but not being composed of). For example a Salesperson
has an association to their customers (as in the image below), but a salesperson is not
'composed of' Customers. Both ends of the association link may assume a 'role' as part
of the association - for example the Salesperson may assume the role of 'Carpet
Salesperson' if there are special conditions that apply to that role.
Salesperson Customer
1 0..n
Aggregation
Aggregation relationships define whole/part relationships. For example, a train journey
may be composed of many journey legs. The overall journey then aggregates or is
composed of the separate legs. The stronger form of aggregation is composition and
infers that a class not only collects another class, but is actually composed of that
collection. The example below indicates that a Store aggregates or collects together a
number of Departments and that there is a whole/part relationship - that is the store is
made up of (in part) this collection of departments.
Store Departments
Inheritance
Inheritance describes the hierarchical relationship between classes. It describes the
'family tree'. Classes may inherit attributes and behaviour from a parent class (which
may in turn be the child of another class). This tree of inherited characteristics and
behaviour allows the designer the ability to collect common functionality in root
classes (ancestors) and refine and specialise that behaviour over one or more
generations (children). Scope specifiers (public, protected and private) determine which
elements may be inherited and which are not visible. The following diagram illustrates
one level of inheritance:
Person
Customer Salesperson
Dynamic
Dynamic relationships are the messages passed between classes (objects at run time). A
Sequence Diagram illustrates this message passing and the sequence in which it occurs.
The image below shows the sequence of messages passed over time when a user logs
on to an on-line book store. These model elements have an association to each other
reflected at run time by the passing of messages to each other.
Login
ValidateUser
CheckUserDetails
[UserDetails]
Validate
[Result]
A customer will be required to login in to the book store prior to browsing and making
selections.
Requirements
These specify what it is the class should be capable of doing, that is what information is
persisted, what behaviour is supported and what relationships are required. For
example, a person class may require the storage of Name, Age, Sex, Birth date etc.
States
Classes may be viewed as having different states over time (eg. A Customer is
Browsing, Selecting, Buying & etc.). UML allows the designer to model these states
using State Charts. These define the legal states an object may be in together with the
transitions, conditions that initiate transitions and guard conditions that prevent
transitions if not met.
Scenarios
Scenarios are descriptive textual (or diagrammatic) representations of how a class is
used over time in a collaborative manner.
Putting it together
+ AddCustomer() : bool
+ DeleteCustomer() : bool
+ GetAccount(dsd) : CustomerAccount
+ GetCustomerAsXML() : string AccountItem
+ GetPreferences() : CustomerPreferences + Notes: string
+ UpdateCustomer(Fred) : bool + Order: OrderID
+ OrderBalance: Currency
+ OrderStatus: string
+* GetItemBalance() : Currency
1 + GetOrderID() : OrderID
1
Customer Preferences
This second example illustrates similar elements, including an inheritance link from
Publisher to Company (indicating that a Publisher is a kind of Company).
Book Publisher
Catalogue
+ Author: Author + ContactID: string
+ BookList: string + DatePublished: string + Phone: string
+ CatalogueDate: Date + Genre: string + PublisherName: string
+ Price: string
+ AddBook() : bool + Title: BookTitle n 1 + AddPublisher()
+ DelBook() : bool + DelPublisher()
+ GetBook() : Book + AddBook() : bool + ModifyPublisher()
+ GetFilterSet(Filter) : BookList + CancelOrder() : long
+ GetQtyInCatalogue() : long + DeleteBook() : bool
+ Modify Book() : bool + GetQtyOnHand() : long
+ OrderBook() : long
Author Title
+ AlternateTitle: string
+ AuthorBirthDate: Date
+ ISBN: string
+ AuthorName: string
+ Keywords: string
+ Biography: string
+ Title: string
+ Comment: string
The diagram below illustrates the states an order being shipped may go through - from
being ready to ship, in transit, delivered or returned.
ReadyToShip
Start
Order Shipped
InTransit Returned
Failed Delivery
Delivered
Deliv ered
End
Packages
As the class model develops, classes (and objects and interfaces) may be organised into
logical units or packages. These collect related elements (and in some implementations
will govern the visibility of operations (and attributes) by elements outside the package.
The diagram below illustrates the collection of classes into packages:
Recommended Reading
Doug Rosenberg with Kendall Scott ,Logical Driven Object Modeling with UML.
ISBN:0-201-43289-7. Publisher: Addison-Wesley