Lecture 6: Software Design (Part I)

1
Lecture 6 Software Design (Part I)

• Dr Valentina Plekhanova
• University of Sunderland, UK

http//www.cet.sunderland.ac.uk/cs0vpl/SE-Com185.
htm
2
Design Process Definition

• The next step after requirements analysis and
  specification is software design.
• Design is the creative process of transforming
  the problem into a solution the description of a
  solution is also called design. Pfleeger, 1998
  
• Design is a process of constructing preliminary
  models for producing an expected
  product/software/program.
• Design process defines several models of the
  systems at different levels of abstraction.

3
Principles of Software Design Abstraction and
Decomposition

• Abstraction is an expression that shows the most
  important information of the program without
  telling its implementation details.
• Decomposition is a way to divide a big task into
  small tasks, and to develop details of an
  abstraction. The benefit of decomposition is to
  reduce the complexity of programs.

4
Principles of Software Design Decomposition and
Modularity

• Every design method involves some kind of
  decomposition starting with a high level
  depiction of the systems key elements and
  creating lower level looks at how the systems
  features and functions will fit together
  Pfleeger, 1998.
• Modularity is a property that a program consists
  of many independent modules. A module is a
  modest-sized component that performs
  independently specific functions.

5
Principles of Software Design Encapsulation
Information Hiding

• Encapsulation is the grouping of related ideas
  into one unit, which can thereafter be referred
  to by a single name.
• Information hiding is the use of encapsulation to
  restrict from external visibility certain
  information or implementation decisions that are
  internal to the encapsulation structure.

6
Design Levels Design Methods

• Design -gt Abstract Design Detailed Design
• Abstract Design different methods can be used,
  e.g. top down design, modular design, structured
  design, etc.
• Detailed Design, e.g. high level design, low
  level design.

7
Conceptual Design Technical Design

• This stage is concerned with planning how to
  build the software itself.
• Conceptual design tells the customer exactly what
  the system will do (i.e. What? conceptual
  design concentrates on the systems functions).
• Technical design allows system builders to
  understand the actual hardware and software
  needed to solve the customers problem (i.e. How?
  technical design describes the form the system
  will take) Pfleeger, 1998

8
Architecture

• Architecture associates the system capabilities
  identified in the requirements specification with
  the system components that will implement them.
• Components are usually modules, and the
  architecture also describes the interconnections
  among them.

9
Cohesion

• Cohesion is an internal property of a module -
  level of relationships between elements of the
  module.
• We say that a module has high cohesion if all of
  its elements (e.g. procedures, statements) are
  related strongly in a logical way.
• They cooperate to achieve a common goal, which is
  the function of the module.

10
Coupling

• Coupling characterises interrelationship among
  modules in a software, i.e. represents a modules
  relationship to other modules.
• With low coupling we can analyse, modify, test,
  and reuse modules separately.

11
Cohesion and Coupling

• Cohesion and Coupling are used for measurement of
  independence of elements/modules in a design,
  i.e. assessment of design quality Yourdon and
  Constantine, 1978
• The goal of software engineer is to design the
  modules with high cohesion and low coupling.

12
Design Methods

• Top down design
• Bottom up design
• Modular design
• Structured design
• Object oriented design

13
Top-down Design

• Top-down design supports the abstract and
  decomposition principle.
• By this design method, a system is first
  abstracted as a high level unit (e.g. module,
  process, procedure, function), and then
  decomposed into low level units, possibly
  integrated together using some constructs.

14
Top-down Software Design

• We begin by considering the problem to be
  computerised as a whole and identify its major
  components.
• For each component we then do the same identify
  what its major sub-components are
• Each of the sub-components can then be broken
  down into its sub-components and so on, until we
  reach a level whereby the individual pieces can
  be understood and designed without any difficulty.

15
Top-down Design

• This process of top-down design (also called
  stepwise refinement) is a way to manage
  complexity.
• We are able to create user-defined functions and
  general procedures to carry out subtasks.

16
Top-down Design Reasons for Use

• Systemic way of breaking a large system/problem
  into the smaller manageable parts.
• Easier to understand the system/problem.
• Easier to test these smaller parts.

17
Top-down Design An Example
18
Object-Oriented Design

• Object-oriented design is a way of designing a
  program system by focusing on the design of
  objects and their integration.
• An object is an encapsulation of attributes and
  operations (or methods) it takes inputs and
  performs some functions. In fact, an object is a
  kind of module.
• An object-oriented program can be regarded as a
  network of objects that interact with each other
  by means of sending and receiving messages (which
  are similar to calling methods in Java).

19
Design Levels

• High Level Design
• Low Level Design

20
High-level Design

• One way to represent high-level design is to use
  a hierarchical structure chart where each box on
  the chart represents a component or subtask of
  the program.
• A high-level algorithm may be presented either in
  pseudocode or with structure charts, and it
  should be language independent.

21
High Level Design Structure Chart
22
High Level Design

• High level design documents such as structure
  charts show
• the overall system design
• how the program is decomposed into separate
  modules
• which modules call which other ones
• how they communicate via data

23
High Level Design

• they do not show
• the order in which the modules are called
• the number of times they are called if its more
  than once
• the condition(s) determining optional/conditional
  invocation
• the internal workings of the modules

24
High-level Design

• High-level program design involves the
  identification of components of our program -
  task, subtasks and decisions about how
  information flows between them.
• We need to make decisions about the type of data
  to be used, names for variables and where to
  declare them (local, form-level, module or global
  variables), and what type of data structures and
  external data storage requirements are required.

25
High-level Design

• At the end of high-level design we will have
  decided the forms, objects, procedures and
  functions needed and where code needs to be added
  to carry out the work of the program.
• All of these decisions may take several passes
  through the design process, each time round,
  adding more detail.
• It is a process of spiralling down from the
  requirement level to the code level - though at
  this stage we do not have to worry about the
  details of the low-level code for the procedures
  and functions.

26
High-level Design Representation

• We can represent out high-level design decisions
  by the use of a structure chart which act as a
  'picture' of all the software 'parts' making up
  the program.
• Additional information can be placed on a
  structure chart to show the flow of data between
  the different parts.

27
High-level Design An Example
Project (a,b,e,r, z, x,)
e,r
a,b
Task 1 (a,b,c,d)
Task 2 (e,r,t,y,p)
t,y,p
c,d
Subtask 2.1 (t,y,p,w)
Subtask 1.1
Function 2.1.A
w
28
Week 8 24.04.2003-28.04.2003Project Control
Session

• Tutorial Time 10 minutes for each Team
• Students will present project file, particularly
  Schedule, plus any project documentation.
• Students will describe where they are in the
  project and any problems encountered.
• During the discussion reviewers will ask to see
  evidence of deliverables for any tasks that are
  complete to determine whether they have in fact
  been done.