SE-381Software Engineering

BEIT-V

Lecture # 26(Detailed Design / Module Description)

Recap • We have been thru Structured System Analysis

and partly thru Structured System Design; have completely understood the problem and have modeled its solution in the form of Higher level or System Design

• The Structured Chart (Higher Level Design description) identifies the Modules, their interconnectivity, Interfaces. Functionality of each of these modules and their Test Cases

• These modules – for an Industrial Strength Software – would be in large number and are to be programmed by other team(s) of programmers

Recap

• Higher Level Design was represented by Structured Charts, which were realized from Data Flow Diagrams, keeping Modularity concepts in mind

• In Structured Charts if interfaces are containing larger number of parameters, then these can be represented by table, like

For Complex SCs and Inflated Attribute Lists

12

3

4

Lnk #

Inputs Outputs

1 - a, n

2 a, n a

3 x, y x, y

4 a, n sum

main

sortreadnums

switch

Add_n

Example Problem

There is a text file containing words separated by blanks or new lines. Design a software system to determine the number of unique words in the file

Transformation from DFDs to SCAn Example

MAI – Most Abstract Input MAO – Most Abstract Output

First Level Factoring

Furthering Factoring of Input Module - SORT

Second Level Factoring of SORT

Detailed Design

– These Module descriptions are not detailed enough, so that these can be implemented or transformed into code by Programmers

– Detailed Design, specifies these Modules further in a language that is Unambiguous, Non-confusing, Clear and Detailed to an extent that these Modules can be coded by the programmers independently

Process/Module Description

• Processes or Modules can be described using– Design Specification/Description Languages– Structured English or pseudo-code– Decision Tables– Decision Trees– And other methods, For Example State

Transition Diagrams, Formal Methods; mostly depending upon the nature of the problem

Module Specifications

– Informal methods usually lead to different interpretations, so to avoid this, Formal or Semi-formal methods are used to ensure the specifications are precise and not open to multiple interpretations

– These methods are applicable to both Function or Object Oriented Designs

– It is ensured that Module Specifications are • Complete – these describe the entire behavior of the module• Unambiguous • Understandable – as these are to be implemented by

Programmers, usually not the part of design team– Formal specifications are usually hard to understand

and equally hard to write.

– Module specifications are Implementation Independent – should not specify or suggest any particular method or language of implementation (Key to re-use of design and re-implementation in any HLPL – High Level Programming Language)

– Specifications should give the external behavior, the internal behavior or details of the module should be decided by the programmer

– Hoare 1969, pointed out that the inputs and outputs of a Functional Module should qualify certain Pre-conditions and Post-conditions, say for find_sqrt, the input needs to be non-negative real numbers and output is again a positive real number.

– Older Authors used Structure English for specifying the detailed design of modules, Eg Baynon-Davies 1989, whereas the more recent authors Jalote 2005 etc call it PDL – Process Description Language

– Ideally the Structured English or PDL is to express the design in a way that it is as precise and unambiguous as possible, without having too much detail and that can be easily converted into an implementation.

– PDL has an overall outer syntax of a Structured Programming Language and has vocabulary of a natural language. Same is the case with Structured English

Structured English

– Structured English is used • To remove logical ambiguities and • To describe activities performed by the respective

process• Various blocks are indented, to demonstrate the

structure of the process• Implementation details can be written if needed, in

pseudo code form• Pseudo code is near to physical description of the

implementation

Structured English

• Structured English is comprised of– Keywords or reserved words, used by many of the

PLs like IF, THEN, ELSE, ENDIF, FOR, READ, WRITE, FROM, TO, DO etc for distinction these are usually written in CAPITALS

– Imperative verbs - written in plain English, EG get, receive, update, modify, do, iterate etc

– Variable names – from DFDs, DD, Data Elements or Data Structures, better be italicized Eg stock, students_database, course etc

• Process or Module name should be mentioned on the top in all capitals

PDL Description for Sort Module

• A design in PDL or Structured English is:

minmax (in file)ARRAY a

DO UNTIL end of input READ an item into a

ENDDOmax, min: = first item of a DO FOR each item in a

IF max < item THEN set max to itemIF min > item THEN set min to item

ENDDO END

-----CAPITILIZED are RESERVED WORDS

Problem: Determine the min and max of a set of numbers in a file

An Example

Text is given in a file with one blank between two words. It is to be formatted into lines of 80 characters, except the last line. A word is not to be divided into two lines, and the numbers of blanks needed to fill the line are added at the end, with no more than two blanks between words.

The PDL version of it is …

For Complex Modules …

• Structured English or PDL may not be the solution

• For example, for an automated Chess program, a routine required to move a pawn, will have to consider all possible situations created by that move and this is to be decided with the position of other pawns at the board at that time. So description of such a routine in SE or PDL will not be possible and we can consider options like Decision Tree or Decision Table

An Example – Jungle Kingdom Admission

A Child under 3 years of age is not to be charged an admission fee. A person under 18 is to be charged half full admission. If a child under 12 is accompanied by an adult, however, then that person is to be charged quarter full admission. For persons over 18 years, full admission is to be charged, except for students who are to be charged half admission and senior citizens (women over 60 and men over 65 years) who are to be charged quarter full admission. A discount of 10% is to apply to all persons subject to full admission who are members of a party of 10 or more. Finally, there are no student concession on the weekends.

Decision Tree

Decision Tables

– These are comprised of four parts:• The Condition Stub – indicates in a number of

rows the appropriate questions to be asked.• The Conditions Entry – indicates in a series of

columns the appropriate combination of conditions that apply

• The Actions Stub – indicates in a series of rows the appropriate actions to be taken in a process

• The Actions Entry – indicates in a series of columns the appropriate combination of actions that apply, given the combination of conditions

Decision Table

References

• Pankaj Jalote, (2004 / 2005), An Integrated Approach to Software Engineering, 2nd / 3rd Edition;Narosa Publishing House, New Delhi – Chapter 7 / 8 – Detailed Design

• Paul Beynon-Davies (1989); Information Systems Development, MacMillan, London, UK, pp 93-103, Ch-9 Process Description

• Jeffrey L Whitten, Lonnie D Bentley and Victor M Barlow (1997); System Analysis and Design Methods, 2nd Edition, Richard D Irwin Inc. Ch-19 Designing Structured Programs, pp: 651-677

• E Yourdan and L Constantine (1979), Structured Design, Printice Hall,