University of Zimbabwe

Department of Computer Science

HCT210: Software Engineering

Unit 3 : Design

Lecturer: Gibson Mukarakate

Acknowledgements: main course text: “Roger S. Pressman , Software engineering: A practitioner’s approach”, 7th edition, 2010
 Unit 3: Design

Unit Outline
• Concepts
• Architectural Design
• Component-Level Design
• User Interface (UI) Design
• Design Patterns

HCT210: Software Engineering Gibson Mukarakate 2

 Unit 3: Design

Design: Introduction
• Software design involves a set of principles, concepts
and practices that lead to the development of high-
quality software
• For design, software engineers are looking more at the
solution domain (rather than the problem domain
when doing requirements)
• The output is models that are used for system
implementation, i.e. models that are architectural,
interface, component-level and deployment
representations of the system
• The input is the requirements (analysis) models
• Design methodologies are always evolving; and various
methods should be employed to get a better picture

HCT210: Software Engineering Gibson Mukarakate 3

 Unit 3: Design

Design: Introduction
• Requirements models are the input; so thus they feed
into the design process to produce the design models /
artefacts
Requirements models Design
Scenario-based models Component-level design
Data based models Interface design
Class-based models Architectural design
Flow-oriented models Data / Class Design
Behavioural models

• Requirements models are “translated” by the design

process
• The diagram does not show a one-to-one mapping, but
various models on the left are used by various design
processes on the right
HCT210: Software Engineering Gibson Mukarakate 4
 Unit 3: Design

The Design Process

• The design is the blueprint of the system to be
implemented in order to produce quality
software
• The quality guidelines used are:
1. Design must implement all explicit and implicit
requirements of all users and stakeholders
2. Design must be readable and understandable to
those who will code, test and support the system
3. Design should provide a complete picture of the
software: data, functions, behaviour

HCT210: Software Engineering Gibson Mukarakate 5

 Unit 3: Design

The Design Process

• Similarly, the quality attributes used are:
1. Functionality: features
2. Usability: aesthetics, consistency, documentation
3. Reliability: accuracy, recovery from failure,
availability
4. Performance: processing speed, response time,
throughput, resource usage
5. Supportability / maintainability: extensibility,
adaptability, serviceability
• All the above are also referred to as the FURPS
quality attributes

HCT210: Software Engineering Gibson Mukarakate 6

 Unit 3: Design

Design Concepts
• Design concepts have developed over time; all
aiming to answer the following questions:
1. How do we partition software into components?
2. How do we separate data structure and function
detail from conceptual representation of software?
3. What uniform criteria define the technical quality of
software design ?
• M. A. Johnson said: “the beginning of wisdom is
to recognise the difference between getting a
program to work, and getting it right”
• The next slides look at some design concepts
HCT210: Software Engineering Gibson Mukarakate 7
 Unit 3: Design

Design Concepts
1. Abstraction
 Explore many levels of abstraction, from high (in problem
domain) to the lowest (in solution domain)
2. Architecture
 Design should derive an architecture of the system;
within which more detailed design is conducted.
Architecture is structure of program components
(modules), how they interact, and the structure of the
data they use
3. Patterns
 Apply existing patterns to problems with known
solutions. A design pattern is an insight which conveys
the essence of a proven solution to a recurring problem
within a certain context

HCT210: Software Engineering Gibson Mukarakate 8

 Unit 3: Design

Design Concepts
4. Separation of Concerns
 This concept suggests that design can be handled if
the complex system is divided into pieces of separate
concerns. A concern is a feature / behaviour of a
system
5. Modularity
 Design should divide the system into separate
modules to handle complexity. Note that; at some
point the sub-division will start to be not beneficial,
or even costly
6. Information hiding
 In order to sub-divide a system, look at ways you can
ensure that data and algorithms in each module are
inaccessible to other modules
HCT210: Software Engineering Gibson Mukarakate 9
 Unit 3: Design

Design Concepts
7. Functional Independence
 A module should be “single-minded” and “averse to
excessive interaction with others”. It is assessed by
two quality attributes: cohesion and coupling
8. Refinement
 Refinement, usually from high to low abstraction
levels, adding more detail. It is an “elaboration”
process.
9. Aspects
 Isolate “cross-cutting concerns” (“aspects”) so that
they can be re-used by various modules
HCT210: Software Engineering Gibson Mukarakate 10
 Unit 3: Design

Design Concepts
10. Refactoring
 a technique of re-organising a design (or code)
by simplifying it, but without changing its
functionality
11. Object-oriented Design concepts
 Concepts used in OOD
 They basically focus on creating design classes.
There are different analysis classes are discussed
in the next slides, together with the design
concepts applied for classes
HCT210: Software Engineering Gibson Mukarakate 11
 Unit 3: Design

Design Concepts : OOD concepts

• The different design class types are:
1. User interface classes : for human computer
interaction (HCI)
2. Business domain classes: identified from
analysis, representing actual objects in the
business domain. Also called entity classes
3. Process classes: for managing business processes
4. Persistent classes: for storing data to data stores
5. System classes: for system management and
control
HCT210: Software Engineering Gibson Mukarakate 12
 Unit 3: Design

Design Concepts : OOD concepts

• The characteristics of “well-designed” classes
are:
1. Complete and sufficient
 Class encapsulates all required attributes and methods
2. Primitiveness
 A method must accomplish only one service for a class, and
that service must be provided by that one method
3. High cohesion
 A class must have a small, focused set of responsibilities
4. Low coupling
 Collaboration of classes within a design should be kept at a
minimum. A class must have limited knowledge of other
classes
HCT210: Software Engineering Gibson Mukarakate 13
 Unit 3: Design

The Design Model

• The design model will consist of various
elements; which can be broadly categorised
as:
1. Data design elements
2. Architectural design elements
3. Interface design elements
4. Component-level design elements
5. Deployment-level design elements
• All elements can be expressed using UML;
similar to analysis elements
HCT210: Software Engineering Gibson Mukarakate 14
 Unit 3: Design

The Design Model:

Data design elements
• Concerned how the data used in the system
is modelled
• The model should be able to be translated to
how the data is going to be stored, e.g. into a
database

HCT210: Software Engineering Gibson Mukarakate 15

 Unit 3: Design

The Design Model:

Architectural design elements
• Concerned with structure of data and system
components
• High level interaction between various sub-
systems of the system
• Similar to a floor plan of a house
• Each sub-system will also have its own
architecture

HCT210: Software Engineering Gibson Mukarakate 16

 Unit 3: Design

The Design Model:

Interface design elements
• Specify how the system interfaces with other
components, even among sub-systems; and
could be:
1. User interface (UI)
2. External interface to other systems
3. Internal interfaces between sub-systems

HCT210: Software Engineering Gibson Mukarakate 17

 Unit 3: Design

The Design Model:

Component-level design elements
• Detailed models for each of the sub-systems
and components
• Specific classes, class members (attributes,
operations), relationships, algorithms, etc are
found in this category

HCT210: Software Engineering Gibson Mukarakate 18

 Unit 3: Design

The Design Model:

Deployment-level design elements
• Indicates how software functionality and sub-
systems will be allocated within the physical
computing environment
• Environment details like location and specific
computing resources (e.g. servers) are found
in these models

HCT210: Software Engineering Gibson Mukarakate 19

 Unit 3: Design

Architectural Design
• Concerned with structure of data and system
components; and their inter-relationships
• Architecture is overall structure / “shape”
• The output is overall data and program
structure; and their inter-relationships
• Architectural design elements are made from
different viewpoints
• There are various architectural design
patterns that can be applied
HCT210: Software Engineering Gibson Mukarakate 20
 Unit 3: Design

Architectural Structures
• There are five foundation architectural
structures; as described by their components,
relationships (connectors) and properties that
differentiate the components and connectors:
1. Functional: components are functions or processing
units; while connectors represent interfaces that
“pass data to” or “use” another component
2. Implementation: components are packages, classes,
procedures functions, etc that represent different
levels of abstraction. Connectors are for passing data
and control. Properties focus on quality of the
structure

HCT210: Software Engineering Gibson Mukarakate 21

Unit 3: Design

Architectural Structures
3. Concurrency: components are units of
concurrency
4. Physical: focus on where components are
located, e.g. deployment
5. Developmental: relating to work products
during the software engineering process

HCT210: Software Engineering Gibson Mukarakate 22

 Unit 3: Design

Architectural Styles
• a design may also fit a particular well known
architectural style or form. The are various
styles:
1. Data-centred : a data store is at the center
2. Data-flow: focus on inputs, processes and
outputs
3. Call and return: function id decomposed into a
control hierarchy and components invoke each
other
4. Object-oriented: components encapsulate data
5. Layered: system decomposed into various layers
HCT210: Software Engineering Gibson Mukarakate 23
 Unit 3: Design

The Architectural Design process

• The architectural design process an be
summarised into the following tasks:
1. Putting the whole system into context using an
architectural context diagram (ACD)
2. Identifying a set of architectural archetypes. An
archetype is an abstraction that represents one
element of the system
3. For each archetype, a refinement process is done to
further identify components that implement the
archetype (This is an Elaboration process)
4. Describing instantiations of the system
• The process is repeated iteratively until the
architecture is derived

HCT210: Software Engineering Gibson Mukarakate 24

 Unit 3: Design

The Architectural Design process

Step 1: The System in Context
• An architectural context diagram (ACD) has
the system and all other systems it interacts
with; and their interfaces
• It is derived from information within the
analysis models
• Systems that interact with the target system
(system being developed) are:
1. Superordinate systems: use the target system as
part of some higher-level processing

HCT210: Software Engineering Gibson Mukarakate 25

Unit 3: Design

The Architectural Design process

Step 1: The System in Context
2. Subordinate systems: used by the target system
to provide data or processing that the target
system depends on
3. Peer-level systems: systems that interact with
the target system on a peer-to-peer basis, i.e.
information is either produced / consumed by
peers
4. Actors: entities (people or devices) that use the
target system

HCT210: Software Engineering Gibson Mukarakate 26

Unit 3: Design

The Architectural Design process

Step 1: The System in Context
Superordinate systems

Used by

Target System
Uses
Uses Peers
Actors

Depends on

Subordinate systems

HCT210: Software Engineering Gibson Mukarakate 27

 Unit 3: Design

The Architectural Design process

Step 2: Defining archetypes
• An archetype is a class or pattern that
represents a core abstraction of a system
component / element
• These are derived from classes identified in the
analysis models
• They represent recurring functional patterns
within a solution, e.g. data store elements, HCI
elements, directories, etc
• Archetypes need to be few and at a high level of
abstraction
HCT210: Software Engineering Gibson Mukarakate 28
 Unit 3: Design

The Architectural Design process

Step 2: Defining archetypes
• Archetypes are table elements that can be
instantiated differently based on the
behaviour of the system
• Examples are: Node, Role, Controller,
Description, Moment-Interval, Place, Thing

HCT210: Software Engineering Gibson Mukarakate 29

 Unit 3: Design

The Architectural Design process

Step 3: Refining the Architecture into
Components
• Refining the architecture is done using the
classes identified during analysis. Classes are
usually found from the following sources:
1. Application (business) domain: domain entities
2. Infrastructure domain: interfaces to other systems,
communication components, data store
components management components
3. Graphical user interface (GUI) components
• Refined model can be depicted as a component
diagram in UML

HCT210: Software Engineering Gibson Mukarakate 30

 Unit 3: Design

The Architectural Design process

Step 3: Refining the Architecture into
Components
• Further elaboration is done to produce
design classes within each of the
components
• The classes have high level operations and
properties but not the design details of
operations and attributes are not until
component-level design

HCT210: Software Engineering Gibson Mukarakate 31

 Unit 3: Design

The Architectural Design process

Step 4: Describing Instantiations
• An instantiation of the architectural design is
applied to a specific problem to prove that the
structure style and components are appropriate
• A UML component diagram is used to illustrate
the instantiation
• This leads to more detail
• Further iterations through the 4 steps continue
to elaborate the architectural design

HCT210: Software Engineering Gibson Mukarakate 32

 Unit 3: Design

The Architectural Design process

Alternative approaches
• One alternative approach to the architectural
design is to use the data flow diagram;
starting off with the high level context
diagram and refining it

HCT210: Software Engineering Gibson Mukarakate 33

 Unit 3: Design

Component-Level Design
• Elaborates the architectural design by designing
the details within each component
• For each component, the following details are
designed:
i. Data structures
ii. Algorithms
iii. Interfaces and communication mechanisms
• A component is a modular, deployable, and
replaceable part of a system that encapsulates
implementation and exposes a set of interfaces
• It is an iterative elaboration process
HCT210: Software Engineering Gibson Mukarakate 34
 Unit 3: Design

Component-Level Design:
The Component
• The are different views of components:
1. Object-oriented view
 Detailed set of collaborating classes; with their operations,
attributes, relationships
 Derived from the analysis classes
2. Traditional (functional) view
 The component is a functional element with processing
logic and its data structures; and can be: control, problem
domain or infrastructure component
 They are derived from data flow diagrams
3. Process-related view
 Used when components are designed from existing re-
usable components

HCT210: Software Engineering Gibson Mukarakate 35

 Unit 3: Design

Designing Class-Based Components:

Design Principles
• The are four main design principles from object-
oriented design:
1. The Open-Closed Principle (OCP)
 “A component should be open for extension but closed for
modification”
 E.g. Can be achieved by using an interface in Java
2. The Liskov Substitution Principle (LSP)
 “Subclasses should be substituted for their the base
classes”
 A component that uses a base class should continue to
work properly when the base class is substituted by its
subclass, i.e. a subclass should honour the contract (pre-
and post- conditions) between a base class and
components that use it
HCT210: Software Engineering Gibson Mukarakate 36
Unit 3: Design

Designing Class-Based Components:

Design Principles
3. The Dependency Inversion Principle (DIP)
 “Depend on abstraction. Do not depend on
concretions”
 If this is not followed extending components will
become more difficult
4. The Interface Suggestion Principle (ISP)
 “Many client-specific interfaces are better than one
general purpose interface”
 If a component serves any clients, it is best to create
many different interfaces for each of the clients;
rather than one big interface with all the operations
HCT210: Software Engineering Gibson Mukarakate 37
 Unit 3: Design

Designing Class-Based Components:

Design Principles
• The following are additional packaging
principles for component-level design:
1. The Release-Reuse Equivalency Principle (REP)
 “the granule of reuse is the granule of release”
 It should be possible to support & maintain older
version of component when a component changes
2. The Common Closure Principle (CCP)
 “classes that change together belong together”
3. The Common Reuse Principle (CRP)
 “classes that are not re-used together should not be
grouped together”
HCT210: Software Engineering Gibson Mukarakate 38
 Unit 3: Design

Designing Class-Based Components:

Design Guidelines
• These apply to components, their interfaces,
their dependencies and their inheritance
properties
– Component names should come from the
architectural design models
– Interfaces should be on the left of the component is
UML diagrams; and only relevant interfaces in a
context should be shown
– Dependencies and Inheritance: for readability,
model dependencies from left to right; and
inheritance from bottom (subclasses) to top (base
class)

HCT210: Software Engineering Gibson Mukarakate 39

 Unit 3: Design

Designing Class-Based Components:

Design Guidelines
• Cohesion
 “single-mindedness” where a component
encapsulates only attributes and operations that are
closely related to one another and to the
component itself
 There should be higher cohesion
 Different types are: functional, layer (higher layer
components access lower ones, but not vice versa)
and communicational cohesion
 It makes implementation, testing and maintenance
easier

HCT210: Software Engineering Gibson Mukarakate 40

 Unit 3: Design

Designing Class-Based Components:

Design Guidelines
• Coupling
 Qualitative measure of the degree to which
classes are inter-connected
 There should be low coupling
 Examples of types of coupling are: content,
common, control, data, type use,
inclusion/import, external, etc

HCT210: Software Engineering Gibson Mukarakate 41

 Unit 3: Design

The Component-Level Design

Process
• Step 1: Identify all design classes that
correspond to the problem domain
• Step 2: Identify all design classes that
correspond to the infrastructure
• Step 3: Elaborate all design classes that are
not acquired as reusable components
 Describe in detail all interfaces, attributes and
operations of every class, using design heuristics
e.g. cohesion and coupling
HCT210: Software Engineering Gibson Mukarakate 42
Unit 3: Design

The Component-Level Design

Process
 Step 3a: Specify message details when classes or
components collaborate
 Message details form the basis of operations; and are
expressed as:
[guard condition] sequence expression (return value) :=
message name (argument list)
 Where:
 [guard condition] : specifies set of conditions that must be met
before the message can be sent in OCL (object constraint lang)
 sequential order : ordering integer indicator (e.g. 3.2) that the
sequential order in which a message is sent
 (return value) : name of information returned by the
operations invoked by the message
 message name : identifies the operation that is to be invoked
 (argument list) : list of attributes passed to the operation
HCT210: Software Engineering Gibson Mukarakate 43
Unit 3: Design

The Component-Level Design

Process
 Step 3b: Identify appropriate interfaces for each
component
 A UML interface (in component-level design) is a
group of externally visible (public) operations
 It’s an abstract class (e.g. Java interface) that provides
a controlled connection between design classes …
and has no attributes
 It is cohesive, focussing on one limited function

HCT210: Software Engineering Gibson Mukarakate 44

Unit 3: Design

The Component-Level Design

Process
 Step 3c: Elaborate attributes and define data types
and data structures required to implement them
 Data structures and types can now be expressed in the
implementation language; in form:
name : type expression = initial-value {property string}
 Where:
 name : attribute name
 type expression : data type
 initial-value : (default) value taken by attribute at object creation
 property string : defines a property / characteristic of the
attribute
 Example:
marital-status : string = “S” {any of values “S”, “M”, “D”, “W”)
 Further refinement can be done e.g. if a complex type needs
its own class

HCT210: Software Engineering Gibson Mukarakate 45

Unit 3: Design

The Component-Level Design

Process
 Step 3d: Describe processing flow within each
operation in detail
 This can be done using pseudocode or a UML activity
diagram
 Any detailed operation can then be examined to see if
there is need for further refinement

HCT210: Software Engineering Gibson Mukarakate 46

 Unit 3: Design

The Component-Level Design

Process
• Step 4: Describe persistent data sources (e.g. databases
and files) and identify the classes that are required to
manage them
 Database and table schema design are done at this stage
• Step 5: Develop and elaborate behavioural
representations for a class or component
 UML state diagrams for design classes that warranty them
 There is more detail for every transition; in the form:
event-name (parameter-list) [guard-condition] / action expression
 Where:
 event-name : name of event
 parameter-list : data associated with the event
 guard-condition: condition that must be met before event can
occur
 action expression : action that occurs as the transition takes place

HCT210: Software Engineering Gibson Mukarakate 47

 Unit 3: Design

The Component-Level Design

Process
• Step 6: Elaborate deployment diagrams to
provide additional implementation detail
 Detail on where the components will be can now be
provided including hardware and operating systems
 Deployment diagrams are architectural components
• Step 7: Refactor every component-level design
representation and always consider alternatives
 Iterations through the design are done and models
are refactored
 Various alternative design solutions are considered
and weighed
HCT210: Software Engineering Gibson Mukarakate 48
 Unit 3: Design

The Component-Level Design

Process: Other approaches
• The approach discussed so far is main object-
oriented. Others include:
i. Flow-oriented: e.g. flowcharts
ii. Tabular notation: e.g. decision tables
iii. Program design language: a structured
pseudocode language
iv. Component-based software engineering (CBSE):
use of existing reusable components to build
new software

HCT210: Software Engineering Gibson Mukarakate 49

 Unit 3: Design

User Interface (UI) Design

• Important part of systems as it is the medium of communication
between user and system, i.e. for human computer interaction
(HCI)
• Systems should have good “usability”: a qualitative measure of
the ease and efficiency of use
• A bad UI can render a system with correct functionality a failure
• There are also design principles, guidelines and processes for
design usable systems
• Principles and guidelines are captured in the “golden rules”;
which will be discussed first
• However, it should be remembered that there are basically three
(3) types of interfaces:
i. Between a system and humans
ii. Between system components
iii. Between systems and non-human consumers & producers of data

HCT210: Software Engineering Gibson Mukarakate 50

 Unit 3: Design

User Interface Design:

The Golden Rules
• The golden rules can be quickly summarised
as follows:
1. Place the user in control
2. Reduce the user’s memory load
3. Make the interface consistent

• The next slides will discuss each the golden

rules in detail

HCT210: Software Engineering Gibson Mukarakate 51

 Unit 3: Design

UI Golden Rules:
1. Place the User in Control
i. Define interaction modes in a way that does
not force a user into unnecessary or
undesired actions
ii. Provide for flexible interaction
 Different mechanisms for different people, e.g.
keyboard, mouse, touch, voice, etc
iii. Allow user interaction to be interruptible and
undoable
iv. Streamline interaction as skill levels advance
and allow the interaction to be customised
HCT210: Software Engineering Gibson Mukarakate 52
 Unit 3: Design

UI Golden Rules:
1. Place the User in Control
v. Hide technical internals from the casual user
 Users should not know underlying technology and
system commands
vi. Design for direct interaction with objects
that appear on the screen
 Allow users to manipulate objects in ways that are
close to what they do in the physical world

HCT210: Software Engineering Gibson Mukarakate 53

 Unit 3: Design

UI Golden Rules:
2. Reduce the User’s Memory Load
1. Reduce demand on short-term memory
 Reduce the user's requirement to remember past actions and results
by providing visual cues of such actions, e.g. the “bread crumb trail”
2. Establish meaningful defaults
 Meaningful defaults for values; and user can reset back to them
3. Define shortcuts that are intuitive
 E.g. keyboard shortcuts with appropriate letter; or highlighted
letter
4. The visual layout of the interface should be based
on a real world metaphor
5. Disclose information in a progressive fashion
 E.g. hierarchical menus
HCT210: Software Engineering Gibson Mukarakate 54
 Unit 3: Design

UI Golden Rules:
3. Make the Interface Consistent
• Interface presentation and information acquisition
mechanisms should be consistent, implying:
i. Visual information displays consistently throughout all screens
ii. Input mechanisms are limited to a limited set that is used
consistently within the system
iii. Mechanisms for navigating from task to task are consistently
defined and implemented
1. Allow the user to put the current task into a
meaningful context
 Icons, colour coding, tiles should show where the user is
2. Maintain consistency across a family of applications
3. If previous models have created user expectations, do
not make changes unless there is a compelling reason to
do so
HCT210: Software Engineering Gibson Mukarakate 55
 Unit 3: Design

The User Interface Analysis & Design

Process
• The process has four key activities:
i. Interface Analysis (user, task, and environment analysis)
ii. Interface Design
iii. Interface Construction
iv. Interface Validation
• The process is a spiral process: where after
activities are done, a prototype is produced and
validated; then another “pass” through the
model is done to incorporate feedback

HCT210: Software Engineering Gibson Mukarakate 56

 Unit 3: Design

The UI Analysis & Design Process

1. Interface Analysis
• Analysis focuses on the following four:
i. User analysis
ii. Task analysis
iii. Content analysis (display content)
iv. Work environment analysis

1. User analysis
 Users are the ones who will use the system
 Focus on analysing the users; and how they will use the
system
 Questions include: user skills/education, user language,
from which departments, their age, consequences of
making mistakes, working times, remuneration, gender,
etc
HCT210: Software Engineering Gibson Mukarakate 57
 Unit 3: Design

The UI Analysis & Design Process

1. Interface Analysis (contd.)
2. Task analysis
 The work done, and in what specific scenarios
 Tasks and sub-tasks of every work unit
 Domain objects manipulated during the tasks
 Sequence of work tasks (workflow)
 Hierarchy of tasks
• Use cases are crucial in identifying:
 How end users perform tasks
 Exact tasks, objects manipulated, and workflow (these can
then be elaborated further)
 System features

HCT210: Software Engineering Gibson Mukarakate 58

 Unit 3: Design

The UI Analysis & Design Process

1. Interface Analysis (contd.)
3. Content analysis
 Display content can be text, graphs, pictures, videos,
etc
 The following questions need to be asked:
 What is the geographical location of components on
the screen? Pictures, menus, navigation tools, etc.
 Can users customise content location?
 If a lot of data is displayed; how can it be presented?
 What summarisation can be done?
 What colours are used?
 What warning / error messages are shown? How ?

HCT210: Software Engineering Gibson Mukarakate 59

 Unit 3: Design

The UI Analysis & Design Process

1. Interface Analysis (contd.)
4. Work Environment analysis
 Amount of lighting in workspace
 Height / size of display mechanism
 Workspace size
 Temperature and humidity conditions
 Keyboard size, height
 Workspace time restrictions

HCT210: Software Engineering Gibson Mukarakate 60

 Unit 3: Design

The UI Analysis & Design Process

2. Interface Design
• The design process is an iterative process;
where refinement is done at each iteration
• The general steps are:
1. From user interface analysis information, define user
interface objects and actions (operations)
2. Define events (user actions) that will cause the state
of the UI to change; model them
3. Depict each interface state as it will actually look to
the end user (e.g. using diagrams)
4. Indicate how the user interprets the state of the
system from information provided through the
interface

HCT210: Software Engineering Gibson Mukarakate 61

 Unit 3: Design

The UI Analysis & Design Process

2. Interface Design (contd.)
• All the steps are done with the UI Golden Rules in
mind
• The common design issues that must be considered
are usually the following:
i. System response time (both length and variability)
ii. User help facilities
iii. Error information handling
 How meaningful to the user, how descriptive of the problem
 Plain language, constructive, consequences, visual, non-
judgemental tone
iv. Menu and command labelling
 Consistency, easy to learn, accessibility, internationalization,
menu / sub-menu relatedness
HCT210: Software Engineering Gibson Mukarakate 62
 Unit 3: Design

The UI Analysis & Design Process

3. Interface Construction
• From the earlier steps, a prototype is
created; showing all the
• Physical material like paper can be used to
model early prototypes of the UI
• Other computer-based design tools can be
used

HCT210: Software Engineering Gibson Mukarakate 63

 Unit 3: Design

The UI Analysis & Design Process

4. Interface Validation
• Evaluation criteria should be based on:
 Amount of learning required by the users
 System-User interaction time and overall efficiency
 Number of user tasks, average actions per task
 The memory load on users
 Number of actions, tasks, and system states
 The complexity of the interface and the degree to
which it will be accepted by the user
• Evaluation feedback is fed back into the spiral
process
HCT210: Software Engineering Gibson Mukarakate 64
 Unit 3: Design

The UI Analysis & Design Process

4. Interface Validation (contd.)
• Evaluation can be done with test drives with
users; and statistics collected and
documented
• Every prototype is evaluated for:
 Satisfaction of user requirements
 Conformance to the three golden rules of user
interface design

HCT210: Software Engineering Gibson Mukarakate 65

 Unit 3: Design

Design Patterns
• A design pattern describes a problem that
occurs repeatedly, a solution that can be
applied to it; and the context in which it
occurs
 Context allows the reader to understand the
environment within which problem occurs, the
appropriate solution within that environment
 A set of requirements, limitations and constraints act
a system of forces to influence how the problem is
interpreted within that context
• Patterns are a key foundation for reuse
HCT210: Software Engineering Gibson Mukarakate 66
 Unit 3: Design

Design Patterns
• Design patterns in software engineering have
their origin from building architecture:- from
the writings of the building architect
Christopher Alexander in the 1970s
• In software engineering one of the early
seminal works is “Design Patterns: Elements of
Reusable Object-Oriented Software” (Gamma,
et al) which is popularly known as the “Gang of
Four” or “GoF” book
• It is one of the first book to have
comprehensively cover the topic of software
design patterns; and was within the “object-
oriented” paradigm
HCT210: Software Engineering Gibson Mukarakate 67
 Unit 3: Design

Characteristics of a Design Pattern

1. It solves a problem
2. It is a proven concept
 the solution has a proven track record
3. The solution isn’t obvious
 It’s for a complex problem
4. It describes a relationship (deeper system
structures)
5. The pattern has a significant human
component (minimises human intervention)
HCT210: Software Engineering Gibson Mukarakate 68
 Unit 3: Design

Kinds of Design Patterns

• Patterns can be characterised as follows:
1. Architectural patterns
 Broad-based, high-level design patterns
2. Data patterns
 For data level (lower abstraction) problems
3. Component patterns (commonly referred to as just “design
patterns”)
 For problems within components / subsystems
4. Interface design patterns
 For common user interface problems
5. Integration design patterns
 Deal with problems and solutions for systems integration
6. WebApp patterns
 Address common problems in web applications
• Note that idioms are at lower level structures like
algorithms and specific data structures
HCT210: Software Engineering Gibson Mukarakate 69
 Unit 3: Design

Object-oriented Design Patterns

• These are categorised in the GoF book as:
1. Creational patterns
 Focus on object creation, composition & representation
2. Structural patterns
 How classes are organised and integrated to build larger
structures
3. Behavioural patterns
 Concerned with how responsibility is assigned among
objects; and their intercommunication

HCT210: Software Engineering Gibson Mukarakate 70

 Unit 3: Design

Design Patterns vs Frameworks

• A framework provides a whole implementation of
a solution that provides specific functionality (a
reusable “mini-architecture”)
• A framework is broader than a pattern; and will
usually incorporate one of more patterns
• Key differences can be summarised as:
i. A pattern is more abstract than a framework
ii. A pattern is a smaller architectural element than a
framework
iii. A pattern is les specialised than a framework
HCT210: Software Engineering Gibson Mukarakate 71
 Unit 3: Design

Design Pattern template (form)

• A design pattern is described using the form:
1. Name: should be named appropriately
2. Problem
3. Motivation: problem example
4. Context: environment within which it is applied
5. Forces: any limitations & constraints
6. Solution
7. Intent: what it does
8. Collaborations: how other patterns contribute to the
solution
9. Consequences: potential issues & trade-offs
10. Implementation
11. Known uses: examples of actual usage
12. Related patterns
HCT210: Software Engineering Gibson Mukarakate 72
 Unit 3: Design

Pattern-based Design
• Pattern-based design is usually used alongside
other design methods
• It comes in when the problem is extracted; and
the designers look if any design applies to it:
1. Extract problems
2. Extract the problems context forces (limitations &
constraints)
3. If a pattern addresses the problem, then do design tasks (see
later). If not; use other methods.
• The patterns will then be incorporated in the
design model; like elements from any other
methods
HCT210: Software Engineering Gibson Mukarakate 73
 Unit 3: Design

Pattern-based Design:
“Thinking in patterns”
• Patterns thinking is enabled by the following
approach:
1. Understand the big picture
2. Examine the big picture and extract patterns at that
abstract level
3. Begin with the big picture patterns to establish context
4. Work inward from the context to get lower level
patterns
5. Repeat Steps 1-4 until the is a complete design
6. Refine the design: adapt each pattern to your specific
software
HCT210: Software Engineering Gibson Mukarakate 74
 Unit 3: Design

Pattern-based Design: Design Tasks

1. Examine requirements model & develop a problem hierarchy
2. Determine a reliable pattern language for the domain
 A pattern language is a collection of design patterns described using the
pattern template; which applies to a specific domain
3. Beginning with a broad problem, determine is any architectural
patterns are available
4. Using collaborations in the architectural pattern, examine
subsystem / component-level problems and determine specific
patterns for them
5. Repeat Steps 1-4 until all broad problems have been solved. This is
an elaboration process
6. If user design problems have been isolated, search for their
appropriate user interface patterns
7. For every candidate pattern, examine context & forces to ensure
that it provides a solution to the problem
8. Refine the design using design quality criteria guidelines:
functionality, usability, reliability, performance, serviceability
(FURPS)
HCT210: Software Engineering Gibson Mukarakate 75
 Unit 3: Design

Pattern-based Design:
Using the Pattern-organising Table
• Once patterns have been identified, categorise them
using a pattern-organising table as shown below:
Database Application Implementation Infrastructure
Data / Content
Problem statement … Patten name(s) Patten name(s) Patten name(s)
Problem statement … Patten name(s) Patten name(s)

Architecture
Problem statement … Patten name(s) Patten name(s) Patten name(s)
Problem statement … Patten name(s) Patten name(s) Patten name(s)

Component-level
Problem statement …
Problem statement … Patten name(s) Patten name(s)

User Interface
Problem statement … Patten name(s) Patten name(s)
Problem statement … Patten name(s) Patten name(s)

HCT210: Software Engineering Gibson Mukarakate 76

 Unit 3: Design

Example Design Patterns:

Architectural patterns
• Access control
• Concurrency
• Distribution
• Persistence

HCT210: Software Engineering Gibson Mukarakate 77

 Unit 3: Design

Example Design Patterns:

Component-Level patterns
• Patterns within the components , e.g. for
common problem of searching, you may have:
– Search box
– Search results

HCT210: Software Engineering Gibson Mukarakate 78

 Unit 3: Design

Example Design Patterns:

User Interface patterns
• Top Level Navigation
• Default-values-in-Input-boxes
• Bread Crumbs
• Shopping Cart
• Progress Indicator/Bar
• Sortable Table

HCT210: Software Engineering Gibson Mukarakate 79

 Unit 3: Design

Example Design Patterns:

Integration patterns
• Message Translator
• Message Router
• Point-to-point
• Publish-Subscribe
• Message Filter

HCT210: Software Engineering Gibson Mukarakate 80

 Unit 3: Design

Example Design Patterns:

Object-oriented Design (GoF) patterns
• Creational
 Abstract factory, Factory method, Singleton, Builder,
Prototype
• Structural
 Adapter, façade, aggregate, bridge, composite,
container, proxy, pipes & filters
• Behavioural
 Chain of responsibility, event listener, command,
interpreter, iterator, mediator, visitor, single-serving
visitor, hierarchical visitor

HCT210: Software Engineering Gibson Mukarakate 81

 Unit 3: Design

Design Patterns:
Common mistakes
• Patterns are not a solution to everything; there
can be the following common mistakes:
i. Misfit: Forcing a pattern to fit where it doesn’t.
This will negatively affect the system design and
architecture
ii. Not using a pattern where it should be used: This
will result in a poor design, “reinventing the
wheel”, wasting time, inefficiency
• Mistakes can be addressed by using design
reviews to ensure proper fit
HCT210: Software Engineering Gibson Mukarakate 82
Unit 3: Design

END

HCT210: Software Engineering Gibson Mukarakate 83