software design

Published on December 2016 | Categories: Documents | Downloads: 57 | Comments: 0 | Views: 258
of 70
Download PDF   Embed   Report

Comments

Content

IT3203-Design

IT3203:Fundamentals of Software
Engineering

Software Design
Duration : 12 hours

UCSC - 2007

IT3203-Design

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.

Abstraction2
CAD software tasks:
user interaction task;
2-D drawing task;
graphics display task;

Procedural Abstraction

drawing file management task;
End.
UCSC - 2007

IT3203-Design

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

Requires Interface

PrintService
Print
GetPDfile
GetQueue
Remove
PrinterInt

Transfer
Register
Unregister

UCSC - 2007

IT3203-Design

Software Components – An Example

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

IT3203-Design

Interface evaluation cont.
Attribute
Learn ability
Speed of operation
Robustness
Recoverability
Adaptability

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.

UCSC - 2007

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close