CS261

Software Engineering

Topic 4: System Design 2

James Archbold
[email protected]

In association with Deutsche Bank

CS261 - Software Engineering - Software Design 1

Planning and Design Document
Preamble
• Authors / Editors
• Creation date, last update, version number, version history,
abbreviations / acronyms, table of contents

Technical Description
• Purpose of the document and problem
• Use of standards, third-party libraries etc.
• Relationship with other systems (context model) and system
architecture (this lecture)
• Definitions of entities and rationale for design (class diagrams),
relationships between
• Database entity relationship diagram

Description of processes, activities

• Including user interaction (use case diagrams)
• Interaction between components (sequence diagrams)
• State and / or activity diagrams

CS261 - Software Engineering - Introduction 2

Planning and Design Document
User interface design
• Architecture, usability inspection, walk through, prototypes
• Application of GUI design principles (clarity, compatibility,
comprehensibility, consistency, efficiency, familiarity, recovery,
responsiveness, simplicity)
• Usability testing

Test Plans
• Tracing requirements through design and implementation, test
coverage
• Unit testing and integration testing
• User acceptance testing

Process documentation and measuring success

• Plan, estimates and schedules (e.g. Gantt chart, activity diagrams)
• Project organisation (if not already documented)
• Risk register, and monitoring and reporting

Delivery and sign-off

Note: THIS IS NOT EXHAUSTIVE
CS261 - Software Engineering - Introduction 3
Unified Modelling Language (UML)
UML can be used to described systems in 2 ways:
(i) Static/structural view, (ii) Dynamic/behavioural view

CS261 - Software Engineering - Software Design 4

Unified Modelling Language (UML)
UML can be used to described systems in 2 ways:
(i) Static/structural view, (ii) Dynamic/behavioural view

CS261 - Software Engineering - Software Design 5

What type of UML diagram is this?

This is a Behaviour Diagram

called an Activity Diagram

This allows us to represent

workflows of stepwise
activities

CS261 - Software Engineering - Software Design 6

How about this?

This is a type of Static Structure Diagram called a Class

Diagram.

We must derive class names from analysis of the

requirements; attributes and methods inform the developer.

Note: We are not prescribing how things are implemented.

CS261 - Software Engineering - Software Design 7
One more

This is a type of
Behaviour Diagram
called a Use Case
Diagram.

It describes the
interaction of
actors with events
in the system.

CS261 - Software Engineering - Software Design 8

A New Challenger Appears

There is one more UML behavioural diagram to cover:

the State machine diagram

CS261 - Software Engineering - Software Design 9

UML - State Diagram
A Finite State Machine showing how the state of the
system changes.

CS261 - Software Engineering - Software Design 10

Seems a little familiar…
The Finite State Machine bears some resemblance
to the flowcharts seen in the Activity Diagrams

CS261 - Software Engineering - Software Design 11

They’re basically cousins!

Although the notation looks similar, and they are both

behaviour diagrams - there are fundamental differences!

CS261 - Software Engineering - Software Design 12

State Diagram vs. Flowchart - The fight of the century

CS261 - Software Engineering - Software Design 13

State Diagram vs. Flowchart - The fight of the century

CS261 - Software Engineering - Software Design 14

State Diagram vs. Flowchart - The fight of the century

&

CS261 - Software Engineering - Software Design 15

Activity Diagrams vs Finite State Diagrams

CS261 - Software Engineering - Software Design 16

Context Models
• Context models illustrate the operational context of the
system and other systems

• Show what is inside and outside of the boundary of the

system - Pizza Ordering system being developed shown
relative to other systems

CS261 - Software Engineering - Software Design 17

Writing Correct UML
• System Modelling encourages us to take something which
may not be clear, and resolve any ambiguities for later
implementation

• The UML should therefore be clear

‣ Ambiguities in the specification should be resolved

‣ New ambiguities should not be introduced

• The system designer should therefore aim to be as

precise as possible

CS261 - Software Engineering - Software Design 18

Writing correct Class Diagrams

Class Name

These are both regular classes

If it is representing an abstract
class then it should be written in
italics

If it is representing an interface
then it should be prefixed with
<<interface>>

CS261 - Software Engineering - Software Design 19

Writing correct Class Diagrams

Attributes

Represent the internal datatypes

Are optional

CS261 - Software Engineering - Software Design 20

Writing correct Class Diagrams

Operations / Methods

You need not include get and

set methods

All methods that make up part of

the interface must be included
(and must be public)

You do not need to include any

inherited methods

CS261 - Software Engineering - Software Design 21

Writing correct Class Diagrams
Attributes / modifiers
+ Public
- Private
# Protected
~ Package void

/ Derived (i.e. computed)

Static Attributes/Methods
These should be underlined

Method Parameters
Return types can be omitted if
void, as in Java

CS261 - Software Engineering - Software Design 22

Writing correct Class Diagrams
Comments

Can be associated with classes,

abstract classes and interfaces

Use the folded note notation

CS261 - Software Engineering - Software Design 23

Associating Class Diagrams

Class Hierarchies

Drawn top-down with arrows pointing to

parent

Arrow Styles:

- Class: solid line, black arrow

- Abstract Class: solid line, white arrow

- Interface: dashed line, white arrow

CS261 - Software Engineering - Software Design 24

Associating Class Diagrams

1. Multiplicity

* (zero or more)

1 (exactly one)

2..4 (between 2 and 4 inclusive)

3..* (3 or more, can omit *)

2. Name (what relationship objects

have)

3. Navigability (direction)

CS261 - Software Engineering - Software Design 25

Associating Class Diagrams

One-to-one

Each car has exactly one

engine

Each engine belongs to

exactly one car

One-to-many

Each book has many pages

Each pages belongs to

exactly 1 book

CS261 - Software Engineering - Software Design 26

Associating Class Diagrams

‘Is part of’ (aggregation)

White diamond

‘Is made up of’ (composition)

Black diamond
Part ‘dies’ when whole ‘dies’
Stronger version of aggregation

‘Uses temporarily’ (dependency)

Dotted line
Often an implementation detail and not
intrinsic part of objects state

CS261 - Software Engineering - Software Design 27

Example!

If the movie theatre goes

away then…

…so does the box office

(composition)

…but movies may still exist

(aggregation)

CS261 - Software Engineering - Software Design 28

Example!

CS261 - Software Engineering - Software Design 29

Writing correct Sequence Diagrams

• Participants are objects/entities

‣ Often starts with a ‘call out’ arrow

representing a method/function

• Messages (arrows) are

communications between objects

• Time moves from top to bottom

CS261 - Software Engineering - Software Design 30

Writing correct Sequence Diagrams

• There are various ways of

representing an object (depending
on what is known)

• The dashed vertical line was the

lifetime of the object

• You can terminate the lifetime with

a cross

CS261 - Software Engineering - Software Design 31

Writing correct Sequence Diagrams

• When an object is active (i.e.

running code, or waiting for another
object to finish) we represent this
with a box

• Nested activations indicate

recursion

CS261 - Software Engineering - Software Design 32

Writing correct Sequence Diagrams

A frame box allows:

if (opt) [condition]
if-else (alt)[condition1, dashed line, condition2]
loops (loop)[condition]
CS261 - Software Engineering - Software Design 33
Writing correct Sequence Diagrams
If the sequence diagrams get too large use:
(i) a reference to another diagram
(ii) a note to another diagram

CS261 - Software Engineering - Software Design 34

Example Sequence Diagram

CS261 - Software Engineering - Software Design 35

Tool Support

• There are several UML tools around which you can user

Violet (http://horstmann.com/violet)

Rational Role (http://www.rational.com/)

Visual Paradigm (http://www.visual-paradigm.com/)

• There is work on creating code from UML directly

• Still active research - xUML: Executable UML is designed to

facilitate Model-driven Engineering

CS261 - Software Engineering - Software Design 36

To Summarise
• We have been doing some system modelling

‣ System design stage of lifecycle

‣ Employed formal methods (UML) to remove ambiguity in requirements

• Various model types exist

‣ Structural - e.g. Class Diagrams

‣ Behavioural - e.g. Activity and Use Case Diagrams, and Sequence and
Interaction Diagrams

• Employ some of these methods in group project

• Be careful how you use the modelling notation (better to do a small

amount properly than a lot wrong)
CS261 - Software Engineering - Software Design 37