Developing the Structural

Model
Dr Kristin Stock

Where
are we
up to?
Behavioural
models next time.

Outline
More on class diagrams:
Different types of associations
Association classes

More on object diagrams.

Package diagrams.
Composite structure diagrams.
Ensuring consistency in class diagrams.
Case study.

Classes
In a class diagram, the objects in the system
(concepts in the conceptual model) are
represented as classes.
A class is a group of individual objects.
E.g. the class road, person, customer, cake.
In UML, we create class diagrams to show the
classes involved in a system, and their
interactions.

Classes from the Real World

We create classes to model categories of objects
in the real world.
Which objects?
How much detail?
It all depends on the application. What is its
purpose?
Which objects are needed to support that
purpose.

Interview Questions for Finding

Classes
What people and organizations does the system
keep track of?
Customer, card holder, board member

What events and transactions does the system keep

a record of?
Sale

What products and services does the system keep a

record of?
Checking account (product), check returns (services)

Challenge Questions
Is it important that the business track this class?
e.g. Do you actually keep track of your customers?

Do apparently similar classes vary in attributes,

operations, methods or relationships?
If not, they are one class

Is a candidate class just information about something

else?
May be an attribute, not a class

Is one class name an alias for another?

Use one class record the alias in the glossary
e.g. customer = client

Classes, Attributes, & Operations

Classes
Templates for instances of people,
places, or things
Attributes
Properties that describe the state
of an instance of a class (an object)
Operations
Actions or functions that a class
can perform

Attributes
Characteristics of a class.
Often in a textual descriptions, they
are adjectives (the red car, the
chocolate cake, the fast delivery).
It is not always clear whether
something should be modelled as
an attribute or a class:
Make it a class if it has other
attributes or operations of its own,
otherwise an attribute.

camelCase, singular

Attribute Appendages
Attributes can be derived
Preceded with a slash (/)
e.g., age is derived from date of birth

Visibility of an attribute:
Restricts access to attributes to ensure consistency
Public attributes (+): visible to all classes
Private attributes (-): visible only to an instance of the class in which
they are defined
Protected attributes (#): visible only to an instance of the class in
which they are defined and its descendants

Example
House
Street
+streetNumber
-houseType
-buildDate
+/age
-owner
#rebuild
#renovate

DetachedHouse

is in
0..*

streetType
oneWay
suburb

Which classes can

access:
streetNumber
houseType
BuildDate
Age
rebuild

Operations

Things that can be done with/to a class, or its

own inherent behaviour.
Often in a textual descriptions, they are verbs
(bake a cake, sell a cake, deliver a cake).
Again, a word of caution some verbs are not
operations, but associations between classes.

Operation Types
Common operations are not shown
Create or delete an instance
Return or set a value

Types of operations:
Constructorcreates an object
Querymakes information about the state of an object
available
Updatechanges values of some or all of an objects attributes
Destructordeletes or removes an object

Relationships
Associations between classes.
Indicate some link or dependency.
There are many kinds of associations, usually they
can be described with a verb (has, contains, is part
of, etc).
Should be able to read through the diagram with
classes and associations.
is in
house

is in
street

city

Example

House
streetNumber
houseType
buildDate
owner
rebuild
renovate

Street
is in
0..*

streetType
oneWay
suburb

Multiplicities
Department
1

Child

Zero or more:
An employee has zero to
many children

Employee

One or more:
A boss is responsible for
one or more employees

0..*

Boss
1

Exactly one:
A department has one and
only one boss

Employee
1

Boss

1..*

Rules Regarding Multiplicity

Multiplicity Indicator

Meaning

0..1

Zero or one

0..*

Zero or more

Zero or more (an alternative to 0..*)

1..*

One or more

One and only one

Exactly n, as in 4

a..b

From a through b, as in 1..5

Types of Relationships in
UML
Dependency
Association:
Generalisation
Aggregation
Composition

Dependencies
Indicates that one class uses the other.
This is the most general type of relationship
better to be more specific if possible, with an
association (including name and multiplicity),
generalisation, composition or aggregation.
More common in some other types of diagrams

Associations
Binary Associations
An object of one class is related to an object (or objects)
of a different class
e.g. each Case object is associated with Payment
objects

Reflexive (or self-referencing) Associations

An object of a class is associated with other objects of
the same class
e.g. one employee (the manager) manages other
employees (team members)

Example

House
streetNumber
houseType
buildDate
owner

Street
is in
0..*

streetType
oneWay
suburb

rebuild
renovate
intersects with
What kind of multiplicity might the
intersects with association have?

Redundant Associations
A shortcut that associates two classes that have
an indirect association is redundant
These are usually best removed
Unless they specify a different business rule to the
indirect association
Customer

is billed

Invoice

purchases

is for

Product

Generalization Associations

Generalisation means:

is a
is a type of
subclass
subtype

Generalization denotes inheritance

Properties and operations of the superclass are valid for the sub-class
Depicted as a solid line with a hollow arrow pointing at the superclass

Example
House
Street
+streetNumber
-houseType
-buildDate
+/age
-owner

is in
0..*

streetType
oneWay
suburb

subtypes
inherit
attributes
and
operation
s

#rebuild
#renovate
ResidentialCollec
tor
DetachedHouse

ResidentialAcce
ss
SuburbanCollec
tor

Modeling Generalization
Why model generalization?
Reduced redundancy in the requirements
Generalized classes can be reused for future specialized
classes

Rules:
The specialized class inherits all the attributes, operations
and relationships of the generalized class
The specialized class may add attributes, operations and
relationships
The specialized class may have polymorphic methods
Multiple inheritance is possible (but not supported by all
languages)

Generalization in the UML

FundAccount
and
CashAccount
would inherit
all the features
of
InternalAccoun
t

InternalAccount

FundAccount

Generalized
Class

CashAccount

Specialized
classes

Aggregation and Composition

Associations

Aggregation and Composition mean:

is part of

Aggregation denotes a logical a-part-of relationship

Composition denotes a physical a-part-of relationship

Model Whole/Part Relationships

Aggregation and composition describe the relationship

between a whole and its parts
If a part can belong to more than one whole, and
continues to exist if the whole is destroyed, model as
aggregation
Collection, list, group

If the part is owned by the whole and ceases to exist if

the whole is destroyed, model as composition
composed of, component

If in doubt, use aggregation

Aggregation in the UML

An unfilled diamond indicates the whole
end of the relationship
ProfessionalAssociation

Inventory

Product

Company

Composition in the UML

A filled diamond indicates the whole end of
the relationship
Vehicle

Order

LineItem

VehiclePart

Composite Structure
Diagram
Another way of showing composition from UML 2
This example shows component parts in a vehicle
whole
Vehicle

attached to

Wheel
2

Axle
1

Generalisation vs Aggregation vs
Composition vs Association
For generalisation, it must make sense to say x is
a type of y
For aggregation and composition, it must make
sense to say x is a part of y
If x can survive without y, it is aggregation,
otherwise composition.

If neither generalisation or aggregation, then

unadorned association.

Which is which?

Leg Body
Knee Leg
Leg Limb
Kneecap Knee
Cracked Kneecap
Kneecap
Cyclone Natural
Disaster
Cyclone Bush Fire
Cyclone Casualties
Cyclone Storm
Soldier - Army

Generalisation
Association
Aggregation
Composition

Association Classes
Common in many-to-many relationships
Used when attributes about the relationship between two
classes needs to be recorded
Students are related to courses; a Grade class provides an attribute
to describe this relationship
Illnesses are related to symptoms; a Treatment class provides an
attribute to describe this relationship

Example
House
Street
+streetNumber
-houseType
-buildDate
+/age
-owner
#rebuild
#renovate

is in
0..*

1..3

streetType
oneWay
suburb

HouseInStreet
What
might
go
here?

Object Diagrams
Class diagrams with instantiated classes
Example: instead of a Doctor class, create an
actual doctor, say Dr. Smith
Place values into each attribute

Used to discover additional attributes,

relationships and/or operations or those
that are misplaced

Example Object Diagram

Modeling Object Links with

Object Diagrams
Sometimes an object diagram can help to show
requirements better than class diagrams alone
e.g. where classes have multiple associations
Here, a transfer has associations with two different
credited to
accounts
+receivingAccount

Account

Transfer

debited from

+sendingAccount

Object Diagrams in UML

The names inside the rectangle are of objects, not
classes
Object names are underlined
The full format is object-name : class-name
e.g fromAccount : Account

The object name can be omitted

A relationship between objects is known as a link, as
opposed to an association
Link names should be underlined

Object Diagram Example

Here, the links between a single (anonymous)
Transfer object and two (named) Account object
are described
:Transfer

debited from

fromAccount:Account

credited to

toAccount:Account

Grouping Classes into Packages

Use packages if there are many classes

A package may contain other packages
Put all of them on a single diagram
Apply a suitable grouping
e.g. flavours of business classes
People and
Organizations

Products and
Services

Events/
Transactions

The Package Diagram

A large package with the classes inside
Keep it simple - do not include class relationships in
these diagrams
Except perhaps generalization

Products and Services

DigitalCellPhone

CallReturn

pkg HDMv 2 Ov erv iew

Application Schema
HDM_Core
Application Schema
HDM_Administrativ eAreas
+ AdmininstrativeAreaType
+ AdministrativeArea

Application Schema
HDM_Surv eys

+ CoreElements

+ SurveyObservations

+ FeatureTypeCatalogue
import

import

+ MetadataProfile

+ SurveyPlans

+ MetadataStructures (to be removed when metadataprofile is complete)

+ PresentationRules
+ VersionAndAudit
import

import

Application Schema
HDM_PlaceNames

+ HeightDatum

import

+ DisplayPoint
import

+ PlaceName

Application Schema
HDM_Geodesy

import
import
Application Schema
HDM_Topography

Application Schema
HDM_StreetAddresses

+ GeneralFeature

Application Schema
HDM_RightsRestrictionsResponsibilities

+ Address
access

+ AddressGeocode

+ AnticipatedLifecycleStage

+ GeocodeType

+ Interest

+ Easement

+ TopographicFeature

+ InterestRelationship

+ TopoPointElement

+ InterestRelationshipType

+ TopoSimpleCurveElement

+ InterestType
import

+ TidalInterface

+ TopoCompCurveElement

+ InterestHolderType

+ CoexistingEstate

+ TidalHeight

+ Road

+ Tank

+ InterestHolder

Application Schema
HDM_Cadastre

+ TidalGaugeMetadata

+ Railway

+ RouteSegment

+ InterestGeometry
access

+ InlandWaterFeature

+ Route

+ InterestFunction

+ CoexistingEstateType

import
Application Schema
HDM_TidalRealm

+ EarthSurface

+ TopoSurfaceElement

+ LegalDocument

+ Utility

+ LifecycleStage
+ RelationshipTypeExists

+ PrimaryEstate
+ PrimaryEstateType
+ SecondaryInterest

import

+ SecondaryInterestLifecycle

import

+ SecondaryInterestType

import

+ Title
+ CadastralLite
+ Property

import

Application Schema
HDM_Nativ eTitle
+ IndigenousLandUseAgreements
+ NativeTitleFutureActs

Application Schema
HDM_Admininstrativ eInterests

+ NativeTitleApplications

+ AdmininstrativeInterest

+ NativeTitleDeterminations

+ AdministrativeInterestType

+ NativeTitleTenureOpinions

Application Schema
HDM_Env ironmentalInterests
+ EnvironmentalInterest
+ EnvironmentalInterestType

pkg PackageDependencies
Application Schema
HDM_RightsRestrictionsResponsibilities
Leaf
Nativ eTitleApplications

+ AnticipatedLifecycleStage
+ Interest

+ ApplicationDocument

+ InterestFunction

+ ApplicationLifecycle

+ InterestGeometry

+ ApplicationType

+ InterestHolder
+ InterestHolderType

+ RegisterOfNativeTitleClaimsRegistrationLifecycle
+ Application

Leaf
IndigenousLandUseAgreements

import

+ InterestRelationship
+ InterestRelationshipType

import

+ IndigenousLandUseAgreementLifecycle
+ IndigenousLandUseAgreement
+ Surrender

+ InterestType
+ LegalDocument
+ LifecycleStage
+ RelationshipTypeExists

access
Leaf
Nativ eTitleDeterminations

import

(from ICSM)

+ DeterminationType
+ NationalNativeTitleRegisterLifecycle

import

import

+ Determination
+ NativeTitleInterest
+ NativeTitleAbsence

Leaf
Nativ eTitleFutureActs

+ DeterminedNativeTitleRight
+ DeterminationOutcome

+ FutureActLifecycle
access

+ FutureAct
+ RightToNegotiate
+ CompulsoryAquisition

Leaf
Nativ eTitleTenureOpinions
+ AssessmentOrExtinguishmentCategory
+ NativeTitleExtinguishmentOpinionLifecycle
+ NativeTitleExtinguishmentOpinion

Optimizing Consistency in the

Requirements Documentation

Assigning Attributes to Classes

Ensure a candidate attribute is not already (or could

be) a separate class
It if is, it will be an association, not an attribute

Ensure that the attribute needs to be applied to each

object, not have the same value for the whole class
It could be a class (static) attribute

List attributes as far up a generalization hierarchy as

possible
So they can be inherited by specializations

Derived Attributes
Can be derived from other parts of the model
Important not to store values that should be calculated to
avoid data integrity problems
e.g. an age attribute should be derived

Indicated by a forward slash

/derived attribute

e.g. a line item total might be derived from unitPrice and

quantity attributes
Document somewhere how it can be derived, e.g.
/lineItemTotal = unitPrice * quantity

Attribute Notation
The full notation for an attribute in UML follows the form
attributeName:attributeType [multiplicity] = default

Only the name is essential for analysis

Both name and type required for design

Various combinations are possible

Examples might be
color : String
middleInitials : Character [0..2]
creditPoints : int = 15

Attribute Types
These may be any of the following:
User defined value type
e.g. PhoneNumber
A generic, complex data type (has its own attributes)
Not an association with a business object (entity class)

A unit of measurement
e.g. Kilometre (spelling to match coding guidelines!)
Can be assumed at the analysis stage
Will need to be defined more specifically at design time

A data type supported by the target programming language

Common Programming Data

Types
Integer
A whole number (no fractions)

Boolean
True/False, yes/no

Character
A single (Unicode) character

String
Text any string of characters

Float / Double / Decimal

A decimal number

Date / Timestamp
A specific date and time
158.225 Systems Analysis and Design 2014

51

Meta-Attributes
Attributes of attributes
Verification rules and other attribute properties

Type, multiplicity and default values are all meta-attributes

So is the definition of an attribute as being derived
These are part of the standard attribute notation
Other meta-attributes will need to be recorded more
informally
Can add a constraint (in braces) to an attribute
e.g. accountName : String {not null}

Meta-Attribute Examples
Required (not null)
Does the attribute always have to have a value?

Uniqueness
Does an attribute have to have a unique value, like a primary key?

Acceptable range of values

e.g. number of hours worked in a day cannot be less than zero or exceed 24

List of acceptable values

e.g. sex can only be male or female

Accuracy
e.g. rounding of floating point values

Length
e.g. the maximum size of a text (String) attribute

Dependencies on other attributes

e.g. one date value might have to occur after another (outward flight occurs before inward flight)

Attributes of a Class
BankAccount

Derived attribute

accountNumber : Integer
accountName : String {not null}
balance : Money = 0
/availableBalance : Money
overdraftLimit : Money
openedOn : Date

A BankAccount class with attributes

constraint

Default value

Is It An Attribute?
If a concept is not represented as a number
or text in the real world, it is probably a
class, not an attribute
Are these all attributes?
Qualification
level : Integer
name : String
institution : String

Operations
An activity that pertains to a class and is consistent
across use cases
e.g. a CashAccount class might have a WithdrawFunds
operation

Rarely added at the business analysis stage

Increasingly important as we move towards design
If an operation applies to all subtypes, add it to a
generalization
e.g. all types of Account
Specializations may use polymorphic methods

Operation Notation
The full notation for an operation in UML follows the form
operationName(argument1:argument1Type,
argument2:argument2Type,) : ReturnType

An operation may have zero or more parameter arguments

These are values passed to the operation to enable it to
perform its tasks

The return type specifies the type of value that is returned

from the operation when it has finished its work
This may be nothing (a void type)

Operation Examples
Examples of operations might be
withdrawCash(amount:Money)
getAge() : Integer
calculateInterest(principal:Money, Interest:Double,
Period:Integer) : Money
getEnrolmentDetails(id : StudentID) : Enrolment
isEnrolled() : Boolean

Note that parameter arguments and return types can be

objects as well as simple data types
An operation will only make sense in the context of the class
it belongs to

Lookup Tables
We create lookup tables for controlled lists of
values for an attribute
e.g. sets of codes that are used
Users can add/edit the list themselves.
But:
If overused, they are meaningless because people
just add codes for everything
If underused, makes search more difficult, data is
messy and difficult to analyse

INSPIRE

INSPIRE
European Directive.
http://inspire.ec.europa.eu/
Develops standards and processes to share data
across 34 themes important for environmental
management, among 28 member states.

Protected Sites
Convened thematic experts from around
Europe.
Had workshops to identify relevant classes
and attributes.
Also several existing domain models in use
around Europe.

Summary
Structural Models
Classes, Attributes, Operations, Associations.
More detail on these next time.

Verifying and validating. Important!