2IW80 Software specification and architecture

Structural specification:
beyond class diagrams
Alexander Serebrenik
 Before we start

Match the pairs

1 Association A
2 Aggregation B
3 Composition C
4 Implementation D
5 Generalization E
6 Dependency F

/ SET / W&I 24-2-2014 PAGE 1

 Before we start

Match the pairs

1E 2C 3F 4A 5D 6B
1 Association A
2 Aggregation B
3 Composition C
4 Implementation D
5 Generalization E
6 Dependency F

/ SET / W&I 24-2-2014 PAGE 2

 Before we start

A patient must be assigned to only one doctor, and a

doctor can have one or more patients.

x y
Patient Doctor

Determine x and y

/ SET / W&I 24-2-2014 PAGE 3

 This week sources

Slides by Site by

David Meredith, Marie-Elise Kontro, Kirill Fakhroutdinov

Aalborg University, DK Tampere University, FI GE Healthcare, USA
 Recall

Structural diagram is a diagram that identifies modules,

activities, or other entities in a system or computer program
and shows how larger or more general entities break down
into smaller, more specific entities.

IEEE Standard Glossary of Software Engineering

Terminology 610.12 1990

/ SET / W&I 24-2-2014 PAGE 5

 UML structure diagrams

Class diagram

Object diagram Packages diagram

Component diagram Deployment diagram

Composite structure diagram

/ SET / W&I 24-2-2014 PAGE 6

 Between specification and architecture

Packages diagram and deployment diagram: the

closest UML diagrams come to architecture
more about architecture: second half of the quartile

/ SET / W&I 24-2-2014 PAGE 7

 Packages diagram

Represents the system at a higher abstraction level

Android SDK 69 packages vs. 1231 classes
less prone to change, ergo better suited for evolution, than
lower level representations

NB: Packages diagram (UML standard) is frequently

called package diagram

/ SET / W&I 24-2-2014 PAGE 8

 Packages diagram: Packages and Relations

Packages
groups of basic elements, e.g., classes or use cases
namespaces, i.e., all members should have unique names
represented as file folders
can contain other packages, creating hierarchy

Relations
dependencies, implementations,
imports and merges

/ SET / W&I 24-2-2014 PAGE 9

 Package representations
Types
Time
Types Date

Package Types, Package Types, some members

members not shown within the borders of the package

Types
Types
Temporal

Shape Point Nested packages

Package Types, some members

shown using -notation
/ SET / W&I 24-2-2014 PAGE 10
 Relations

Dependency
Implementation
Import / access
Merge

/ SET / W&I 24-2-2014 PAGE 11

 Relations: Dependencies
Package A depends on package B if A contains a class
which depends on a class in B
Summarise dependencies between classes

Graphic representation:

or <<use>>
 Relations: Dependencies
Package A depends on package B if A contains a class
which depends on a class in B
Summarise dependencies between classes
Typical 3-tier application (sketch):
UI, web-interface,
Presentation layer services to other
systems

Core calculations,
Business layer operations, etc

Data storage (DB)

Data layer
 Relations: Dependencies
Package A depends on package B if A contains a class
which depends on a class in B
Summarise dependencies between classes

Martins Acyclic Dependency Principle

there should be no cycles in the dependencies

Fowler:
If there are cycles in dependencies, these cycles should be
localized, and, in particular, should not cross the tiers
 Relations: Implementations

Meaningful if multiple variants are present

Database
Gateway

SQL Server
Oracle Gateway MySQL Gateway
Gateway

/ SET / W&I 24-2-2014 PAGE 15

 Relations: Import / access

To understand the import / access relation between

packages
We need to know how elements can reference each other
What does an element import / access mean
How this notion can be generalized to packages

/ SET / W&I 24-2-2014 PAGE 16

 How elements can reference each other? (1)

p
r
A B C
foo

D E s

Element can refer to other elements that are in its

own package and in enclosing packages without
using fully qualified names

17
 Do you remember?

Fully qualified name: a globally unique identifier of a

package, class, attribute, method.

Fully qualified name is composed of

qualifier: all names in the hierarchic sequence above the
given element
the name of the given element itself
p
Notation
r
UML, C++, Perl, Ruby p::A::foo, p::r::C A
foo
C
Java, C# p.A.foo, p.r.C

/ SET / W&I 24-2-2014 PAGE 18

 How elements can reference each other? (2)

p
r
A B C
foo

D E s

Element can refer to other elements that are in its

own package and in enclosing packages without
using fully qualified names

19
 Element Import (1)

Element import allows an element in another package to

be referenced using its name without a qualifier
<<import>> imported element within importing package is public
<<access>> imported element within importing package is private

/ SET / W&I 24-2-2014 PAGE 20

 Element Import (2)

Element import allows an element in another package to

be referenced using its name without a qualifier
<<import>> imported element within importing package is public
<<access>> imported element within importing package is private

e b
a
<<import>>
F
h F
D
C C

/ SET / W&I 24-2-2014 PAGE 21

 Element Import (3)

Element import allows an element in another package to

be referenced using its name without a qualifier
<<import>> imported element within importing package is public
<<access>> imported element within importing package is private

e b
a
<<import>>
F
h FC
D
C or C

/ SET / W&I 24-2-2014 PAGE 22

 Element Import (4)

Element import allows an element in another package to

be referenced using its name without a qualifier
<<import>> imported element within importing package is public
<<access>> imported element within importing package is private

e b
a
<<import>>
F
h FC
D
C
should be C
referred as e::C
in a

/ SET / W&I 24-2-2014 PAGE 23

 Element Import (5)

Element import allows an element in another package to

be referenced usingFits name
cannot bewithout
importedatoqualifier
a since
<<import>> importedthere is already
element within an F in a. Hence,
importing package is public
weelement
<<access>> imported need towithin
rename b::F to package
importing G in a. is private

e b
a
<<import>>
F
h F
D
C C

/ SET / W&I 24-2-2014 PAGE 24

 Element Import (6)

Element import allows an element in another package to

be referenced using its name without a qualifier
<<import>> imported element within importing package is public
<<access>> imported element within importing package is private

e b
a
<<import>>
F
h F
D
C C
b::F is accessible as G in h, b::C is
accessible as C in h, b::D is not
accessible in h (private visibility of
b::D in a due to <<access>>).
/ SET / W&I 24-2-2014 PAGE 25
 Package import (1)

A package import identifies a package whose members

are to be imported
Conceptually equivalent to having an element import to
each individual member of the imported package
<<import>> if package import is public
<<access>> if package import is private

/ SET / W&I 24-2-2014 PAGE 26

 Package import (2)

A package import is a directed relationship that

identifies a package whose members are to be imported
Conceptually equivalent to having an element import to
each individual member of the imported package
<<import>> if package import is public
<<access>> if package import is private
Are elements of types accessible from webShop?
Are elements of auxiliary accessible from webShop?
auxiliary

<<import>>
shoppingCart webShop

types
Are elements of types accessible from shoppingCart?
Are elements of auxiliary accessible from shoppingCart?
/ SET / W&I 24-2-2014 PAGE 27
 Package import (2)

A package import is a directed relationship that

identifies a package whose members are to be imported
Conceptually equivalent to having an element import to
each individual member of the imported package
<<import>> if package import is public
<<access>> if package import is private
Are elements of types accessible from webShop? YES
Are elements of auxiliary accessible from webShop? NO
auxiliary

<<import>>
shoppingCart webShop

types
Are elements of types accessible from shoppingCart? YES
Are elements of auxiliary accessible from shoppingCart? YES
/ SET / W&I 24-2-2014 PAGE 28
 Relations: Recap

Dependency
Implementation
Import / access
Merge

/ SET / W&I 24-2-2014 PAGE 29

 Package merge

A package merge indicates that the contents of the two

packages are to be combined.
A (merged package) is merged into B (receiving package)
that becomes B (resulting package)

/ SET / W&I 24-2-2014 PAGE 30

 Package merge

A package merge indicates that the contents of the two

packages are to be combined.
A (merged package) is merged into B (receiving package)
that becomes B (resulting package)

Merge is possible only if

There is no cycle on merge dependencies
Receiving package does not contain the merged package
Receiving package is not contained in the merged package
Receiving element cannot have references to the merged
element
Matching typed elements should have the same type (class)
or a common supertype (superclass)

/ SET / W&I 24-2-2014 PAGE 31

 Merge rules
UML 2.5 Beta 2, pp. 252-262
http://www.omg.org/spec/UML/2.5/Beta2/

s receiving package
merged package
D q
<<merge>>
A C
A B
s resulting package
Copied D
from s Copied
C from q

Merge of s::A Copied

and q::A A B from s
/ SET / W&I 24-2-2014 PAGE 32
 Merge rules
UML 2.5 Beta 2, pp. 252-262
http://www.omg.org/spec/UML/2.5/Beta2/

s receiving
package merged package
A q
<<merge>>
A B
B
s resulting
Merge of s::A package
and q::A
A

Merge of s::B
and q::B B
/ SET / W&I 24-2-2014 PAGE 33
 Summary: UML package diagrams

http://www.uml-diagrams.org/package-diagrams-overview.html
/ SET / W&I 24-2-2014 PAGE 34
 How do we organize classes/use-cases in
packages?
General: try to give packages meaningful names

Two special cases:

Class package diagrams
basic elements are class diagrams
The most popular special case
Use-case package diagrams
basic elements are use-case diagrams
Useful for larger projects to organize requirements

/ SET / W&I 24-2-2014 PAGE 35

 Class Package Diagrams

Heuristics to organize classes into packages:

Classes of a framework belong in the same package.
Classes in the same inheritance hierarchy typically belong
in the same package.
Classes related to one another via aggregation or
composition often belong in the same package.
Classes that collaborate with each other a lot often belong
in the same package.

/ SET / W&I 24-2-2014 PAGE 36

 How would you organize into 2 packages?

Car, Cylinder, Driver, Driving License, Engine, Person,

Wheel

/ SET / W&I 24-2-2014 PAGE 37

 How would you organize into 2 packages?

Car, Cylinder, Driver, Driving License, Engine, Person,

Wheel

Person

Car Driver

4 1
Driving License
Wheel Engine

2,4,6,8,10,12
Cylinder

/ SET / W&I 24-2-2014 PAGE 38

 How would you organize into 2 packages?

Car, Cylinder, Driver, Driving License, Engine, Person,

Wheel Individual
Person
Vehicle

Car Driver

4 1
Driving License
Wheel Engine

2,4,6,8,10,12
Cylinder

/ SET / W&I 24-2-2014 PAGE 39

 How would you organize into 2 packages?

Car, Cylinder, Driver, Driving License, Engine, Person,

Wheel

Individual

Vehicle

/ SET / W&I 24-2-2014 PAGE 40

 Use-Case Package Diagrams

Heuristics to organize use cases into packages:

Keep associated use cases together: included, extending
and inheriting use cases belong in the same package.
Group use cases on the basis of the needs of the main
actors.

/ SET / W&I 24-2-2014 PAGE 41

 Use-Case Package Diagram Example

http://www.students.tut.fi/~kontrom/files/Lecture6.pdf

/ SET / W&I 24-2-2014 PAGE 42

 UML structure diagrams

Class diagram

Object diagram Packages diagram

Component diagram Deployment diagram

Composite structure diagram

/ SET / W&I 24-2-2014 PAGE 43

 Component diagrams

Component: a modular unit with well-defined interfaces

that is replaceable within its environment (UML Superstructure
Specification, v.2.0, Chapter 8)
fosters reuse
stresses interfaces

Graphical representation: special kind of class

<<component>>
Account Account
Account

UML 1 UML 2
/ SET / W&I 24-2-2014 PAGE 44
 Component diagrams

Component: a modular unit with well-defined interfaces

that is replaceable within its environment (UML Superstructure
Specification, v.2.0, Chapter 8)
fosters reuse
stresses interfaces

Two views: black-box and white-box

Black-box view: interfaces provided and required only

/ SET / W&I 24-2-2014 PAGE 45

 Component diagrams

Component: a modular unit with well-defined interfaces

that is replaceable within its environment (UML Superstructure
Specification, v.2.0, Chapter 8)
fosters reuse
stresses interfaces

Two views: black-box and white-box

Black-box view: interfaces provided and required only
White-box view: structure of interfaces and/or internal
structure

provided required
interface interface
/ SET / W&I 24-2-2014 PAGE 46
 Component diagrams

Component: a modular unit with well-defined interfaces

that is replaceable within its environment (UML Superstructure
Specification, v.2.0, Chapter 8)
fosters reuse
stresses interfaces

Two views: black-box and white-box

Black-box view: interfaces provided and required only
White-box view: structure of interfaces and/or internal
structure

/ SET / W&I 24-2-2014 PAGE 47

 Nested components

Components can be contained in other components

Interfaces can then be delegated through ports

/ SET / W&I 24-2-2014 PAGE 48

 Summary: UML component diagrams

http://www.uml-diagrams.org/component-diagrams.html
/ SET / W&I 24-2-2014 PAGE 49
 UML structure diagrams

Class diagram

Object diagram Packages diagram

Component diagram Deployment diagram

Composite structure diagram

/ SET / W&I 24-2-2014 PAGE 50

 Deployment

Deployment: relationship between logical and/or

physical elements of systems (Nodes) and information
technology assets assigned to them (Artefacts).

/ SET / W&I 24-2-2014 PAGE 51

 Deployment

Deployment: relationship between logical and/or

physical elements of systems (Nodes) and information
technology assets assigned to them (Artefacts).

Nodes DBServer
devices: application server, client workstation,
execution environments: DB system, J2EE container,
Graphical representation: box

/ SET / W&I 24-2-2014 PAGE 52

 Deployment

Deployment: relationship between logical and/or

physical elements of systems (Nodes) and information
technology assets assigned to them (Artefacts).

Nodes DBServer
devices: application server, client workstation,
execution environments: DB system, J2EE container,
Graphical representation: box
Nodes can be physically connected (e.g., via cables or
wireless)
UML-parlance: CommunicationPath
Graphical representation: as an association

/ SET / W&I 24-2-2014 PAGE 53

 Deployment

Deployment: relationship between logical and/or

physical elements of systems (Nodes) and information
technology assets assigned to them (Artefacts).

Artefacts: information items produced during software

development or when operating the system
model files, source files, scripts, executable files, database
tables, word-processing documents, mail messages,
Graphical representation: class-like <<artifact>>

ShoppingCart.jar
Relations: dependencies

/ SET / W&I 24-2-2014 PAGE 54

 Deployment

Deployment: relationship between logical and/or

physical elements of systems (Nodes) and information
technology assets assigned to them (Artefacts).

Deployment: three equally valid representations

http://www.uml-diagrams.org/deployment-diagrams.html
24-2-2014 PAGE 55
 Deployment: missing piece

How do we know where a given use case, class,

component, or package is deployed?
Use case / class / component / packages diagrams do not
discuss deployment
Deployment diagrams do not discuss use cases / classes /
components / packages but only artifacts

/ SET / W&I 24-2-2014 PAGE 56

 Deployment: missing piece

How do we know where a given use case, class,

component, or package is deployed?
Use case / class / component / packages diagrams do not
discuss deployment
Deployment diagrams do not discuss use cases / classes /
components / packages but only artifacts

Manifestation maps artifacts to use

cases / classes / components /
packages

/ SET / W&I 24-2-2014 PAGE 57

 Summary: deployment diagrams

/ SET / W&I http://www.uml-diagrams.org/deployment-diagrams-overview.html

24-2-2014 PAGE 58
 Conclusions

/ SET / W&I 24-2-2014 PAGE 59