Instructional Objectives
• Describe the important software design issues and concepts
• Compare different approaches to software design
• Apply suitable design approaches for a problem
UCSC - 2007
IT3203-Design
Detailed Syllabus
4.1. Design concepts
4.1.1. Abstraction
4.1.2. Architecture
4.1.3. Patterns
4.1.4. Modularity
4.1.4.1. Cohesion
4.1.4.2. Coupling
4.1.5. Information hiding
4.1.6. Functional independence
4.1.7. Refinement
4.2. Architectural design
4.2.1. Repository model
4.2.2. Client-server model
4.2.3. Layered model
4.2.4. Modular decomposition
4.3. Procedural design using structured methods
4.4. User Interface design
4.4.1. Human-computer interaction
4.4.2. Information presentation
4.4.3. Interface evaluation
4.5. Design notations
UCSC - 2007
IT3203-Design
Design activities
h Identification of the sub-systems
h Identification of the software components
h Identification of the software architecture
h Data design
h Interface design
h Algorithm design
h Data structure design
h Design specification
UCSC - 2007
IT3203-Design
4.1. Design concepts
UCSC - 2007
IT3203-Design
Software Design – Why it is important?
A good design
• is the key for a successful software system.
• allows easy maintenance of a system.
• allows to achieve non-functional requirements such
as reliability, performance, reusability, portability.
• facilitates the development and management
processes of a software project.
UCSC - 2007
IT3203-Design
Abstraction
hThis is an intellectual tool (a psychological notion) which
permits one to concentrate on a problem at some level of
generalization without regard to irrelevant low level details
h Abstraction allows us to proceed with the development
work without been held up in low-level implementation
details (yet to be discovered)
UCSC - 2007
IT3203-Design
Abstraction
An Example : Develop software that will perform 2-D drafting (CAD)
Abstraction 1
h Software will include a computer graphics interface which will enable the
draftsperson to see a drawing and to communicate with it via a mouse. All line
and curve drawing, geometric computations. Will be performed by the CAD
software. Drawing will be stored in a drawings file.
Abstraction Cont..
hData Abstraction = defining a data object at different levels.
heg: Drawing
Abstraction 1 -
Another data
abstraction
drawing
Abstraction 2 TYPE drawing
number IS STRING LENGTH(12)
geometry DEFINED
notes IS STRING LENGTH(256)
END drawing ;
UCSC - 2007
IT3203-Design
• Software Architecture
– overall structure of the software components and the ways in
which that structure provides conceptual integrity for a
system.
• Design Patterns
– When reusing software components, the developer is
constrained by the design decisions that have been made by
the implementers of these components.
– If the design decisions of the reusable components conflicts
whit the current requirements the reusability will be
impossible or the developed system will become inefficient.
– One way to solve the problem is to reuse more abstract
designs that do not include implementation details
UCSC - 2007
IT3203-Design
Modularity
• Software is divided into separately named, addressable components
called modules.
• Complexity of a program depends on modularity
• Let C(x) = a measure of complexity and P1 and P2 be problems,
E(x) = a measure of effort to solve
* If C(P1) > C(P2) then
* E(P1) > E(P2)
* Also, C(P1+P2) > C(P1) + C(P2)
* Therefore, E(P1+P2) > E(P1) + E(P2)
UCSC - 2007
IT3203-Design
Modularity ctd..
Modularity facilitates
• the development process
• the maintenance process
• the project management process
• reusability
UCSC - 2007
IT3203-Design
How many modules?
Cost of effort
Interface cost
Cost per
module
No. of modules
UCSC - 2007
IT3203-Design
Module Coupling
• A measure of the strength of the interconnections between
system components.
• Loose coupling means component changes are likely to affect
other components.
• Shared variables or control information exchange lead to tight
coupling.
• Loose coupling can be achieved by component communication
via parameters or message passing.
UCSC - 2007
IT3203-Design
Levels of Coupling
• Data Coupling
Data is passed from one module to another using arguments
Stamp Coupling
More data than necessary is passed via arguments. Eg. Pass
the whole record instead of just the field being changed.
Control Coupling
A flag is passed from one module to another affecting the
functionality of the second module
• External Coupling
Coupling with the environment (eg. Data files, other programs
etc.).
UCSC - 2007
IT3203-Design
Levels of Coupling (Cont..)
• Common Coupling
Occurs when modules access the same global data.(Eg.
COMMON in FORTRAN and DATA DIVISION in COBOL)
MODULE- A
MODULE- B
MODULE- C
MODULE -D
UCSC - 2007
IT3203-Design
Levels of Coupling (Cont..)
•
Content Coupling
One module directly affects the working of another. Calling
module can modify the called module or refer to an internally
defined data element.
A
Content
Global
Data
area
C
B
Common
Coupling
D
E
UCSC - 2007
Coupling
IT3203-Design
Levels of Coupling (Contd..)
Object oriented systems are loosely coupled. No shared state and
objects communicate using message passing, but
• Object Coupling
Occurs when an object class inherits attributes and
methods of another class. Changes to super-class propagate
to all sub-classes.
Student
PG Student
UG Student
UCSC - 2007
IT3203-Design
Coupling should be minimised.
Loosely coupled modules facilitate:
• Maintenance
• Development
• Reusability
UCSC - 2007
IT3203-Design
Module Cohesion
• Interaction within a module. A measure of how well a
component fits together.
• High cohesion – A component should implement a single
logical entity or function
• Cohesion is a desirable design component attribute as when a
change has to be made, it is localised in a single component.
UCSC - 2007
IT3203-Design
Levels of Cohesion
• Object Cohesion - Occurs when a single entity is represented
by the object and all operations on the object, and no others are
included within it. This is the strongest type of cohesion and
should be aimed by the designer.
• Functional Cohesion – Occurs when all the elements of the
module combine to complete one specific function. This also
strong cohesion and should be recommended.
• Sequential Cohesion – Occurs when the activities (more than
one purpose to the function) combine such that the output of one
activity is the input to the next. Not as good as functional
cohesion but still acceptable.
UCSC - 2007
IT3203-Design
Levels of Cohesion (Cont..)
• Communicational Cohesion – Occurs when a module performs
a number of activities on the same input or output data.For
example customer maintenance functions add,delete, update and
query are related through communication because they all use
user the customer file.
• Procedural Cohesion – Occurs when a modules internal
activities bear little relationship to one another but control flows
one to another in sequence.
• Temporal Cohesion - Occurs when functionality is grouped
simply because it occurs at the same time. For example house
keeping tasks at the start and ednd of an application.
UCSC - 2007
IT3203-Design
Levels of Cohesion (Cont..)
• Logical Cohesion – Occurs when functionality is grouped by
type. For example all creates together, all updates together etc.
This should be avoided at all cost.
• Coincidental Cohesion - Occurs when functionality is
grouped randomly. Not even to be considered as an option in
design.
UCSC - 2007
IT3203-Design
Cohesion Examples
Compute average
daily temperatures at
various sites
Initialise sums
And open files
Create new
temperature
record
Store
Temperature
record
Read in site, time
and temperature
Edit site, time or
temperature filed
UCSC - 2007
Store record for
specific site
Close files and
print average
temperatures
IT3203-Design
Information Hiding
The principle of Information Hiding suggests that modules be
characterized by design decisions that (each) hides from all others.
In other words modules should be specified and designed so that
information (procedure and data) contained within a module is
directly inaccessible to other modules.
However the modules should communicates using well defined
interfaces. Protecting information from direct access by other
modules and providing access to this information through well
defined interfaces is called Encapsulation.
Because most data and procedure are hidden from other parts of the
software, inadvertent errors introduced during modification are less
likely to propagate to other locations within the software.
UCSC - 2007
IT3203-Design
Encapsulation
Encapsulation is a technique for minimizing
interdependencies among separately written modules by
defining strict external interfaces. The external interface
acts as a contract between a module and its clients. If
clients only depend on the interface, modules can be reimplemented without affecting the client. Thus the
effects of changes can be confined.
UCSC - 2007
IT3203-Design
• Functional Independence
– Achieved by developing modules with single-minded
purpose and an aversion to excessive interaction with
other models
• Refinement
– process of elaboration where the designer provides
successively more detail for each design component
UCSC - 2007
IT3203-Design
Design with reuse
Another important design consideration is reusability of software
components. Designing reusable software components is
extremely valuable. Some benefits of software reuse are
•
Increased reliability
• Reduced process risks
• Effective use of specialists
• Standards compliance
• Accelerated Development
UCSC - 2007
IT3203-Design
4.2. Architectural design
UCSC - 2007
IT3203-Design
Software Architectural Design
The architectural design process is concerned with establishing a
basic structured framework for a system. It involves identifying the
major components of the system and the communications between
these components.
Large systems are always decomposed into subsystems that provide
some related set of services. The initial design process of
identifying these sub-systems and establishing a framework for subsystem control and communication is called architectural design
and the output of this design process is a description of the software
architecture.
UCSC - 2007
IT3203-Design
Sub-Systems and Components
Sub- Systems - A Sub-system is a system in its own right
whose operations are not depend on the services proved by the
other sub-systems. Sub systems are composed of modules
(components) and have defined interfaces which are used for
communication with other sub-systems,.
Components – A component (module) is normally a system
component that provides one or more services to other modules.
It makes use of services provided by other modules. It is not
normally considered as an independent system. Modules are
usually composed from a number of other, simpler system
components.
UCSC - 2007
IT3203-Design
Software components
- An Example
`
Provides Interface
GetPDfile – A service to retrieve the printer description file for
a printer type
PrinterInt – A service that transfers commands to a specified
printer.
Print – A service to print a document
GetQueue – Discover the state of a print queue
Remove – Remove a job from the queue
Transfer – Transfer a job to another queue
Register - Register a printer with the printing service
component
Unregister – unregister a printer
UCSC - 2007
IT3203-Design
Architectural Design Process
• System structuring - The system is structured into a number
of principal sub-systems where a sub-system is an independent
software unit. Communications between sub-systems are
identified.
• Control modelling – A general model of the control
relationships between the parts of the systems is established.
• Modular decomposition - Each identified sub-system is
decomposed into modules. The architect must decide on the
types of module and their interconnections.
UCSC - 2007
IT3203-Design
Architectural Design – An example
Vision
System
Object
identification
system
Arm controller
Packaging
selection
system
Packing
system
UCSC - 2007
Gripper controller
Conveyor
controller
IT3203-Design
Repository Model
Sub-systems making a up a system must exchange information
so that they can work together effectively. One approach is to
keep all shared data in a central database that can be accessed by
all sub-systems. A system model based on a shared database is
called repository model.
This model is suited to applications where data is generated by
one sub-system and used by another. Examples of this type of
systems include command and control systems, management
information systems CAD systems and CASE tools.
UCSC - 2007
IT3203-Design
Repository Model - An example
The architecture of an integrated CASE tool.
Design
editor
Design
translator
Code
generator
Project repository
Design
analyser
Report
generator
UCSC - 2007
Program
editor
IT3203-Design
Some advantages of Repository Model
• It is efficient way to share large amount of data. There os no need
to transmit data explicitly from one sub-system to another.
• Activities such as backup recovery, access control and recovery
from error are centralised. They are the responsibility of the
repository manager. Tools can focus on their principal function
rather than be concerned with these issue.
• The model of sharing is visible through the repository schema. It
is straight forward to integrate new tools given that they are
compatible with the agreed data model.
UCSC - 2007
IT3203-Design
Some disadvantages of Repository model
• Sub-systems must agree on a repository data model. Inevitably,
this is a compromise between the specific needs of each tool.
Performance may be adversely affected by this compromise. It may
be difficult or impossible to integrate new sub-systems if their data
models do not fit the agreed schema.
• Evolution may be difficult as a large volume of information is
generated according to an agreed data model. Translating this to a
new model will certainly be expensive.
• Different sub-systems may have different requirements for
security, recovery and backup policies. The repository model forces
the same policy on all sub-systems.
UCSC - 2007
IT3203-Design
The client-server model
The client-server architectural model is a distributed system model
which shows how data and processing are distributed across a
range of processors. The major components of the model are:
1. A set of stand-alone servers which offer services to other subsystems. Examples of servers are print servers, web servers and
data base servers.
2.
A set of clients that call on the services offered by the servers.
Theses are normally sub-systems in their own right. There may be
several instances of a client program executing concurrently.
3.
A network which allows the clients to access these services.
UCSC - 2007
IT3203-Design
Client- Server model - An example
Client 1
Client 2
Client 3
Client 4
Wide-bandwidth network
Catelogue
server
Catelogue
Video
server
File-clip
files
Picture
server
Digitised
photographs
UCSC - 2007
Hypertext
server
Hypertext
IT3203-Design
Client-Server model – Example
The above system is multi-user hypertext system to provide a
film and photograph library. In this system, there are several
severs which manage and display the different type of media.
Video frames need to be transmitted quickly and in synchrony
but at relatively low resolution. They may be compressed in a
store. Still pictures, however, must be sent at a high resolution.
The catelogue must be able to deal with a variety of queries and
provide links into the hypertext information systems. The client
program is simply an integrated user interface of these services.
UCSC - 2007
IT3203-Design
Layered Model
• The layered model organizes the system in to layers by modeling
the interfacing of sub systems.
• Each layer provides a set of services.
• This model is also called abstract machine model.
• Each layer defines an abstract machine language is used to
implement the next level of abstract machine.
UCSC - 2007
IT3203-Design
Layered model of a version management system
Configuration management layer
Object management system layer
Database system layer
Operating system layer
UCSC - 2007
IT3203-Design
• An example for layered model is OSI reference model
for network protocols.
• This model support the incremental development of
systems because some of the services provided by the
layer is made available to users while the layer is being
developing.
UCSC - 2007
IT3203-Design
Modular Decomposition
• After a structural architecture has been designed,
the next stage of architectural design process is the
decomposition of sub-system in to modules.
• There is not a rigid distinction between system
decomposition and modular decomposition.
UCSC - 2007
IT3203-Design
We consider two modules which may be used when
decomposing a sub-system into modules.
1. An object oriented model: The system
decomposed into a set of communicating
objects.
2. A data flow model: The system decomposed into
functional modules which accept input data and
transform it, in some way, to output data. This is
also called a pipeline approach.
UCSC - 2007
IT3203-Design
4.3. Procedural design using structured
methods
UCSC - 2007
IT3203-Design
• For the component-level design for conventional
software components has proposed a set of constrained
logical constructs from which any program could be
formed.
• Each construct had a predictable logical structure.
• Structured programming is a design technique that
constraints logic flow to three constructs that are
sequence, construct and repetition.
UCSC - 2007
IT3203-Design
• The structured constructs reduces program complexity
and enhances readability, testability and
maintainability.
• These allow reader to recognize procedural elements
of a module rather than reading the design or code line
by line.
UCSC - 2007
IT3203-Design
4.4. User Interface design
UCSC - 2007
IT3203-Design
User Interface Design
Good user interface design is critical to the success of a system. An
interface that is difficult to use will, at best, result in a high level of
user errors. At worst, user users will simply refuse to use the
software system irrespective of its functionality.
If information is presented in a confusing or misleading way, users
may misunderstand the meaning of information. They may initiate
a sequence of actions that corrupt data or even cause catastrophic
system failure.
The system should assist the user providing help facilities and
should guide the user in the case of occurrence of an error.
UCSC - 2007
IT3203-Design
Graphical User Interfaces
Although text based interfaces are still widely used, especially
in legacy systems, computer users now expect application
systems to have some form of graphical user interface.
The advantages of GUI are:
1. They are relatively easy to learn and use. Users with no
computing experience can learn to use the interface after a
brief training session.
2.
The users have multiple screens (windows) for system
interaction. Switching from one task to another is possible
without losing sight of information generated during the first
task.
3. Fast, full-screen interaction is possible with immediate access
to anywhere on the screen.
UCSC - 2007
IT3203-Design
The characteristics of a graphical user interface
Windows - Multiple windows allow different information to be
displayed simultaneously on the user’s screen
Icons - Icons represent different types of information. On some
system icons represents files, on others, icon represents processes.
Menus - Commands are selected from a menu rather than typed in
a command language.
Pointing – A pointing device such as a mouse is used for selecting
choices from a menu or indicating items of interest in a window.
Graphics - Graphical elements can be mixed with text on the same
display.
UCSC - 2007
IT3203-Design
The user interface design process
Analyse and
understand
user activities
Produce perBased design
prototype
Evaluate design
With end-users
Design
Prototype
UCSC - 2007
Produce
dynamic
Design
prototype
Evaluate design
With end-users
Executable
prototype
Implement
Final user
interface
IT3203-Design
User interface design principles
User familiarity - The interface should use terms and concepts
which are drawn from the experience of the people who will make
most use of the system.
Consistency – The interface should be consistent in that, wherever
possible, comparable operations should be activated in the same
way.
Recoverability – The interface should include mechanisms to allow
users to recover from errors.
User guidance – The interface should provide meaningful feedback
when errors occur and provide context-sensitive user help facilities.
User diversity – The interface should provide appropriate
interaction facilities for different type of system user.
UCSC - 2007
IT3203-Design
Colour in interface design
Some guidelines for effective use of colour in user interfaces.
1.
You should not use more than four or five separate colours in a window and
no more than seven in a system interface. Colours should be used selectively
and consistently.
2.
Use colour change to show a change in system status.If the display changes
colour, this should mean that a significant event has occurred.
3.
Use colour coding to support the task which users are trying to perform. If
they have to identify anomalous instances, highlight these instances. .
4.
Be careful about colour pairing. Some colour combinations are not good for
the eye. (eg. Red and Blue)
5.
Use colour coding in a useful and consistent way.
If one part of a system
displays error messages in red, then red should not be used for anything else.
UCSC - 2007
IT3203-Design
Human computer Interaction
• This can be seen when a user enter data into a computer
system.
• There are number of approaches that enhance user
interaction.
• Direct interaction - Involve a pointing device. User
interact directly with objects on the screen. Eg: To delete a
file, user may drag it directly to the trash can using mouse.
UCSC - 2007
IT3203-Design
• Menu selection – User has to select an option from a list of
possibilities. It is often the case that another screen object is
selected at the same time and command operates on that
object. In this approach to delete a file, user select the file
menu and then select the delete command from the list.
• Form fill – User fills a form that includes fields and buttons.
Some fields have associated menus. Buttons initiate some
actions on press.
• Command language – User give necessary commands and
parameters to instruct the computer to perform a specific
activity. Eg: To delete a file, user issues delete command with
the file name as a parameter.
UCSC - 2007
IT3203-Design
• Natural language – User issues commands in natural
language. To delete a file, user may type ”Delete file
name xxx”.
• The above styles can be mixed in an application.
UCSC - 2007
IT3203-Design
Advantages and disadvantages of interaction styles
Interaction
style
Main advantage Main disadvantage
Application
example
Direct
manipulation
Fast and intuitive
interaction. Easy to
learn.
May be hard to
implement. Only
suitable where there is
a visual metaphor for
tasks and objects.
-Video games
and CAD system
Menu selection
Avoid user error.
Required little
typing.
Show for experienced
-Most general
user. Can be complex if purpose systems
many menu options.
Form fill-in
Simple data entry.
Easy to learn.
Takes up lot of screen
space
UCSC - 2007
-Stock control
-Personal loan
processing
IT3203-Design
Interaction
style
Main advantage
Main disadvantage Application
example
Command
language
Powerful and
flexible
Hard to learn
Poor error
management
Natural language
Accessible to casual
users
Easily expanded
Requiring more typing
Natural language
understanding systems
are unreliable
UCSC - 2007
-Operating
systems
-Library
information
retrieval systems.
-Time table
systems
-www
information
retrieval systems
IT3203-Design
Information Presentation
• All interactive systems have to provide some way of presenting
information to users.
• The information presentation may simply be a direct representation
of the input information or it may present the information
graphically.
• It is a good system design practice to keep software required for
information presentation separate from the information itself.
• To some extend, this contradicts object-oriented philosophy which
suggest that operation on data should be defined with the data
itself.
UCSC - 2007
IT3203-Design
Information Presentation cont.
Information to
be
displayed
Presentation
software
Display
The MVC approach first made widely available in smalltalk is an
effective way to support multiple presentation of data. Users can
interact with each presentation using a style that appropriate to it.
The MVC model of user interaction
View state
View modification messages
View methods
Model queries
and updates
Controller state
User inputs
Controller methods
Model state
Model methods
UCSC - 2007
Model edits
IT3203-Design
Interface evaluation
• Interface evaluation is the process of accessing the
usability of an interface and checking that it meets
user requirements.
• Systematic evaluation of a user interface design
can be as expensive process involving cognitive
scientist and graphics designers.
• An evaluation should be conducted against a
usability specification based on usability attributes
as shown below.
UCSC - 2007
Description
How long does it take a new user to
become productive with the system?
How well does the system response
to match the user’s work practices?
How tolerant is the system of user
error?
How good is the system at
recovering from user errors?
How closely is the system tied to a
single middle of work?
UCSC - 2007
IT3203-Design
Design Notations
Graphical design notation
• The activity diagram allows a designer to
represent all elements of structured
programming.
• Activity diagram is the descendent of flowchart.
Flow chart is simple pictorially.
Repetition
Sequence
Selection
UCSC - 2007
IT3203-Design
Tabular design notation
• Decision tables provides a notation to translate
actions and conditions into a tabular form.
• Following steps are applied to develop a decision
table.
1. List all actions that can be associated with a
specific procedure.
2. List all conditions during execution of the
procedure.
3. Associate specific sets of conditions with
specific actions, eliminating impossible
combinations of conditions.
UCSC - 2007
IT3203-Design
• Define rules by indicating what action(s)
occurs for a set of conditions.
Conditions
1
2
T T
Regular customer
Silver customer
3
4
T
T
Gold customer
F
Special discount
Actions
No discount
Apply 8% discount
Apply 15% discount
Apply additional x% discount
Resultant Decision Table
UCSC - 2007
T F
5
6
T T
T F T
IT3203-Design
Program design language
• This is also known as structured English or pscudocode.
• This uses vocabulary of one language (English) and
overall syntax (structured programming language) of
another.
• PDL actually is not a programming language due to the
use of narrative text.
• There are tools that can translate PDL into programming
language.
Program design language has been found as the best design notation.