Chapter 12 Design Phase*

*This chapter is constructed based on “Software Engineering: a Practitioner’s Approach” (chap 13, 14, 21) [Pressman, 1997]

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

1. Design Model

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

1.2 Design for Object-Oriented Systems:

Subsystem? A subset of all classes collaborate among themselves to accomplish a set of cohesive responsbilities.[ Wirfs-Brock et al, 1990]

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

2. The Design Process

2.1 Design Quality:

  • Implement all of the explicit requirements contained in the analysis model
  • A readable, understandable guide for those who generate code and for those who test and subsequently maintain the software
  • Provide a complete picture of the software (data, functional, behavior domains)
  • Exhibit a hierarchical organization that makes intelligent use of control among elements of software
  • Lead to modular: logically partitioned into elements that perform specific functions and subfunctions.
  • Contain both data and procedural abstractions
  • Lead to interfaces that reduce the complexity of connections between modules and with the external environment

2.2 Design Principles:

  • The design process should not suffer from tunnel vision (consider alternative approaches)
  • The design should be traceable to the analysis model
  • The design should not reinvent the wheel
  • The design should minimize the intellectual distance between software and the problems in the real world.
  • The design should exhibit uniformity and integration.

2.3 Design concepts

  • 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?
  • Are there uniform criteria that define the technical quality of a software design?

Abstraction, Refinement, Modularity

  • 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 (modules) that are integrated to satisfy problem requirements.

How do we define an appropriate module of a given size? [Meyer, 88]

  • Decomposability: decompose a large problem into subproblems that are easier to solve
  • Composability: A design method enables existing design components to be assembled into a new system,
  • Understandability: the easy with which a program component can be understood without reference to other.
  • Continuity: the ability to make small change in a program and have these changes manifest themselves with corresponding changes in one or very few modules.
  • Protection: reduce the propagation of side effects of an error.

2.4 Effective Modular Design

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

2.4.1 Design heuristics for effective modularity

  • Evaluate the first iteration of the program structure to reduce coupling and improve cohesion.
  • Attempt to minimize structures with high fan-out
  • 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 avoid modules that are overly restrictive.
  • Strive for controlled entry modules, avoiding pathological connections.
  • Package software based on design and portability requirements.

2.5 Software Architecture

The overall structure of the software and the ways in which that structure provides conceptual integrity for a system. [Shaw and Garlan, 95] (a structure is composed of components and connectors)

  • Structural properties
  • Non-functional properties
  • Families of related systems

2.6 Control Hierarchy

  • Represents the organization of program components and implies a hierarchy of control.
  • A module that controls another module is said to be superordinate to it; a module controlled by another is said to be subordinate to the controller.
  • Visibility indicates the set of program components that may be invoked or used as data by a given component, even when this is accomplished indirectly.
  • Connectivity indicates the set of components that are directly invoked or used as data by a given component.

2.7 Structural Partitioning

  • Horizontal partitioning: separate branches of the modular hierarchy for each major program function; input/data transformation/output.
  • Vertical partitioning: control and work should be distributed top-down in the program architecture (controller-at-top, worker-at-bottom)
  • Benefits:
  • Results in software that is easier to test
  • Leads to software that is easier to maintain
  • Results in propagation of fewer side effects
  • Results in software that is easier to extend

2.8 Data Structure

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

3. Classical Model: Design Methods

3.1 Data design

  • The systematic analysis principles applied to function and behavior should also be applied to data.
  • All data structures and the operations to be performed on each should be identified.
  • A data dictionary should be established and used to defined both data and program design
  • Low-level data design decisions should be deferred until late in the design process.
  • The representation of data structures should be known only to those modules that must make direct use of the data contained within the structure.
  • A library of useful data structure and the operations that may be applied to them should be developed.
  • A software design and programming language should support the specification and realization of abstract data type.

3.2 Architectural design

3.2.1 Data flow-oriented design: a convenient transition from the analysis model to a design description of program structure.

Design Steps:

  1. The type of information flow is established
  2. Flow boundary are indicated
  3. The DFD is mapped into program structure
  4. Control hierarchy is defined by factoring
  • A top-down distribution of controls:
  • Top-level modules: decision making
  • Middle-level modules: some control and moderate amounts of work
  • Low-level modules: performs most input, computational, and output work.
  • Mapping individual transforms of a DFD into appropriate modules within the program structure.
  1. The resultant structure is refined using design measures and heuristics

3.2.2 Design Postprocessing

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

3.3 Interface design

  • The design of interface between software modules
  • The design of interface between the software and other external entities
  • The design of the interface between a human and a computer
  • Design model: data, architecture, interface, procedural representations
  • User model: novices, knowledgeable, intermittent users, knowledgeable, frequent users
  • Interface design guidelines
  • General interaction
  • Information display
  • Data input

3.4. Procedural design

  • Structured programming
  • Graphical design notation
  • Program design language

4. Object-Oriented Design Process

  • Problem domain: the subsystems that are responsible for implementing customer requirements directly.
  • Human interaction: the subsystems that implement the user interface
  • Task management: the subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems.
  • Data management: the subsystem that is responsible for the storage and retrieval of objects.
  • Partitioning the Analysis Model
  • A well-defined interface through which all communication with the rest of the system occurs.
  • With the exception of a small number of communication classes, 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.
  • Concurrency and Subsystem Allocation
  • Allocate each subsystem to an independent processor
  • Allocate the subsystems to the same processor and provide concurrency support through operating system features
  • The Task Management Component
  • The characteristics of the task are determined
  • A coordinator task and associated objects are defined
  • The coordinator and other tasks are integrated (task name, description, priority, services, coordinates by, communicates via)
  • The Data Management Component
  • The design of the attributes and operations required to manage objects.
  • The Resource Management Component
  • External entities (disk drive, processor, communication channel, etc) and abstractions (database, objects)
  • The Human-computer Interface Component
  • Intersubsystem communication
  • 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
  • For each contract, define type, collaborator, class, operation
  • A subsystem collaboration graph or table can be constructed for complex system.

4.8 Object Design Process

4.8.1 Object Descriptions

  • A protocol description: establish the interface of an object by defining each message that the object can receive and the related operation that the object performs when it receives the message.
  • An implementation description: show implementation details for each operation implied by a message that is passed to an object.
  • A specification of the object’s name and reference to class
  • Specification of private data structures with indication of data items and types
  • A procedural description of each operation
  • Designing algorithms and data structure
  • The system design provides 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 bearingon the algorithm design of the corresponding operations.

4.8.3Program components and interfaces

  • An important aspect of software design quality is modularity- specification of program component (module)
  • Modules are combined to form a complete program
  • OO approach: defines the object as a program component that is linked to other components.
  • During design, the interface that exist between objects and the overall structure of the objects must be identified (step-wised refinement)