Software%20Engineering%20COMP%20201

1
Software EngineeringCOMP 201

• Design and design methodology

2
Software Design

• Deriving a solution which satisfies software
  requirements

3
Stages of Design

• Problem understanding
• Look at the problem from different angles to
  discover the design requirements.
• Identify one or more solutions
• Evaluate possible solutions and choose the most
  appropriate depending on the designer's
  experience and available resources.
• Describe solution abstractions
• Use graphical, formal or other descriptive
  notations to describe the components of the
  design.
• Repeat process for each identified abstraction
  until the design is expressed in primitive terms.

4
The Design Process

• Any design may be modelled as a directed graph
  made up of entities with attributes which
  participate in relationships.
• The system should be described at several
  different levels of abstraction.
• Design takes place in overlapping stages. It is
  artificial to separate it into distinct phases
  but some separation is usually necessary.

5
Phases in the Design Process
6
Design Phases

• Architectural design Identify sub-systems.
• Abstract specification Specify sub-systems.
• Interface design Describe sub-system interfaces.
• Component design Decompose sub-systems into
  components.
• Data structure design Design data structures to
  hold problem data.
• Algorithm design Design algorithms for problem
  functions.

7
Design

• Computer systems are not monolithic they are
  usually composed of multiple, interacting
  modules.
• Modularity has long been seen as a key to cheap,
  high quality software.
• The goal of system design is to decode
• What the modules are
• What the modules should be
• How the modules interact with one-another

8
Modular programming

• In the early days, modular programming was taken
  to mean constructing programs out of small
  pieces subroutines
• But modularity cannot bring benefits unless the
  modules are
• autonomous,
• coherent and
• robust

9
Procedural Abstraction

• The most obvious design methods involve
  functional decomposition.
• This leads to programs in which procedures
  represent distinct logical functions in a
  program.
• Examples of such functions
• Display menu
• Get user option
• This is called procedural abstraction

10
Programs as Functions

• Another view is programs as functions
• input output
  x ? f ? f (x) the program is
  viewed as a function from a set I of legal inputs
  to a set O of outputs.
• There are programming languages (ML, Miranda,
  LISP) that directly support this view of
  programming

Less well-suited to distributed, non-terminating
systems - e.g., process control
systems, operating systems like WinNT, ATM
machines
Well-suited to certain application domains
- e.g., compilers
11
Object-oriented design

• The system is viewed as a collection of
  interacting objects.
• The system state is decentralized and each
  object manages its own state.
• Objects may be instances of an object class and
  communicate by exchanging methods.

12
Five Criteria for Design Methods

• We can identify five criteria to help evaluate
  modular design methods
• Modular decomposability
• Modular composability
• Modular understandability
• Modular continuity
• Modular protection.

13
Modular Decomposability

• This criterion is met by a design method if the
  method supports the decomposition of a problem
  into smaller sub-problems, which can be solved
  independently.
• In general method will be repetitive
  sub-problems will be divided still further
• Top-down design methods fulfil this criterion
  stepwise refinement is an example of such method
  

14
Hierarchical Design Structure
15
Top-down Design

• In principle, top-down design involves starting
  at the uppermost components in the hierarchy
  and working down the hierarchy level by level.
• In practice, large systems design is never truly
  top-down. Some branches are designed before
  others. Designers reuse experience (and
  sometimes components) during the design process.

16
Modular Composability

• A method satisfies this criterion if it leads to
  the production of modules that may be freely
  combined to produce new systems.
• Composability is directly related to the issue of
  reusability
• Note that composability is often at odds with
  decomposability top-down design,
• for example, tends to produce modules that may
  not be composed in the way desired
• This is because top-down design leads to modules
  which fulfil a specific function, rather than a
  general one

17
Examples

• The Numerical Algorithm Group (NAG) libraries
  contain a wide range of routines for solving
  problems in linear algebra, differential
  equations, etc.
• The Unix shell provides a facility called a pipe,
  written ?, whereby
• the standard output of one program may be
  redirected to the standard input of another this
  convention favours composability.

18
Modular Understandability

• A design method satisfies this criterion if it
  encourages the development of modules which are
  easily understandable.
• COUNTER EXAMPLE 1. Take a thousand lines program,
  containing no procedures its just a long list
  of sequential statements. Divide it into twenty
  blocks, each fifty statements long make each
  block a method.
• COUNTER EXAMPLE 2. Go to statements.

19
Understandability

• Related to several component characteristics
• Can the component be understood on its own?
• Are meaningful names used?
• Is the design well-documented?
• Are complex algorithms used?
• Informally, high complexity means many
  relationships between different parts of the
  design.

20
Modular Continuity

• A method satisfies this criterion if it leads to
  the production of software such that a small
  change in the problem specification leads to a
  change in just one (or a small number of )
  modules.
• EXAMPLE. Some projects enforce the rule that no
  numerical or textual literal should be used in
  programs only symbolic constants should be used
• COUNTER EXAMPLE. Static arrays (as opposed to
  open arrays) make this criterion harder to
  satisfy.

21
Modular Protection

• A method satisfied this criterion if it yields
  architectures in which the effect of an abnormal
  condition at run-time only effects one (or very
  few) modules
• EXAMPLE. Validating input at source prevents
  errors from propagating throughout the program.
• COUNTER EXAMPLE. Using int types where subrange
  or short types are appropriate.

22
Five principles for Good Design

• From the discussion above, we can distil five
  principles that should be adhered to
• Linguistic modular units
• Few interfaces
• Small interfaces
• Explicit interfaces
• Information hiding.

23
Linguistic Modular Units

• A programming language (or design language)
  should support the principle of linguistic
  modular units
• Modules must correspond to linguistic units in
  the language used
• EXAMPLE. Java methods and classes
• COUNTER EXAMPLE. Subroutines in BASIC are called
  by giving a line number where execution is to
  proceed from there is no way of telling, just by
  looking at a section of code, that it is a
  subroutine.

24
Few Interfaces

• This principle states that the overall number of
  communication channels between modules should be
  as small as possible
• Every module should communicate with as few
  others as possible.
• So, in the system with n modules, there may be a
  minimum of n-1 and a maximum of links
  your system should stay closer to the minimum

25
Few Interfaces
26
Small Interfaces (Loose Coupling)

• This principle states
• If any two modules communicate, they should
  exchange as little information as possible.
• COUNTER EXAMPLE. Declaring all instance variables
  as public!

27
Coupling

• A measure of the strength of the
  inter-connections between system components.
• Loose coupling means component changes are
  unlikely to affect other components.
• Shared variables or control information exchange
  lead to tight coupling.
• Loose coupling can be achieved by state
  decentralization (as in objects) and component
  communication via parameters or message passing.

28
Tight Coupling
29
Loose Coupling
30
Coupling and Inheritance

• Object-oriented systems are loosely coupled
  because there is no shared state and objects
  communicate using message passing.
• However, an object class is coupled to its
  super-classes. Changes made to the attributes
  or operations in a super-class propagate to all
  sub-classes.

31
Reusability

• A major obstacle to the production of cheap
  quality software is the intractability of the
  reusability issue.
• Why isnt writing software more like producing
  hardware? Why do we start from scratch every
  time, coding similar problems time after time
  after time?
• Obstacles
• Economic
• Organizational
• Psychological.

32
Stepwise Refinement

• The simplest realistic design method, widely used
  in practice.
• Not appropriate for large-scale, distributed
  systems mainly applicable to the design of
  methods.
• Basic idea is
• Start with a high-level spec of what a method is
  to achieve
• Break this down into a small number of problems
  (usually no more than 10)
• For each of these problems do the same
• Repeat until the sub-problems may be solved
  immediately.

33
Explicit Interfaces

• If two modules must communicate, they must do it
  so that we can see it
• If modules A and B communicate, this must be
  obvious from the text of A or B or both.
• Why? If we change a module, we need to see what
  other modules may be affected by these changes.

34
Information Hiding

• This principle states
• All information about a module, (and particularly
  how the module does what it does) should be
  private to the module unless it is specifically
  declared otherwise.
• Thus each module should have some interface,
  which is how the world sees it anything beyond
  that interface should be hidden.
• The default Java rule
• Make everything private

35
Cohesion

• A measure of how well a component fits
  together.
• 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 localized in a single cohesive component.
• Various levels of cohesion have been identified.

36
Cohesion Levels

• Coincidental cohesion (weak)
• Parts of a component are simply bundled together.
• Logical association (weak)
• Components which perform similar functions are
  grouped.
• Temporal cohesion (weak)
• Components which are activated at the same time
  are grouped.

37
Cohesion Levels

• Communicational cohesion (medium)
• All the elements of a component operate on the
  same input or produce the same output.
• Sequential cohesion (medium)
• The output for one part of a component is the
  input to another part.
• Functional cohesion (strong)
• Each part of a component is necessary for the
  execution of a single function.
• Object cohesion (strong)
• Each operation provides functionality which
  allows object attributes to be modified or
  inspected.

38
Cohesion as a Design Attribute

• Not well-defined. Often difficult to classify
  cohesion.
• Inheriting attributes from super-classes weakens
  cohesion.
• To understand a component, the super-classes as
  well as the component class must be examined.
• Object class browsers assist with this process.