Lecture 9
Lecture 6: Design Principles &
System Architecture
Course Outline
W1: Intro
W2: Modelling with UML
W3-4: Design patterns
W5-6: Design principles & system architecture
W7-8: Testing
W9: Continuous integration
W10: Review
Today’s Plan
10:05-11:55:
Quiz 6 (assessed, correctness)
Design principles
System architectures
Design in practice – revisit Lab 2
Long break
13:00-14:00 OR 14:00-15:00 in BO1028: Lab 6 – work on AE1
(tutors will be present) !
Quiz 6
Join YACRS
Session: 1240
Q6.1 UML and system
architecture
In UML this symbol is used to denote a:
A: package called “DataHandlers”
B: component called “DataHandlers”
C: class called “DataHandlers”
D: interface called “DataHandlers”
Q6.1 UML and system
architecture
In UML this symbol is used to denote a:
A: package called “Datahandlers”
B: component called “Datahandlers”
C: class called “Datahandlers”
D: interface called “Datahandlers”
<
InterfaceName
-memberName
-memberName
ClassName
-memberName
-memberName
Q6.2 Multi-Layer
The multi-layer architectural pattern can (in a strict
design/implementation) have dependencies in which
direction(s)?
A: Any connection/dependency between layers is
allowed
B: Higher layers depend on lower layers
C: Both ways
D: Lower layers depend on higher layers
Q6.2 Multi-Layer (solution)
The multi-layer architectural pattern can (in a strict
design/implementation) have dependencies in which
direction(s)?
A: Any connection/dependency between layers is
allowed
B: Higher layers depend on lower layers
C: Both ways
D: Lower layers depend on higher layers
Q6.3 Architectures
Consider the following scenario. The system includes a user
interface, which must interact with a local database. The user
interface is accessed from a mobile device.
Which architectures is most suitable in this scenario?
A: Broker pattern
B: Model View Controller pattern
C: Pipe and filter pattern
D: Transaction processing pattern
Q6.3 Architectures (solution)
Consider the following scenario. The system includes a user
interface, which must interact with a local database. The user
interface is accessed from a mobile device.
Which architectures is most suitable to use in this scenario?
A: Broker architectural pattern
B: Model View Controller
C: Pipe and filter
D: Transaction processing
Design
Properties of “good” design:
Increasing profit by reducing cost and increasing revenue
Ensuring that we actually conform with the requirements
Accelerating development
Increasing qualities such as
Usability
Efficiency
Reliability
Maintainability
Reusability
…
DESIGN Principles
Divide and Conquer
Cohesion
Coupling
Keep the level of abstraction as high
as possible (already covered)
Increase reusability
Reuse existing designs and code
Anticipate obsolescence
Design for portability
Design for testability
Design defensively
Divide and conquer (combine)
Trying to deal with something big all at once is normally
much harder than dealing with a series of smaller things
Separate people can work on each part.
An individual software engineer can specialize.
Each individual component is smaller, and therefore easier
to understand.
Parts can be replaced or changed without having to
replace or extensively change other parts.
Cohesion: High cohesion is good
Functional
Layer
Communicational
Sequential
Procedural
Temporal
Utility
Coupling: High Coupling is Bad
Content
Common
Control
Data
Routine
Type Use
Import
External
Abstraction level should be as high
AS possible
Keeping the level of
abstraction high means being
able to understand or use the
system without knowing and
understanding specific details.
Increase Reusability Where Possible
Design the various aspects of your system so that they
can be used again in other contexts
Generalize your design as much as possible (abstraction)
Ensure cohesion and low coupling
Design your system to contain hooks
Hooks: Which design patterns provide hooks, and how
does this help promote reusability?
Increase Reusability through Hooks
The Factory Pattern allows programmers to add their own
classes into an existing hierarchy, and dynamically setting
a custom factory provides a powerful hook to extend the
Factory Framework.
Reuse existing Designs and Code
Where Possible
(Good) designs and code should be reused.
Why is cloning not considered a good way of reusing
code? What side effects does cloning have?
Cloning is Not Reuse
Copy and Paste is abolished in software engineering.
If a library changes, your clone may not be updated.
Local code can be changed, which makes maintainability
more difficult.
Unless you have an infrastructure to update your clone (for
example using networked version control) a clone is not a
good way to reuse code.
Unless there is some other need to keep a local copy for
reliability reasons. See Tolerating Clones? Page 331.
Design for Flexibility
Actively anticipate changes that a design may have to
undergo in the future, and prepare for them
Reduce coupling and increase cohesion
Create abstractions
Do not hard-code anything
Leave all options open
Do not restrict the options of people who have to modify
the system later
Use reusable code and make code reusable
Identify an alternative to hard coded constraints and
how you would implement this alternative in Java?
Anticipate Obsolescence
Anticipating obsolescence is an important design
principle, but may contradict other design principles.
Which other design principles play a role in anticipating
obsolescence, and how would you balance these
concerns?
Anticipate Obsolescence
Reusing code can be in direct competition with anticipating
obsolescence.
A library or package may cease to be maintained by the
library producer, then you are stuck with a legacy
dependency.
If different parts of a library are not well maintained or
implemented, your dependence on them becomes more
volatile.
For example, OpenCV is a library with a wide variety of
quality in its modules. Dependence on a more experimental
module is more risky.
Design for portability
Designing for portability means designing so that your
software can be run on as many platforms as possible.
One field where this is particularly difficult is mobile platforms
where standardization is limited, and platforms specifically
compete for business by providing different features.
For example, let’s say you want to design a mobile
application that requires an NFC sensor to function properly.
What trade-offs must you consider when deciding to use
NFC features or not?
Example: NFC and Portability
How likely is it that many platforms will support NFC
hardware?
What market forces will influence the continued support
for NFC?
What will happen if a user downloads this app but
doesn’t have the correct hardware?
Design for Testability
Take steps to make testing easier
Design a program to automatically test the software
Discussed more in Chapter 10
Ensure that all the functionality of the code can by driven
by an external program, bypassing a graphical user
interface
In Java, you can create a main() method in each class in
order to exercise the other methods
E.g. the Model View Controller is on way of dividing and
organizing a system architecture. How does the
architecture help or hinder designing for testability?
Design for Testability
Model View Controller separates functionality from a GUI,
but designing for testability goes one step further and
provides methods for running all GUI functions either
through additional main methods or through a
command line interface.
If functionality is coupled to GUI actions, it can be costly
and time consuming to run testing. Large scale testing
would not be practical if testers had to run tests through
the application GUI.
Design Defensively
Not only must you be able to produce code without errors, you
should attempt to make your code robust enough that other
users of your code cannot introduce errors.
How might you refactor this code to design more defensively?
// This is snippet from a Course class.
// A student can be enrolled in a Course, but the ID
// number must be valid
public void enrollStudent(int studentID) {
this.addStudent(studentID);
}
// This is snippet from a Course class.
// A student can be enrolled in a Course, but the ID number
// must be valid
public boolean enrollStudent(int studentID) {
if (checkStudentIDValid(studentID)) {
this.addStudent(studentID);
return true;
}
else {
return false;
}
}
Design Defensively
Software Architecture
Software Architecture
Software architecture is process of designing the global
organization of a software system, including:
Dividing software into subsystems.
Deciding how these will interact.
Determining their interfaces.
The architecture is the core of the design, so all software
engineers need to understand it.
The architecture will often constrain the overall efficiency,
reusability and maintainability of the system.
Architectural Models Support Good
Design
Enable everyone to better understand the system
To allow people to work on individual pieces of the
system in isolation
To prepare for extension of the system
To facilitate reuse and reusability
34
UML for System level modelling
35
Deployment diagrams
MultiLayer Architecture
An abstract example multilayer architecture.
Actual implementations vary….
Multilayer Implementation I
A simple implementation
with procedures…
Demo: mylayeredapp.java
Relaxed multi layer architecture
What happens if the database
changes without the Presentation
layer knowing ?
Can we come up with a
implementation with minimum
coupling that allow a lower layer
to indicate a change ?
Which design pattern would you
use ?
Model View Controller
Notifies
Modifies Creates/Updates
Update/Notify
Update/Notify
Client Server
Transaction-Processing
A process reads a series of inputs one by one.
Each input describes a transaction – a command that
typically some change to the data stored by the system
There is a transaction dispatcher component that decides
what to do with each transaction
This dispatches a procedure call or message to one of a
series of component that will handle the transaction
Pipe-and-Filter
A stream of data, in a relatively simple format, is passed
through a series of processes
Each of which transforms it in some way.
Data is constantly fed into the pipeline.
The processes work concurrently.
The architecture is very flexible.
Almost all the components could be removed.
Components could be replaced.
New components could be inserted.
Certain components could be reordered.
Example: Pipe-and-Filter
Others…
Service oriented
Message oriented
In practise..
Making design decisions
Using priorities and objectives to decide among
alternatives
Step 1: List and describe the alternatives for the design
decision.
Step 2: List the advantages and disadvantages of each
alternative with respect to your objectives and priorities.
Step 3: Determine whether any of the alternatives prevents
you from meeting one or more of the objectives.
Step 4: Choose the alternative that helps you to best meet
your objectives.
Step 5: Adjust priorities for subsequent decision making.
Cost-benefit analysis
To estimate the costs, add up:
The incremental cost of doing the software engineering
work, including ongoing maintenance
The incremental costs of any development technology
required
The incremental costs that end-users and product support
personnel will experience
To estimate the benefits, add up:
The incremental software engineering time saved
The incremental benefits measured in terms of either
increased sales or other financial benefits to users
Design documentation
Design documents as an aid to making better designs
They force you to be explicit and consider the important
issues before starting implementation.
They allow a group of people to review the design and
therefore to improve it.
Design documents as a means of communication.
To those who will be implementing the design.
To those who will need, in the future, to modify the
design.
To those who need to create systems or subsystems that
interface with the system being designed.
Documentation
A. Purpose:
What system or part of the system this design document describes.
Make reference to the requirements that are being implemented by this
design (traceability) .
B. General priorities:
Describe the priorities used to guide the design process.
C. Outline of the design:
Give a high-level description of the design that allows the reader to
quickly get a general feeling for it.
D. Major design issues:
Discuss the important issues that had to be resolved.
Give the possible alternatives that were considered, the final decision and
the rationale for the decision.
E. Other details of the design:
Give any other details the reader may want to know that have not yet
been mentioned.
Documentation: Javadoc
The audience for JavaDoc is Java developers
Keywords
@author (classes and interfaces only, required)
@version (classes and interfaces only, required. See footnote 1)
@param (methods and constructors only)
@return (methods only)
@exception (@throws is a synonym added in Javadoc 1.2)
@see
@since
@serial (or @serialField or @serialData)
@deprecated (see How and When To Deprecate APIs)
http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#footnote1
http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html
Full JavaDoc Overview
http://www.oracle.com/technetwork/articles/java/index
-137868.html
http://www.oracle.com/technetwork/articles/java/index-137868.html
Design in practise – revisit Lab 2
User Requirements to Design
A software for a travel agency provide reservations facilities for the
people who whish to travel on tours by accessing a built-in network
at the agency bureau.
The application software keeps information on all the tours.
Users can access the system to make a reservation on a tour and to
view information about the tours available online.
Users can access the system to cancel a reservation the he/she has
made.
Any complaints or suggestions that the client may have could be
sent by email to the agency or stored in a complaint database.
The employees of the corresponding agency could use the
application to administrate the systems operations. Employees can
add, delete, and update the information on the customers and the
tours.
For security purposes, the employee should be provided a login ID
and password by the manager to be able to access the database
of the travel agency.
User Requirements to UML
A software for a travel agency provide reservations facilities for the
people who whish to travel on tours by accessing a built-in network
at the agency bureau.
The application software keeps information on all the tours.
Users can access the system to make a reservation on a tour and to
view information about the tours available online.
Users can access the system to cancel a reservation the he/she has
made.
Any complaints or suggestions that the client may have could be
sent by email to the agency or stored in a complaint database.
The employees of the corresponding agency could use the
application to administrate the systems operations. Employees can
add, delete, and update the information on the customers and the
tours.
For security purposes, the employee should be provided a login ID
and password by the manager to be able to access the database
of the travel agency.
User Requirements to
UML
A software for a travel agency provide reservations facilities for the
people who whish to travel on tours by accessing a built-in network
at the agency bureau.
The application software keeps information on all the tours.
Users can access the system to make a reservation on a tour and to
view information about the tours available online.
Users can access the system to cancel a reservation the he/she has
made.
Any complaints or suggestions that the client may have could be
sent by email to the agency or stored in a complaint database.
The employees of the corresponding agency could use the
application to administrate the systems operations. Employees can
add, delete, and update the information on the customers and the
tours.
For security purposes, the employee should be provided a login ID
and password by the manager to be able to access the database
of the travel agency.
User Requirements to
UML
A software for a travel agency provide reservations facilities for the
people who whish to travel on tours by accessing a built-in network
at the agency bureau.
The application software keeps information on all the tours.
Users can access the system to make a reservation on a tour and to
view information about the tours available online.
Users can access the system to cancel a reservation the he/she has
made.
Any complaints or suggestions that the client may have could be
sent by email to the agency or stored in a complaint database.
The employees of the corresponding agency could use the
application to administrate the systems operations. Employees can
add, delete, and update the information on the customers and the
tours.
For security purposes, the employee should be provided a login ID
and password by the manager to be able to access the database
of the travel agency.
Model solution (high level)
notifies
Consensus
Summary
Design process
Analysis & Modelling (domain vs system)
Design patterns
Design principles
Architectural patterns
Documentation
Assumptions and trade-offs among priorities are required and
ubiquitous – make sure to provide explanation and rationale for
MAJOR decisions.
Lab 6 at 13:00 or 14:00 in BO1028
Next Week
Testing
Read: OOSE Chapter 10