Understanding Stages, Processes, and Criteria for Effective Software Design, Slides of Software Engineering

An in-depth exploration of software design, focusing on the stages and processes involved in deriving a solution that satisfies software requirements. Topics include problem understanding, design phases, and modular design methods. Five criteria for evaluating modular design methods are discussed: modular decomposability, modular composability, modular understandability, modular continuity, and modular protection.

Typology: Slides

2011/2012

Uploaded on 07/16/2012

sanaka
sanaka 🇮🇳

4.6

(21)

71 documents

1 / 28

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Software Design
Deriving a solution which satisfies
software requirements
1 COMP201 - Software Engineering
docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c

Partial preview of the text

Download Understanding Stages, Processes, and Criteria for Effective Software Design and more Slides Software Engineering in PDF only on Docsity!

Software Design

Deriving a solution which satisfies

software requirements

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.

Phases in the Design Process

Architectu ral design Abstract specificatio n Interface design C ompon ent design Data stru ctu re design Alg orithm design Sy stem architectu re So ftware specificatio n Interface specificatio n C ompon ent specificatio n Data stru ctu re specificatio n Alg orithm specificatio n Requ irements specificatio n Desig n activities Desig n prod ucts

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.

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

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

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

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.

Hierarchical Design Structure

System level Sub-system level

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.

Exercise

Modular Composability

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, it 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

Modular Understandability

 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; it’s 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.

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