Software Engineering, Lectures

1. SE-381
Software Engineering
BEIT-V
Lecture # 26
(Detailed Design / Module Description)

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

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

4. For Complex SCs and Inflated
Attribute Lists
1
2
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

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

6. Transformation from DFDs to SC
An Example
MAI – Most Abstract Input MAO – Most Abstract Output

7. First Level Factoring

8. Furthering Factoring of Input
Module - SORT

9. Second Level Factoring of SORT

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

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

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

13. – 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

14. – 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

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

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

17. PDL Description for Sort Module

18. • A design in PDL or Structured English is:
minmax (in file)
ARRAY a
DO UNTIL end of input
READ an item into a
ENDDO
max, min: = first item of a
DO FOR each item in a
IF max < item THEN set max to item
IF 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

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

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

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

23. Decision Tree

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

25. Decision Table

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