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
