Software Design

1
Software Design

• Deriving a solution which satisfies software
  Speficitaion

2
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.

3
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.

4
Phases in the Design Process
5
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.

6
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

7
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

8
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

9
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
10
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.

11
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.

12
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
  

13
Hierarchical Design Structure
14
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.

15
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

16
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.

17
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.

18
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.

19
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.

20
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.

21
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.

22
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.

23
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

24
Few Interfaces
25
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!

26
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.

27
Tight Coupling
28
Loose Coupling
29
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.

30
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.

31
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.

32
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.

33
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

34
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.

35
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.

36
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.

37
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.

38
Natural Language

• Nouns suggest candidate Classes.
• Not every noun is an Object Class.
• Some are attributes of another Class.
• Some are irrelevant, outside the scope of the
  application.
• Verb phrases suggest class associations
• some relationships are irrelevant (caution).
• Proper nouns suggest Objects of a Class type.
  Beware of singular nouns.

39
Class Description

• Develop a Class description, either in textual
  prose or some other structured form. E.G. using a
  customer in a Bank
• Customer a holder of one or more accounts in a
  Bank. A customer can consist of one or more
  persons or companies. A customer can make
  withdrawals deposit money transfer money
  between their accounts or to another account
  query their accounts.

40
Structured Class Description
Class Name Customer Description Personal or
company details Superclass User Name
Name Description Customers name Type String
(max. 12 chars) Cardinality 1 Name
Owns Description Details of bank accounts Type
Account Cardinality Many
41
Structured Class Description (cont..)
Public Methods Name Pay_bill Parameters
amount, date, destination,
account. Description Customer may pay bills
through the Bank.
42
Structured Class Description (cont..)
Private Methods Name Transfer Parameters
amount, from_account,
to_account. Description Allow transfers from
owned accounts to any others.