High-Level Design
Lecture 7
1Chapter 7 Design and implementation
© Clear View Training 2010 v2.6 2
Purpose of system design
 Refine how the system's functions are to be
implemented and how non-functional requirements are
to be ensured
 Decide on strategic design issues such as concurrency,
redundancy, persistence, distribution etc. to end with a
design satisfying both functional and non-functional
requirements
 Create policies to deal with tactical design issues
 High-level vs. Low-level design
Design best practices
 A system design consists of a collection of decisions that
help to control different attributes of software quality.
 The design aims to ensure achievement of system functionality,
but whenever there are different ways to achieve the
functionality, the impact of each design decision on software
quality becomes the issue.
 Quality-driven design decisions are often known as
tactics, which isolate and describe design best practices
with respect to a specific quality attribute.
 Design patterns are a specific and very popular tactic used
during low-level design.
3Chapter 7 Design and implementation
Outline
 Design for dependability
 Design for security
 Design for performance, modifiability and usability
 UML Class Diagram in Design
 Design classes
 Design relationships
4Chapter 7 Design and implementation
Design for Dependability
Lecture 7/Part 1
5Chapter 13 Dependability Engineering
Software dependability
 In general, software customers expect all software to be
dependable. However, for non-critical applications, they
may be willing to accept some system failures.
 Some applications (critical systems) have very high
dependability requirements and special software
engineering techniques may be used to achieve this.
 Medical systems
 Telecommunications and power systems
 Aerospace systems
6Chapter 13 Dependability Engineering
Dependability achievement
 Fault avoidance
 The development process is organised so that faults in the
system are detected and repaired before delivery to the
customer.
 Verification and validation techniques are used to discover and
remove faults in a system before it is deployed.
 Fault detection
 Run-time techniques to detect faults and failures, such as
acceptance tests, ping/echo, heartbeat.
 Fault tolerance
 The system is designed so that faults in the delivered software
do not result in system failure.
7Chapter 13 Dependability Engineering
Dependable processes for fault avoidance
 To ensure a minimal number of software faults, it is
important to have a well-defined, repeatable software
process.
 The process should not depend entirely on individual
skills; rather can be enacted by different people.
 Regulators use information about the process to check if
good software engineering practice has been used.
 For fault detection, it is clear that the process activities
should include significant effort devoted to verification
and validation.
8Chapter 13 Dependability Engineering
Static fault detection and its costs
9Chapter 13 Dependability Engineering
Dynamic fault detection tactics
 Ping/echo. One component issues a ping and expects
to receive back an echo, within a predefined time, from
the component under scrutiny.
 Heartbeat (dead man timer). In this case one
component emits a heartbeat message periodically and
another component listens for it. If the heartbeat fails, the
originating component is assumed to have failed and a
fault correction component is notified.
 Acceptance tests and Exceptions. One method for
recognizing faults is to identify and raise an exception.
10
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Fault tolerance
 In critical situations, software systems must be
fault tolerant.
 Fault tolerance is required where there are high availability
requirements or where system failure costs are very high.
 Fault tolerance means that the system can continue in
operation in spite of software failure.
 Even if the system has been proved to conform to its
specification, it must also be fault tolerant as there may be
specification errors or the validation may be incorrect.
 Dependable systems architectures are used in
situations where fault tolerance is essential.
 These architectures are generally all based on redundancy and
diversity.
11Chapter 13 Dependability Engineering
Diversity and redundancy
 Redundancy
 Keep more than 1 version of a critical component available so
that if one fails then a backup is available.
 E.g. switch to backup servers automatically if failure occurs.
 Diversity
 Provide the same functionality in different ways so that they will
not fail in the same way.
 E.g. different servers may be implemented using different
operating systems (e.g. Windows and Linux).
 However, adding diversity and redundancy adds
complexity and this can increase the chances of error.
 Some engineers advocate simplicity and extensive V & V is a
more effective route to software dependability.
12Chapter 13 Dependability Engineering
Fault tolerance and recovery tactics (1)
 Voting. Processes running on redundant processors
each take equivalent input and compute a simple output
value that is sent to a voter to choose non-deviant result.
 Active redundancy (hot restart). All redundant
components respond to events in parallel. Consequently,
they are all in the same state. The response from only
one component is used (usually the first to respond), and
the rest are discarded.
 Passive redundancy (warm restart/dual redundancy/
triple redundancy). One component (the primary)
responds to events and informs the other components
(the standbys) of state updates they must make.
13
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Fault tolerance and recovery tactics (2)
 Spare. A standby spare computing platform is configured
to replace many different failed components. It must be
rebooted to the appropriate software configuration and
have its state initialized when a failure occurs.
 Shadow operation. A previously failed component may
be run in "shadow mode" for a short time to make sure
that it mimics the behavior of the working components
before restoring it to service.
 Checkpoint/rollback. A checkpoint is a recording of a
consistent state created either periodically or in response
to specific events, to which the system can be restored.
14
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
N-version programming pattern
 Multiple versions of a software system carry out
computations at the same time.
 The versions should be designed and implemented by different
teams, to avoid repeating the same mistake.
 The results are compared using a voting system and the
majority result is taken
to be the correct result.
Which of the tactics
are involved here?
Chapter 13 Dependability Engineering 15
Self-monitoring architectures
 Multi-channel architectures with diverse SW and HW in
each channel.
 The same computation is carried out on each channel and the
results compared.
 The system monitors its own operations and takes action if
inconsistencies are detected.
Chapter 13 Dependability Engineering 16
Protection systems
 A specialized system that is associated with some other
control system, which can take emergency action if a
failure occurs.
 System to stop a train if it passes a red light
 System to shut down a reactor if temperature/pressure are too
high
 Protection systems are redundant because they include
monitoring and control capabilities that replicate those in
the control software.
 Protection systems should be diverse and use different
technology from the control software.
Chapter 13 Dependability Engineering 17
Key points
 Dependability in a program can be achieved by avoiding the
introduction of faults, by detecting and removing faults before
system deployment, and by including fault tolerance facilities.
 The use of redundancy and diversity in hardware, software
processes and software systems is essential for the development of
dependable systems.
 The use of a well-defined, repeatable process is essential if faults in
a system are to be minimized.
 Dependable system architectures are system architectures that are
designed for fault tolerance. Architectural styles that support fault
tolerance include protection systems, self-monitoring architectures
and N-version programming.
Chapter 13 Dependability Engineering 18
Design for Security
Lecture 7/Part 2
Chapter 14 Security Engineering 19
Design for security
 Two fundamental issues have to be considered when
designing an architecture for security.
 Protection
• How should the system be organised so that critical assets can be
protected against external attack?
 Distribution
• How should system assets be distributed so that the effects of a
successful attack are minimized?
 These are potentially conflicting
 If assets are distributed, then they are more expensive to protect.
If assets are protected, then usability and performance
requirements may be compromised.
Chapter 14 Security Engineering 20
Protection
 Platform-level protection
 Top-level controls on the platform on which a system runs.
 Application-level protection
 Specific protection mechanisms built into the application itself
e.g. additional password protection.
 Record-level protection
 Protection that is invoked when access to specific information is
requested
 These lead to a layered protection architecture
Chapter 14 Security Engineering 21
A layered protection architecture
Chapter 14 Security Engineering 22
Distribution
 Distributing assets means that attacks on one system do
not necessarily lead to complete loss of system service
 Each platform has separate
protection features and may
be different from other platforms
so that they do not share a
common vulnerability
 Distribution is particularly
important if the risk of denial
of service attacks is high
Chapter 14 Security Engineering 23
Security tactics
 Security tactics encapsulate good practice in secure
systems design
 Security tactics serve two purposes:
 They raise awareness of security issues in a software
engineering team. Security is considered when design decisions
are made.
 They can be used as the basis of a review checklist that is
applied during the system validation process.
 Tactics described here are applicable during software
specification and design
Chapter 14 Security Engineering 24
Tactics for secure systems engineering
Security tactics
Base security decisions on an explicit security policy
Avoid a single point of failure
Fail securely
Balance security and usability
Log user actions
Use redundancy and diversity to reduce risk
Compartmentalize your assets
Design for recoverability
Design for deployment
Validate all inputs
Chapter 14 Security Engineering 25
Design guidelines 1-3
 Base decisions on an explicit security policy
 Define a security policy for the organization that sets out the
fundamental security requirements that should apply to all
organizational systems.
 Avoid a single point of failure
 Ensure that a security failure can only result when there is more
than one failure in security procedures. For example, have
password and question-based authentication.
 Fail securely
 When systems fail, for whatever reason, ensure that sensitive
information cannot be accessed by unauthorized users even
although normal security procedures are unavailable.
Chapter 14 Security Engineering 26
Design guidelines 4-6
 Balance security and usability
 Try to avoid security procedures that make the system difficult to
use. Sometimes you have to accept weaker security to make the
system more usable.
 Log user actions
 Maintain a log of user actions that can be analyzed to discover
who did what. If users know about such a log, they are less likely
to behave in an irresponsible way.
 Use redundancy and diversity to reduce risk
 Keep multiple copies of data and use diverse infrastructure so
that an infrastructure vulnerability cannot be the single point of
failure.
Chapter 14 Security Engineering 27
Design guidelines 7-10
 Compartmentalize your assets
 Organize the system so that assets are in separate areas and
users only have access to the information that they need rather
than all system information.
 Design for recoverability
 Design the system to simplify recoverability after a successful
attack.
 Design for deployment
 Design the system to avoid deployment problems
 Validate all inputs
 Check that all inputs are within range so that unexpected inputs
cannot cause problems.
Chapter 14 Security Engineering 28
System survivability
 Survivability is an emergent system property that reflects
the systems ability to deliver essential services whilst it is
under attack or after part of the system was damaged
 Survivability analysis
and should be part of
the security
engineering
process
Chapter 14 Security Engineering 29
Survivability strategies
 Resistance
 Avoiding problems by building capabilities into the system to
resist attacks
 Recognition
 Detecting problems by building capabilities into the system to
detect attacks and failures and assess the resultant damage
 Recovery
 Tolerating problems by building capabilities into the system to
deliver services whilst under attack
Chapter 14 Security Engineering 30
Key points
 Design for security involves architectural design,
following good design practice and minimising the
introduction of system vulnerabilities
 General security guidelines sensitize designers to
security issues and serve as review checklists
 System survivability reflects the ability of a system to
deliver services whilst under attack or after part of the
system has been damaged.
Chapter 14 Security Engineering 31
Design for Performance, Modifiability and Usability
Lecture 7/Part 3
32
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Performance tactics – Resource
management
 Introduce concurrency. If requests can be processed in
parallel, the blocked time can be reduced.
 Maintain multiple copies of either data or
computations. The purpose of replicas is to reduce the
contention that would occur if all computations took
place on a central server.
 Increase available resources. Faster processors,
additional processors, additional memory, and faster
networks all have the potential for reducing latency.
33
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Performance tactics – Resource arbitration
 The selection of optimal scheduling strategy for each
resource influences optimal resource usage, minimizes
the number of resources used, minimizes latency,
maximizes throughput, prevents starvation, and so forth.
 A scheduling policy conceptually has two parts: a
priority assignment and dispatching.
 All scheduling policies assign priorities.
 In some cases the assignment is as simple as first-in/first-out.
 In other cases, it can be tied to the deadline of the request or its
semantic importance.
34
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Modifiability tactics – Localize modifications
 Maintain semantic coherence. The goal is to ensure
that all the responsibilities in a module work together
without excessive reliance on other modules.
 Generalize the module. Making a module more general
allows it to compute a broader range of functions on
input.
 Limit possible options. Modifications, especially within
a product line, may be far ranging and hence affect
many modules. Restricting the possible options will
reduce the effect of these modifications.
35
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Modifiability tactics – Prevent ripple effects
 A ripple effect from a modification is the necessity of
making changes to modules not directly affected by it.
 For instance, if module A is changed to accomplish a particular
modification, then module B is changed only because of the
change to module A. B has to be modified because it depends,
in some sense, on A.
 Hide information. Information hiding is the
decomposition of the responsibilities for an entity (a
system or some decomposition of a system) into smaller
pieces and choosing which information to make private
and which to make public.
36
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Modifiability tactics – Prevent ripple effects
 Maintain existing interfaces. If B depends on the name
and signature of an interface of A, maintaining this
interface and its syntax allows B to remain unchanged.
 Restrict communication paths. Restrict the modules
with which a given module shares data via data
production and consumption.
 Use an intermediary. If B has any type of dependency
on A other than semantic, it is possible to insert an
intermediary between B and A that manages activities
associated with the dependency.
37
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Modifiability tactics – Defer binding time
 Runtime registration supports plug-and-play operation
at the cost of additional overhead to manage the
registration. Publish/subscribe registration, for example,
can be implemented at either runtime or load time.
 Configuration files are intended to set parameters at
startup.
 Polymorphism allows late binding of method calls.
 Component replacement allows load time binding.
 Adherence to defined protocols allows runtime binding
of independent processes.
38
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Usability tactics – Design-time tactics
 Separate the user interface from the rest of the
application. Localizing expected changes is the
rationale for semantic coherence.
 Since the user interface is expected to change frequently
both during the development and after deployment,
maintaining the user interface code separately will
localize changes to it.
39
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Usability tactics – Runtime tactics
 Maintain a model of the task. The task model is used to determine
context so the system can have some idea of what the user is
attempting and provide various kinds of assistance.
 For example, knowing that sentences usually start with capital letters
would allow an application to correct a lower-case letter in that position.
 Maintain a model of the user. The model determines the user's
knowledge of the system, the user's behavior in terms of expected
response time, and other aspects specific to a user or a class of
users.
 For example, maintaining a user model allows the system to pace
scrolling so that pages do not fly past faster than they can be read.
 Maintain a model of the system. The model determines the
expected system behavior so that appropriate feedback can be
given to the user.
40
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
Quality conflicts
 Within complex systems, quality attributes can never be
achieved in isolation.
 The achievement of any one will have an effect, sometimes
positive and sometimes negative, on the achievement of others.
 For example, almost every quality attribute negatively
affects performance.
 Portability. The main technique for achieving portable software is
to isolate system dependencies, which introduces overhead into
the system's execution, typically as process or procedure
boundaries, and this hurts performance.
 Reliability. Redundancy together with a voting schema delays
system response.
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
41
Quality conflicts
 It is not possible for any system to be optimized for all of
these attributes.
 The quality plan should therefore define the most
important quality attributes for the software that is being
developed.
 The plan should also include a definition of the quality
assessment process, an agreed way of assessing
whether some quality, such as maintainability or
robustness, is present in the product.
42
© Software Architecture in Practice
by L. Bass, P. Clements and R. Kazman
UML Class Diagram in Design
Lecture 8/Part 3
43© Clear View Training 2010 v2.6
© Clear View Training 2010 v2.6 44
Design model
 Design model is a refinement of an analysis model to
such a degree that it can be implemented
 In MDD design models include all implementation details and
can be automatically translated into code
 In OO design models:
 All attributes are completely specified
 Analysis operations become fully specified methods
 Many new classes are added to include implementation details,
such as utility classes (String, Date, Time, etc.), middleware
classes (DB access, communication, etc.) or GUI classes
(Applet, Button, etc.)
 Design models are programming-language specific
 Multiple inheritance, templates, nested classes, collections
© Clear View Training 2010 v2.6 45
 A design model may contain 10 to 100 times as many
classes as the analysis model
 The analysis model helps us to see the big picture without
getting lost in implementation details
 We need to maintain both models if:
 It is a big system ( >200 design classes)
 It has a long expected lifespan
 It is a strategic system
 We are outsourcing construction of the system
 Otherwise, we can make it with only a design model
Analysis vs. design model
© Clear View Training 2010 v2.6 46
Anatomy of a design class
 A design class shall have:
 A complete set of operations
including parameter lists, return
types, visibility, exceptions, set and
get operations, constructors
 A complete set of attributes
including types and default values
BankAccount
-name:String
-number:String
-balance:double = 0
+BankAccount(name:String, number:String)
+deposit(m:double):void
+withdraw(m:double):boolean
+calculateInterest():double
+getName():String
+setName(n:String):void
+getAddress():String
+setAddress(a:String):void
+getBalance():double
BankAccount
name
number
balance
deposit()
withdraw()
calculateInterest()
analysis design
«trace»
constructor
© Clear View Training 2010 v2.6 47
High cohesion, low coupling
 High cohesion
 Each class should have a set of operations that support the
intent of the class, no more and no less
 Each class should model a single abstract concept
 Low coupling
 A particular class should be associated with just enough
other classes to allow it to realise its responsibilities
 Only associate classes if there is a true semantic link
between them – never to only reuse code!
 Use aggregation rather than inheritance
 Primitive operations
 Each operation shall implement a single functionality, and
each functionality shall be implemented by single operation
Employee
Manager Programmer
john:Programmer
«instantiate»
What is wrong with
this model?
© Clear View Training 2010 v2.6 48
Aggregation vs. inheritance
 An employee has a job,
not is a job.
 An employee can have
more jobs.
just change this link at
runtime to promote john!
Job
Manager Programmer
john:Employee
Employee
:Programmer
«instantiate»
:Manager
«instantiate»
«instantiate»
0..*0..*
Employee
Manager Programmer
john:Programmer
«instantiate»
© Clear View Training 2010 v2.6 49
 With inheritance we get two things:
 Interface – the public operations of the
base classes
 Implementation – the attributes,
relationships, operations of the class
 With interface we get one thing:
 Interface – a set of public operations,
attributes and relationships that have
no implementation
Use interface realization when we want to
define a contract.
Inheritance vs. interface realization
Job
Manager Programmer
Job
Manager Programmer
Use inheritance when we want to inherit
implementation.
© Clear View Training 2010 v2.6 50
Key points (design classes)
 Design classes come from:
 A refinement of analysis classes (i.e. the business domain)
 From the solution domain
 Design classes must be well-formed:
 High cohesion
 Low coupling
 Primitive operations
 Don’t overuse inheritance
 Use inheritance for "is kind of"
 Use aggregation for "is role played by"
 Use interfaces rather than inheritance to define contracts
© Clear View Training 2010 v2.6 51
Design relationships
 Refining analysis associations to design associations
involves several procedures:
 refining associations to aggregation or composition
 implementing one-to-many associations
 implementing many-to-one associations
 implementing many-to-many associations
 implementing bidirectional associations
 implementing association classes
 All design associations must have:
 navigability
 multiplicity on both ends
© Clear View Training 2010 v2.6 52
Aggregation and composition
A B
A B A B
«trace» «trace»
{xor}
AnalysisDesign
aggregation composition
Some objects are strongly
related like a tree and its leaves
Some objects are weakly related
like a computer and its peripherals
© Clear View Training 2010 v2.6 53
Aggregation semantics
 The aggregate can (sometimes) exist independently of the parts
 The parts can (sometimes) exist independently of the aggregate
 It is possible to have shared ownership of the parts by several
aggregates
Computer Printer
0..* 0..*
whole or
aggregate
part
aggregation is a whole–part relationship
A Computer may be attached to 0 or more
Printers
At any one point in time a Printer is
connected to 0 or more Computers
The Printer exists even if there are no
Computers
The Printer is independent of the Computer
aggregation
© Clear View Training 2010 v2.6 54
Composition semantics
 The parts belong to exactly 1 whole at a time
 The composite has sole responsibility for the disposition of all its
parts. This means responsibility for their creation and destruction
 If the composite is destroyed, it must either destroy all its parts,
OR give responsibility for them over to some other object (the
exception above)
Mouse Button
1 1..4
composition is a strong form of aggregation
composite part
composition
always 1 (with an exception of
a transferable part, when it is 0)
The buttons have no independent
existence. If we destroy the
mouse, we destroy the buttons.
They are an integral part of the
mouse
Each button can belong to exactly
1 mouse
© Clear View Training 2010 v2.6 55
• Many-to-one relationships in
analysis imply shared ownership
and are refined to aggregations
• One-to-one associations in analysis
usually imply single ownership and
usually refine to compositions
A B
1 1
A B
1 1
«trace»
roleName
One to one
A B
0..* 1
A B
0..* 1
«trace»
roleName
Many to one
analysis
design
One-to-one and many-to-one associations
© Clear View Training 2010 v2.6 56
One-to-many and many-to-many
associations
 Collection classes instances store a
collection of object references to objects
of the target and provide methods for
operating the collection
 In Java in the java.util library
A B
1 0..*
A B
1 0..*
Vector
1 1
«trace»
Many to manyOne to many
Task Resource
0..* 0..*
AllocationTask Resource
10..*1 0..*
«trace»
 Many-to-many associations shall be
reified into intermediate design
classes
© Clear View Training 2010 v2.6 57
Bi-directional associations
 There is no commonly used OO
language that directly supports bidirectional
associations
 We must resolve each bi-directional
associations into two unidirectional
associations
 Again, we must decide which side of
the association should have primacy
and use composition, aggregation
and navigability accordingly
A B1 0..*
A B
1
0..*
1 0..*
«trace»
this side has primacy
© Clear View Training 2010 v2.6 58
Association classes
 There is no commonly used
OO language that directly
supports association
classes
 Refine all association
classes into a design class
 Decide which side of the
association has primacy
and use composition,
aggregation and
navigability accordingly
Company Person
0..* 0..*
Job
salary:double
Company Person
Job
salary:double
0..*0..* 11
«trace»
{each Person can only have one
job with a given Company}
this side
has primacy
© Clear View Training 2010 v2.6 59
Key points (design relationships)
 In this section we have seen how we take the incompletely specified
associations in an analysis model and refine them to:
 Aggregation
• Whole-part relationship
• Parts are independent of the whole
• Parts may be shared between wholes
 Composition
• A strong form of aggregation
• Parts are entirely dependent on the whole
• Parts may not be shared
 One-to-many, many-to-many, bi-directional associations and
association classes are refined in design