Design Phase

1
Design Phase

• Whats design?
• the process of applying various techniques and
  principles for the purpose of defining a device,
  a process, or a system in sufficient detail to
  permit its physical realization
• Design Issues Modularity (Refinement,
  Abstraction)
• Design Model Classical vs. Object-Oriented Model
• Design Process Classical vs. Object-Oriented
  Model
• Software Engineering a Practitioners Approach
  (chap 13, 14, 21) Pressman, 1997

2
Design Principles

• not suffer from tunnel vision
• be traceable to the analysis model
• not reinvent the wheel
• minimize the intellectual distance between
  software and the problems in the real world.
• exhibit uniformity and integration

3
Design Issues

• Whats design quality? Are there uniform criteria
  that define the technical quality of a software
  design?
• What criteria can be used to partition software
  into individual components?
• How is function or data structure detail
  separated from a conceptual representation of the
  software?

4
Design Quality

• Implement all of the explicit requirements
  contained in the analysis model
• A readable, understandable guide for developers
• Provide a complete picture of the software

• Makes intelligent use of control among elements
  of software
• Contain both data and procedural abstractions
• Lead to interfaces to reduce complexity

5
Modularity (Abstraction Refinement)

• Each step in the software engineering process is
  a refinement in the level of abstraction of the
  software solution.
• Refinement causes the designer to elaborate on
  the solution statement, providing more and more
  detail as each successive refinement occurs.
• Software is divided into separately named and
  addressable components that are integrated to
  satisfy problem requirements.

6
How to define Module?Meyer, 88

• Decomposability decompose a large problem into
  subproblems
• Composability enables existing design components
  to be assembled into a new system
• Understandability
• Continuity Protection make small change and
  reduce the propagation of side effects of an
  error.

7
Effective Modular Design

• Functional independence a direct outgrowth of
  modularity and the concepts of abstraction and
  information hiding
• Cohesion a measure of the relative functional
  strength of a module.
• Coupling a measure of the relative
  interdependence among modules

8
Design Heuristics for Effective Modularity

• Evaluate the first iteration of the program
  structure to reduce coupling and improve
  cohesion.
• Keep scope of effect of a module within the scope
  of control of that module

• Evaluate module interfaces to reduce complexity
  and redundancy and improve consistency
• Define modules whose function is predictable, but
  not overly restrictive.

9
Software Architecture

• The architecture of a software system
• defines the system in terms of components and
  interactions among components
• shows correspondence between requirements and
  elements of the constructed system
• addresses system-level properties (scale,
  capacity, throughput, consistency, compatibility)
• An architectural definition identifies
• components define the locus of computation
• e.g., filters, database, objects, clients,
  servers
• connectors mediate interactions of components
• e.g., procedure call, pipes, event broadcast
• properties specify info for construction
  analysis
• e.g., signatures, pre/post conditions

10
Control Hierarchy (View)

• A module controls another module or is controlled
  by (superordinate vs. subordinate)
• Visibility components are invoked or used as
  data by a given component (directly or
  indirectly)
• Connectivity set of components are directly
  invoked or used as data by a given component.

11
Structural Partitioning

• Horizontal partitioning separate branches of the
  modular hierarchy for each major program function
  (input/computation/output)
• Vertical partitioning control and work should be
  distributed top-down (controller-at-top,
  worker-at-bottom)
• Benefitseasier to test and maintain, fewer side
  effects, easier to extend

12
Data Structure

• A representation of the logical relationship
  among individual elements
• organization
• methods of access
• degree of associativity
• processing alternatives for information

13
Classical Design Model

• Data design transform the information domain
  model created during analysis into the data
  structure
• Architectural design define the relationship
  among major structural elements of the program.
• Interface design describe how the software
  communicates within itself, to systems that
  interoperate with it, and with humans who use it.
• Procedural design transforms structural elements
  of the program architecture into a procedural
  description of software components.

14
Object-Oriented Design Model

• The subsystem layer a representation of each of
  the subsystems to achieve its customer defined
  requirements and to implement the technical
  infrastructure that supports customer
  requirements.
• The class and object layer the class hierarchies
  that enable the system to be created using
  generalizations and increasingly more targeted
  specializations design representations of each
  object.
• The message layer the details that enable each
  object to communicate with its collaborators (the
  external and internal interfaces).
• The responsibility layer the data structure and
  algorithmic design for all attributes and
  operations for each other.

15
Object-Oriented Design Model

• Whats Subsystem?
• A subset of all classes collaborate among
  themselves to accomplish a set of cohesive
  responsibilities. Wirfs-Brock et al, 1990.

16
Classical Design Process (Data Design)

• Identify all data structures and the operations
  to be performed on each.
• Establish a data dictionary (data library) to be
  used both data and program design
• Defer low-level data design decisions.
• A software design and programming language should
  support the specification and realization of
  abstract data type.

17
Classical Design Process (Architecture Design)

• Data flow-oriented design
• Information flow type/ boundary are established
• The DFD is mapped into program structure
• Mapping individual transforms of a DFD into
  appropriate modules within the program structure.
• Control hierarchy is defined by factoring (a
  top-down distribution of controls)
• The resultant structure is refined using design
  measures and heuristics

18
Classical Design Process (Data flow-oriented
design)

• Figure 12.3 Data flow diagram
• Figure 12.4 12.5 Structure charts
• Figure 12.6 Detailed design
• Figure 12.7 PDL (pseudocode) representation
• Figure 12.8 Data flow diagram with multiple input
  output streams
• to find the point of highest abstraction of
  input/output for each input/output stream
• use these points to decompose the given data flow
  diagram into modules with fewer input/output
  streams. Continue in this way until each module
  has high cohesion.

19
Classical Design Process (Interface Design)

• The design of interface b/w software modules
• The design of interface b/w the software and
  other external entities
• The design of the interface b/w a human and a
  computer
• User model novices, knowledgeable, intermittent
  users, knowledgeable, frequent users
• General interaction, Information display, Data
  input

20
Classical Design Process (Procedural Design)

• Structured programming
• Graphical design notation
• Program description language (PDL)

21
Classical Design Process (Post Processing)

• Processing narrative must be developed for each
  module
• An interface description is provided for each
  module
• Local and global data structures are defined
• All design restrictions/limitations are noted.
• A design review is conducted Optimization (time,
  space, etc) is considered.

22
Object-Oriented Design Process (Partitioning OOA)

• The classes within a subsystem should collaborate
  only with other classes within the subsystem.
• The number of subsystems should be kept small.
• Subsystems can be partitioned internally to help
  reduce complexity.
• A well-defined interface through which all
  communication with the rest of the system occurs.

23
OO Design Process (Process Task Management)

• Allocate each subsystem to an independent
  processor
• Allocate the subsystems to the same processor and
  provide concurrency support through operating
  system features
• The characteristics of the task, coordinator task
  and associated objects are defined
• The coordinator and other tasks are integrated
  (task name, description, priority, services,
  coordinates by, communicates via)

24
OO Design Process (UML)

• Construct interaction diagrams
• Figure 12.12 Sequential diagram emphasize the
  explicit chronological sequence of message,
  useful in situations where the order in which
  event occur is important.
• Figure 12.13 Collaboration diagram emphasize the
  relationship between objects and are a powerful
  tool for understanding the structure of the
  software product.

25
OO Design Process (UML)

• Construct the detailed class diagram
• Figure 12.14 Detailed Class Diagram determine
  which actions (method) should be associated with
  each class or client that sends a message to an
  object of that class (responsibility-driven
  design), information hiding, inheritance
• Design the product clients of objects
• Figure 12.15 Client-object relations clients of
  each object missing (requests, log-request,
  update-request) in Elevator-controller
• Proceed to the detailed design
• Figure 12.16 Detailed design

26
OO Design Process (Data Resource Management)

• The design of the attributes and operations
  required to manage objects.
• External entities (disk drive, processor,
  communication channel, etc) and abstractions
  (database, objects)
• Human and computer interface

27
OO Design Process (Intersubsystem Commun.)

• List each request that can be made by
  collaborators of the subsystems.
• For each contract, note the operations that are
  required to implement the responsibilities
  implied by the contract (contract is the
  specification of the service provided by a
  subsystem to its clients)
• For each contract, define type, collaborator,
  class, operation
• A subsystem collaboration graph or table can be
  constructed for complex system.

28
Object Design Process (protocol implementation
description)

• Establish the interface of an object by defining
  each message, the related operations.
• Implementation details for each operation implied
  by a message that is passed to an object.
• A specification of the objects name and
  reference to class
• Specification of private data structures with
  indication of data items and types
• A procedural description of each operation

29
Object Design Process algorithm data structure

• A specification for all operations and
  attributes.
• Algorithm is created to implement the
  specification for each operation.
• Since operations invariably manipulate the
  attributes of a class, the design of the data
  structures that best reflect the attributes will
  have a strong bearing on the algorithm design of
  the corresponding operations.

30
Object Design Process components interfaces

• Modularity- specification of component
• Modules are combined to form a complete program
  (defines the object as a program component that
  is linked to other components)
• The interface that exist between objects and the
  overall structure of the objects must be
  identified (stepwise refinement)