More unified modelling language

We saw use case diagrams, which are part of UML, the Unified
Modelling Language.
Class diagrams and architectural design (What’s that, and why?)
A class diagram crept into last lecture...
Perdita Stevens Now we look properly at the basic features of class diagrams.

School of Informatics
University of Edinburgh

A class An object

jo : Customer
Book

This pattern generalises: always show an instance of a classifier

A class as design entity is an example of a model element: the using the same symbol as for the classifier, labelled
rectangle and text form an example of a corresponding instanceName : classifierName.
presentation element.
UML explicitly separates concerns of actual symbols used vs
meaning.
Classifiers and instances Showing attributes and operations
An aspect of the UML metamodel that it’s helpful to understand Book
up front.
title : String
An instance is to a classifier as an object is to a class: instance
copiesOnShelf() : Integer
and classifier are more general terms.
borrow(c:Copy)
UML defines many different classifiers. In fact, UseCase and Actor
are classifiers. Syntax for signature of operations (argument and return types)
adaptable for different PLs. May be omitted

Compartments Visibility
We saw the standard: Book
I a compartment for attributes + title : String
I a compartment for operations, below it - copiesOnShelf() : Integer
# borrow(c:Copy)
They can be suppressed in diagrams.
They are omitted if empty. Can show whether an attribute or operation is
You can have extra compartments labelled for other purposes, e.g., I public (visible from everywhere) with +
responsibilities of the class... I private (visible only from inside objects of this class) with −
(Or protected (#), package (∼) or other language dependent
visibility.)
Association between classes Rolenames on associations

Director of DoS directee Student

is a copy of Studies
Copy Book
Can show the role that one object plays to the other.
Useful when documenting the class: e.g. a class invariant for
This generalises: association between classifiers is always shown
DirectorOfStudies could refer to the associated Student objects as
using a plain line. (Recall the associations between actors and use
self.directee (a set, if there can be more than one).
cases!)
Can use visibility notation + − etc on role names too.
An instance of an association connects objects (e.g. Copy 3 of War
and Peace with War and Peace).
An object diagram contains objects and links: occasionally useful.

Class invariants Multiplicity of association

Book
A class invariant is a statement which is supposed to be true of
every object of the class, all the time - a “sanity check”. 1
is a copy of
Very useful to make these explicit. Can be included as comments
on class diagrams, and in code. 1..*
May be formal, e.g. x + y = z, or informal, e.g. “the attribute
LibraryMember borrows/returns Copy
docstring describes the action of the button in concise English”. 1 0..*
If formal, it can be useful to have class invariants automatically 0..*
checked. borrows/returns
1

MemberOfStaff borrows/returns Journal

1 0..*

Commas for alternatives, two dots for ranges, * for unknown

number. E.g. each Copy is a copy of exactly one Book; there must
be at least one Copy of every Book.
Navigability Generalisation
Adding an arrow at the end of an association shows that some
object of the class at one end can access some object of the class
at the other end, e.g. to send a message. LibraryMember

is taking Module
Student

Crucial to understanding the coupling of the system. NB direction

of navigability has nothing to do with direction in which you read
the association name.
We’ll return to this in the context of interactions and interaction
MemberOfStaff
diagrams.

This generalises: generalisation between classifiers is always shown

using this arrow.
Usually, but not necessarily, corresponds to implementation with
inheritance.

Abstract operations and classes Interfaces

An operation of a class is abstract if the class provides no In UML an interface is just a collection of operations.
implementation for it: thus, it is only useful if a subclass provides
<<interface>> Module
the implementation. Stringifiable
A class which cannot be instantiated directly – for example, stringify() : String
stringify() : String

because it has at least one abstract operation – is also called ...

...
abstract.
Stringifiable
Can show abstract operation or class using italics for the name,
<<use>>
and/or using the property {abstract}.

Printer
Simpler diagram: WRITE ONCE Identifying objects and classes
<<interface>> Module Simplest and best: look for noun phrases in the system description!
Stringifiable
stringify() : String
Then abandon things which are:
stringify() : String I redundant
... I attributes
...
I outside scope I operations and events
Stringifiable I vague I implementation classes.

prints
(May need to add some back later, especially implementation
classes: point is to avoid incorporating premature design decisions
into your conceptual level model.)
Printer Similarly, can use verb phrases to identify operations.

Many things other than classes can realise interfaces: can use the
lollipop symbol on e.g. components, actors.

So what is architecture?
Architecture Many things to many people.

The way that components work together

More precisely, an architectural decision is a decision which affects

how components work together.
Includes decisions about the high level structure of the system –
what you probably first think of as “architecture”.
Pervasive, hence hard to change. Indeed an alternative definition is
“what stays the same” as the system develops and between related
systems (Stuart Anderson).
Classic structural view More examples of architectural decisions
Architecture specifies: I what language and/or component standard are we using?
(C++, Java, CORBA, DCOM, JavaBeans...)
I what are the components?
Looked at another way, where shall we put the encapsulation
I what conventions do components have about error handling?
barriers? Which decisions do we want to hide inside I what framework does the product use?
components, so that we can change them without affecting
the rest of the system? Clean architecture helps get reuse of components.
I what are the connectors? Indeed by some definitions parts of the architecture can be
Looked at another way, how and what do the components components – frameworks, product-line architectures etc.
really need to communicate? E.g., what should be in the
interfaces, or what protocol should be used?
The component and connector view of architecture is due to Mary
Shaw and David Garlan – spawned specialist architectural
description languages, and influenced UML2.0, but beyond scope
of this course.

Reading
Suggested: Browse SEI’s collection of architecture definitions at
http:
//www.sei.cmu.edu/architecture/definitions.html
Suggested: (architecture) Somerville ch 11-13
Suggested: (class diagrams) Stevens ch 5.