Topic 5:

Software Design and

Development/Implementation

Instructor: Dr. Bii

 Introduction
 Software design is a process of translating
requirements into a “blueprint” for
constructing the software.
 Initial blueprint depicts a holistic view of
software. This design is represented at a
high level of abstraction.
 Later iterations and refinement lead to
design representations at much lower levels
2 of abstraction.
 … Introduction

 Design produces various representations

of the software that serve as a guide for
the construction activity.
 Pressman (p. 225) – “Design creates a
representation or model of the software, but unlike the
requirements model (that focuses on describing required
data, function, and behavior), the design model provides
detail about software architecture, data structures,
interfaces, and components that are necessary to
3 implement the system”.
 Design activities

4
5
 Design Steps

 Both Pressman & Sommerville list 4

steps:
– Data(base) / class design;
– Architecture design;
– Interface design; &
– Software components design.
 These steps are applicable across
6 various types of software.
 Data/Class Design

 Creation of a model of data and or

information represented at a high level of
abstraction (user views of data).
 These representations are progressively
refined to more implementation-specific
representations suitable for computer-
based system.

7
 … Data/Class Design

 At the application level, the data model is

translated into a database – that meets
the business objectives of an
organization.
 Many disparate databases may be
organized into data warehouses – to
facilitate data mining and knowledge
discovery. (Refer ISK 222)
8
 Architectural Design

 Architectural design is concerned with

the definition of an overall structure and
organization of a software system.
 It identifies the main structural
components in a system and the
relationships between them.

9
 … Architectural Design
 Its output is an architectural model that
describes how the system is organized
as a set of communicating components.
 Example: architectural design of a
packing robot (below):

10
 … packaging robot

11
 … architectural design

 Sommerville (p. 169) observes that:

− You may start with an abstract system
architecture that associates groups of
system functions or features with large-scale
components or subsystems.
− You then use this decomposition to discuss
and create more detailed features of the
system.

12
 … architectural design

 Sommerville (p. 169) identifies 2 levels of

abstraction in architectural designs:
– Architecture in the small, and
– Architecture in the large.
 Architecture in the small – is concerned
with how individual programs are
decomposed into their components;
13
 … architectural design

 Architecture in the large - is concerned

with the architecture of complex
enterprise systems that include other
systems, programs, and program
components.

14
 Advantages of an architecture
 Stakeholder communication
– Architecture may be used as a focus of discussion
by system stakeholders.
 System analysis
– Analysis to determine if the system can meet its
non-functional requirements is possible.
 Large-scale reuse
– The architecture may be reusable across a range of
systems; product-line architectures (same domain)
15 may be developed.
 Architectural Representations

 Software architectures may be modelled

using:
– Block diagrams:

Block diagrams present a high-

level picture of the system
structure, which people from
different disciplines, who are
involved in the system
development process, can
readily understand.
16
 … box diagrams

 Each box represents a component.

 Boxes within boxes indicate that the
component has been decomposed to
subcomponents.
 Arrows mean that data and or control
signals are passed from component to
component in the direction of the arrows.
17
 Architectural Design Decisions

 Architectural design is a creative process,

with no universal steps to follow.
 Sommerville considers it as a series of
decisions to be made rather than series of
activities (diagram below).
 The decisions span all design processes.

18
 … architectural design decisions

19
 Architectural views

 As noted under modelling, a system has

many perspectives – views.
 Recall the perspectives that we
discussed:
– External;
– Interaction;
– Structural; &
– Behavioural perspectives.
20
 … architectural views

 So, it is necessary to answer:

– What views or perspectives are useful
when designing and documenting a
system’s architecture?
– What notations should be used for
describing architectural models?

21
 … architectural views

 It is impossible to represent all relevant

information about a system’s architecture
in a single diagram.
 A graphical model can only show one
view or perspective of the system – e.g.
how a system is decomposed into modules, how the
runtime processes interact, or the different ways in
which system components are distributed across a
network.
22
 … architectural views

 There are 4 possible views:

23
 … architectural views

 A logical view, which shows the key

abstractions in the system as objects or
object classes.
 A process view, which shows how, at
run-time, the system is composed of
interacting processes.

24
 … architectural views

 A development view, which shows how

the software is decomposed for
development – breakdown into
components to be developed.
 A physical view, which shows the system
hardware and how software components
are distributed across the processors in
the system.
25
 … Representing arch. views

 Unified Modeling Language (UML) is a

notation that may be used to describe
and document system architectures.
 Other informal models/sketches are also
used.
 Architectural description languages
(ADLs) have been developed but are not
widely used.
26
 Architectural Patterns

 In SE, a pattern is a general repeatable

solution to a commonly occurring
problem:
– It is a way of presenting, sharing, and reusing
knowledge about software systems.
– An architectural pattern is a stylized description of
good design practice, which has been tried and
tested in different environments.
 There are many design patterns.
27
 … architectural patterns

 Patterns should include information

about when they are and when the are
not useful.
 Patterns may be represented using
tabular and graphical descriptions (or
mixture of narrative descriptions and
diagrams).

28
 … architectural patterns
(examples)
(1) Model-View-Controller pattern.
– MVC pattern is the basis of interaction
management in many web-based systems.

29
 … The MVC pattern
Name MVC (Model-View-Controller)

Description Separates presentation and interaction from the system data. The system is
structured into three logical components that interact with each other. The
Model component manages the system data and associated operations on that
data. The View component defines and manages how the data is presented to
the user. The Controller component manages user interaction (e.g., key
presses, mouse clicks, etc.) and passes these interactions to the View and the
Model.

Example The architecture of a web-based application system organized using the MVC
pattern (next slide).
When used Used when there are multiple ways to view and interact with data. Also used
when the future requirements for interaction and presentation of data are
unknown.
Advantages Allows the data to change independently of its representation and vice versa.
Supports presentation of the same data in different ways with changes made in
one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when the data model and
interactions are simple.

30
 … MVC pattern example

31
 … Architectural patterns

(2) Layered architecture pattern

 This pattern is used to model the
interfacing of sub-systems.
 It organises the system into a set of
layers (or abstract machines) each of
which provides a set of services.

32
 … layered architecture pattern

33
 … layered architecture pattern
Name Layered architecture

Description Organizes the system into layers with related functionality

associated with each layer. A layer provides services to the layer
above it so the lowest-level layers represent core services that
are likely to be used throughout the system.
Example A layered model of a system for sharing copyright documents
held in different libraries, as shown in next slide.
When used Used when building new facilities on top of existing systems;
when the development is spread across several teams with each
team responsibility for a layer of functionality; when there is a
requirement for multi-level security.
Advantages Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the
system.
Disadvantages In practice, providing a clean separation between layers is often
difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately
below it. Performance can be a problem because of multiple
levels of interpretation of a service request as it is processed at
each layer.
34
 … layered architecture – example
(iLearn System)

35
 … architectural patterns

(3) Client-Server architecture pattern

 If a system is distributed, it may follow
the Client–Server pattern.
 This organizes a system as a set of
services and associated servers, and
clients that access and use the services.

36
 … client-server architecture

 Set of stand-alone servers which provide

specific services such as printing, data
management, etc.
 Set of clients which call on these
services.
 Network which allows clients to access
servers.
37
 …client-server arch. pattern

38
 … client-server pattern
Name Client-server

Description In a client–server architecture, the functionality of the system is

organized into services, with each service delivered from a
separate server. Clients are users of these services and access
servers to make use of them.
Example A film and video/DVD library organized as a client–server system
(previous slide, replicated below).
When used Used when data in a shared database has to be accessed from a
range of locations. Because servers can be replicated, may also be
used when the load on a system is variable.
Advantages The principal advantage of this model is that servers can be
distributed across a network. General functionality (e.g., a printing
service) can be available to all clients and does not need to be
implemented by all services.
Disadvantages Each service is a single point of failure so susceptible to denial of
service attacks or server failure. Performance may be unpredictable
because it depends on the network as well as the system. May be
management problems if servers are owned by different
39 organizations.
 …client-server arch. pattern

40
 Design of Interface &
Components

 Next lecture

41
 Interface Design

 In part 1 of this lecture, we discussed

architectural design.
 This part of the lecture introduces
interface design.
 A software interface is analogous to a set
of detailed drawings (& specifications) of
doors, windows, and external utilities of a
house.
42
 … interface design

 Interface design is the description of how

the software communicates with
systems that interoperate with it, and
with humans who use it.
 It depicts information flows into and out
of a system and how it is communicated
among the components defined as part
of the architecture.
43
 … interface design

 Pressman (p. 245) identifies 3 elements

of interface design:
– the user interface (UI),
– external interfaces to other systems,
devices, networks, or other producers
or consumers of information, and
– internal interfaces between various

44
design components.
 User interface

 User interface is a mechanism for

interaction between human beings and
the computer.
 It must be designed to facilitate good
usability – ease of use, learning,
effectiveness, and so on.

45
 … user interface design

 User interface design is guided by a

number of principles, including:
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.

(Known as Golden Rules)

46
 … interface design

Place User in Control

 Interface should enable the user to be in
control.
 The designer should:
– Define interaction modes in a way that does not
force a user into unnecessary or undesired actions.
– Provide for flexible interaction e.g. keyboard,
mouse, touch screen, commands, voice input, etc.

47
 … interface design

– Allow user interaction to be interruptible and

undoable.
– Streamline interaction as skill levels advance
and allow the interaction to be customized.
– Hide technical internals from the casual user.
– Design for direct interaction with objects that
appear on the screen (direct manipulation
e.g. drag trash to bin).

48
 … interface design

Reduce the User’s Memory Load

 UI should not tax user's memory.
 Designer should:
– Reduce demand on short-term memory
(use visual cues).
– Establish meaningful defaults.

49
 … interface design

– Define shortcuts that are intuitive (e.g. Alt-

P).
– The visual layout of the interface should be
based on a real-world metaphor.
– Disclose information in a progressive
fashion.

50
 … interface design

Make the Interface Consistent

 Some of the rules to achieve this are:
– Allow the user to put the current task into a
meaningful context.
– Maintain consistency across a complete product
line.
– If past interactive models have created user
expectations, do not make changes unless there
is a compelling reason to do so e.g. Ctrl-S, P,
51 etc.
 User interface design process

 UI design requires a good understanding

of the intended users - age, gender,
physical abilities, education, cultural or
ethnic background, motivation, goals
and personality.
 Pressman observes that UI development
process involves analysis, design,
construction and validation.
52
 … interface design

53
 … interface design

 In UI design, the goal is to define a set of

interface objects, actions and their
screen representations that enable a
user to perform all required tasks.
 This has to be in a manner that meets all
usability goals defined during analysis.

54
 … interface design steps

 Pressman (p. 332) notes that UI design

involves the following:
– Define interface objects and actions;
– Identify events (user actions) that will cause the
state of the user interface to change;
– Depict the representation of each state; and
– Indicate how the user interprets each state from
information provided through the interface.
55
 … UI design

 Definition of interface objects and

actions is accomplished by parsing user
scenarios (use cases).
 Nouns (objects) and verbs (actions) are
isolated to create a list of objects and
actions e.g. select record, view record,
edit record, register patient, generate
report, etc
56
 … UI design

 Objects and actions are categorized – to

indicate events (user actions).
 A sketch of screen layout is then created
– a number of sketches may be done.

57
 User Interface Design Patterns

 As noted earlier, a design pattern is an

abstraction that prescribes a design
solution to a specific, well-bounded
design problem.
 Many UI design patterns have been
proposed too (Pressman, Chap 16).
 Examples include CalendarStrip, Top-
Level-Navigation , Cardstack, Fill-in-blanks,
58 etc.
 Component Design

 Architectural design defines the structure

of a software system and its
components.
 This is done at a high level of
abstraction.
 Component design should be done at a
much lower level of abstraction that is
close to code.
59
 … Component Design

 A component is a modular building block

for computer software (Pressman).
 Component-level design defines the
data structures, algorithms, interface
characteristics, and communication
mechanisms for each software
component.

60
 … Component Design

 It elaborates the component specified by

architectural design – in more detail to
guide implementation.
 In OOD, attributes, operations and
interfaces are elaborated e.g. on next
slide (PrintJob).

61
62
 … Component design

 Also specified at this stage are the data

structures appropriate for each attribute
and the algorithmic detail required to
implement the processing logic
associated with each operation.
 Mechanisms required to implement all
messaging between objects (interface)
are designed. (Read Pressman, Chap 14)
63
 Component Design Patterns

 Component-level design may be guided

by design patterns too (Pressman, chap.
16).
 Some of them include HelpWizard,
SearchArea, SearchTips, etc.

One of the presentations will handle

64
some of these patterns.
 … Make or buy?

 Once design is completed, a decision

should be made whether software
should be made or bought.
 In a wide range of domains, it is now
possible to buy off-the-shelf systems
(COTS) that can be adapted and tailored
to the users’ requirements e.g. medical
records system.
65
 Implementation

 During this phase, an executable version

of the software is created.
 It involves developing programs in high-
or low-level programming languages or
tailoring and adapting generic, off-the-
shelf systems to meet the specific
requirements.

66
 … Implementation

Sommerville (p. 212-213):

 Important aspects of implementation
(good programming practices) include:
– Reuse;
– Configuration management; and
– Host-target development.

67
 (i) Reuse
 Development based on existing
components and systems.

68
 … reuse levels

 The abstraction level

– At this level, you don’t reuse software
directly but use knowledge of successful
abstractions in the design of your software.
 The object level
– At this level, you directly reuse objects from
a library rather than writing the code
yourself.
69
 … reuse levels

 The component level

– Components are collections of objects and
object classes that you reuse in application
systems.
 The system level
– At this level, you reuse entire application
systems.

70
 (ii) Configuration Management

 In software development, change

happens all the time - requirements,
models, code, etc.
 Due to this, change management is
absolutely essential.
 The general process of managing a
changing software system is called
configuration management.
71
 … Configuration management

 Version management - Keeping track of

the different versions of software
components. Many programmers may
be working on a project.
 System integration - Developers should
track versions of components that are
used to create each version of a system.

72
 … Configuration management
 Problem tracking - Support provided to
allow users to report bugs and other
problems, and to allow all developers to
see who is working on these problems
and when they are fixed.
 Release management - Planning the
functionality of new releases and
organizing the software for distribution to
73 customers.
 … Configuration management

74
 Host-target Development
 Most software is developed on one
computer (the host), but runs on a
separate machine (the target).
 More generally, we can talk about a
development platform and an execution
platform.

75
 … Host-target development
– A platform is more than just hardware.
– It includes the installed operating system
plus other supporting software such as a
database management system or, for
development platforms, an interactive
development environment.
 Development platform usually has
different installed software than
76
execution platform.
 … host-target development

77
 … host-target development

 Software engineer should consider all

aspects shown in the diagram – for the
host and the target.
 Read more Sommerville & Pressman

78
 …

 .

79
 References
 Pressman – Chap 12, 13, 14, 15
 Sommerville – Chap 6, 7.

80
 Seminar Presentation
Task 12 – 19:

(As given in last lecture)

81