Software Engineering (phần 11) docx

Ei
' j
.
! I
'
(
;
*1* t u A p T : R Aa * Design Pbose
' (
1
.
()
t ; Ia.l@ TKSTIN/ PURIN/ TH: DESI*N PHA:K
'
: f
! l The goal of testing in the design phase is to verify that the speciscations have been
.
j I accurately and completely incorporated into the design as well as to ensure the cor-
!
.
i rectness of the design itself. For example, the design must have no logic faults and
l al1 interfaces must be correctly defined. It is im portant that any faults in the design
I
.
be detected before eoding commences. otherwise the cost of fixing the faults will .!
. t be considerably higher. as retlected in Figure l .5. Design faults can be detected by
1 means of design inspections as well as design walkthroughs
. Design inspections are1
: j discussed in the remainder of this section, but the remarks apply equally to design
l walkthroughs
.!

t W hen the product is transaction oriented (Section l 3.4), the design inspection
i should reiect this IBeizer, 19901. Inspections that include a1l possible transaction
!
types should be scheduled. The reviewer should relate each transaction in the de-1
j sign to the specification, showing how the transaction arises from the specitieation
j j' document. For example, if the application is an automated teller machine, a transac-
' ! tion corresponds to each operation the customer can pedbrm, such as deposit to or )!
l withdraw from a credit card account. In other instances, the correspondence between@ i .
l specifications and transactions will not necessarily be one to one
. ln a traffic-light .f
' E $ trol system
.
for example, if an automobile driving over a sensor pad results in thecon
1 i
! i system deciding to change a particular light from red to green in l 5 seconds, then
,
t further impulses from that sensor pad may be ignored
.
Conversely, to speed trafhc
i I
t ! flow, a single impulse may cause a whole series of lights to be changed from red to .
i ! reen
.
g-
;
1
.
k Restricting reviews to transaction-driven inspections will not detect cases where
' '1 the designers have overlooked instances of transactions required by the specifications
.

I
To take an extreme example, the specilications for the traffic-light controller may
i stipulate that
,
between l 1:00 P.M. and 6:00 A.M., all lights are to llash yellow in one
. !
direction and red in the other direction. lf the designers overlooked this stipulation
,l h
en clock-generated transactions at l 1 :00 P.M. and 6:00 A.M
. would not be includedl t
( j
'
in the design', and if these transactions w ere overlooked, they could not be tested in
j a design inspection based on transactions. Therefore. it is not adequate to schedule '
' i inspections that are just transaction driven', specihcation-driven inspectionsdes gn 1
.
( also are essential to ensure that no statement in the speciscation document has been
l ither overlooked or misinterpreted
.
e
! !' (
'1!
ï 1( :
j l
(
.
1 '
' ' laal QASE Tooks F@R TH: PKSI/N PHAS: f1
-
'

i As stat
ed in the previous section, a critical aspect of the design phase is testing that the1
l design document accurately incorporates aII aspects of the specifcation document
.
'
!
W hat therefore is needed is a CASE tool that can be used both for the specihcation
Please purchase Image To PDF Converter on to remove this message, thank you.
f .
:
i E
:
.
l
'
Iaaa M ETRIKS FoR THE DESIGN PHM E *%@ I 13
1
è
'
q .'
he design document, a so-called front-end or uppercAsE tool (as : I )document and t
l (
opposed to a back-end or 1owerCASE tool, which assists with the implementation, ) j
integration, and maintenance phases). ! y
' A number of uppercAsE tools are on the market
. Some of the more popular # :
1 i
ones include Analyst/D esigner, Software through Pictures, and System Architect. ;
'
UppercAsE tools generally are built around a data dictionary. The CASE tool can 1

check that every held ofevery record in the dictionary is mentioned som ewhere in the
idesign docum ent or that every item in the design document is reqected in the data llow
,
ion, many uppercAsE tools incorporate a consistency checker that ' 1
:
1diagram
. ln addit i
uses the data dictionary to determine that every item in the design has been declared i
: Iin the specifications and conversely that every item in the specifications appears in
g ë
' I lthe design
. j )
Furthermore, many uppercAsE tools incorporate screen and report generators. y l 1
; 1 I
That is, the client can specify what items are to appear in a report or on an input i ! :
J . !
. screen and where and how each item is to appear. Because full details regardinx E I '
.
-'
'
'
*' -''-' -'''' i
.
every item are in the data dictionary, the CASE tool easily can generate the code for . j
inting the report or displaying the input screen according to the client's wishes. y ) lpr
.
lS
ome uppercAsE products also incorporate managem ent tools for estim ating and I
: . I
planning. J ( !

With regard to object-oriented design, Together. Rose, and Software through ! l
.
ë iPictures provide support for this phase within the context of the complete object
-
: tJ
'
l
oriented Iife cycle. 1 1 ,
i l
i l f' ' j' i
1 ir7 iI
!
.
1
'
3 ( (la
.
lo KTRIt: FoR THE P ESI/N PHASK i r,1
!
IE
? 1
. .
A variety of metrics can be used to describe aspects of the design. For example. 1;
I ' lthe number of modules is a crude measure of the size of the target product
. M odule : 4
'
.
i
cohesion and coupling are measures ot the quality of the design, as are fault statistics. ; t
As with all other types of inspection, it is vital to keep a record of the number and type 1C

-
1:of design faults detected during a design inspection
. This information is used during j
code inspections of the product and in design inspections of subsequent products. lj!
1
The cyclomatic complexity M of a detailed design is the number of binary deci- '
sions (predicates) plus l EMccabe, 1 9761 or, equivalently, the number of branches in
the module. It has been suggested that cyclom atic complexity is a m etric ot design j i
quality: the lower the value of M , the better. An advantage of this metric is that it ' '
!i
s easy to compute. However, it has an inherent problem . Cyclomatic com plexity is ; ! y
p '
'
a measure purely of the control complexity', the data complexity is ignored. That iss l i
M does not measure the com plexity of a m odule that is data driven. such as by the : j
,
values in a table. For example. suppose a designer is unaware ot the C++ library 1 l '(
function toascii and designs a module from scratch that reads a character input by '; 1 '.
lthe user and returns the corresponding ASCII code (an integer between 0 and l 27)
.
! r :
7 .One way of designing this is using a l28-way branch implemented by means of a j
,
1 .
1
;1. :
f' '!ù
'
'
'

;
I )
Please purchase Image To PDF Converter on to remove this message, thank you.
1
i
i
k
'
#Q@ t H A p T E R la @ Design Phose
,i
( :'
, j swikh statement. A second way is to have an array containing the l28 characters in
! ASCII code order and utilize a loop to com pare the character input by the user with
I
6 each element of the an-ay of charaeters'. the loop is exited when a match is obtained
.
'
1 I x
.
j j The current value of the loop variable then is the corresponding ASCII code. The twe
1 ! designs are equivalent in functionality but have cyclomatic complexities of 128 andI
, . 6 l , respectively.
.
I
t ( W hen the structured paradigm is used, a related class of metrics for the design
'
I phase is based on representing the architectural design as a directed graph with the
.
1
t modules represented by nodes and the flows between modules (procedure and function

'
I
l calls) represented by arcs. The fèln-in of a module can be dehned as the number of
1 '''
'
''' ''
.
; 1 flows into the module plus the number of global data structures accessed by the :
' j'
j module. The fan-out similarly is the number of llows out of the module plus the!
, 'k number of global data structures updated by the module. A measure of complexity
'
j
! 2! of the module then is given by Iength x (
,/?zz?-/z? x fan-out) jldenry and Kafura,
.
I I 98 l1, where Iength is a measure of the size ot the module (Section 9.2.1 ). Because :
ù l the deunitions of jttn-in and Iàn-out ineorporate global data
,
this m etric has a data-
'
i 1 dependent component
.
Neve'rtheless
,
experiments have shown that this m etric is no
'
p .
r better a measure ol complexity than simpler metrics, such as cyclomatic complexity
l . yKitchenham, Pickard

, and Linkman, 1990., Shepperd, 19901.' ! I
! 'j The issue of design metrics is even more complicated when the object-orientedt
l paradigm is used
.
For example, the cyclomatic complexity of a class usually is low,i
! j because many classes typically include a large number ofsmall, straightforward meth-
1
h i ods. Furtherm ore, as previously pointed out, cyclomatic complexity ignores data
: complexity. Because data and actions are equal partners within the object-oriented
.
j
: i paradigm, cyclomatic complexity overlooks a major component that could contribute
: l j
j to the complexity of an objeet. Therefore, metries for elasses that incomorate cyclo-
i matic complexity generally are ot little use.
i A number of objeet-oriented design metrics have been put forward
,
for example,!
) in tchidamber and Kemerer, l 9941. These and other metrics have been questioned on
q both theoretical and experimental grounds gBinkley and Schach, 1996., 1997., 19981.
1 .
!
.
-
)
(
.
I
l .t Iaaa A IR G O URM ET CAS: sTupyr '
! @ BJK<T-@ RIKNTZP p zsloxt I

' l As described in section 13.6, object-oriented design consists offour steps.!E
.
I
' ê
!
s:ep 1. tons:eue In:eyot:ll. plogyom s Ioy Koth n enael. The se-
'
'
.
l quence diagram for the extended scenario for making a reservation (Figure 12.12)
'
$ is shown in Figure l 3. l 8. The sequence diagram was constructed by taking each
statement in the scenario and drawing an arrow between the instances of the relevanti
lasses. In more detail, first the actors of the scenario were determined: Possenger,: c1
l t
I .
1 .
'
Please purchase Image To PDF Converter on to remove this message, thank you.
- E
'
.
!
. I I
Aaaa AIR GOURMG CM E STUDY: O BJKT-ORIENTED DESIGN *QX ' ' l!
p :
l Phone XiT i ;
Passenger Gourmet .l oxrator i
database
.

!) j
,
request i
l reservation j !
.
t
2 quel'y name 7 :
1 ' q .
' and address :
i !
l 3. give name i 'I l
g and address 1! jt 1
! !
'
.
4 quew flight l'i l
t ) information I :
' I ! (
'
,
,
s. give flight 1 i
5 i
'
information ( ! !)
-
' 6. query special l l
.
I )) meal
I

. I
l 17
.
give meal i .h
'
yinformation , !j
.
I
'
li
! ', 8. query seating ;
> j 1
- information
E t
i 9 iVO Seating !
.
g .
j information j
5 (
,
10. query payment l
- ;information 1
1 r
l ! -
:. 1 1 . give payment
.
p r :
a information ! , q
.
'

12. commit flight t
reservation i )
; : '13
. issue
Q
reservation ID '
7
- j'
14. finalize !
I
; reservation l!
;
'
i l
I I
'
Flgvre Aa.1e Sequence diagram for scenario for making a reservation (Figure 1 2. 1 2). ') l
'
1!
1 t .,;

Phone Operoer, and Air Gourmet dolobose. Boxes containing the names of these , l ' )
j j ,l
z three actors are placed at the top of Figure l 3. 1 8 and vertical double lines drawn y j
kt in. Now each event of the scenario is exam ined and entered in the sequence dia- !, i
! 'j
. xram . For example, in the first event, the passenger calls a phone operator to make a
' ï
'
.

' ! i
'
.
: 'j
) E
'
1 i
- !
Please purchase Image To PDF Converter on to remove this message, thank you.
l 'j:
! 1
i ,;
i I .
I ' *QQ t H A p T E R 'a @ Design Phose
:
p
1 1 . Send postcard +
1 -
I * 2. return postcard
i 1 passenger
j Air Gourmet Staff MemberI
.
i 1
! I '
i
,
'
; 3. record meal quality
l:
.

j
:
l
t (
! ë Air Gourme
-
t database
' ;
'
' j
.
$
'
l I Aaa. c
olloboraùion diogram for scenario for returning and scanning postcordI F 9MKe
' l (Figure 1 2. 1 .4).
II 1
1 ion This is modeled by the horizontal arrow from the Possenger vertical
,
,
reservat .
!
; double lines to the vertical double lines of the Phone Opercfor bearing the label 1 .
l request reservation. The remainder of the sequence diagram is equally straightfor-
.
i I
.
( ward, as are sequence diagrams for the other classes.
'
1 1 The collaboration diagram for the scenario for returning and scanning a postcard

) ') (Figure 12.14) is shown in Figure 13.19. As with the sequence diagram of Figure
.
1 l l 3
.
l 8, the first step in constructing the collaboration diagram is to examine the ex- '1
i tended scenario (Figure l 2
.
l4) and determine the actors. In this case. they are found .i
t
l to be Air Gourme, SKff Member. Possenger, and Air Gourmet dclobcse
. These!
.
) actors are drawn in Figure 1 3. l 9. Next. each event is examined and entered in the
I diagram. ln event l , a member of the Air Gourmet staff mails a postcard to each
i passenger w ho received a special m eal
.
First, a line is drawn between Air Gourmei;
.
1 Sloff Member and Pqssenger. Then, a labeled arrow is inserted to denote that the
!
'
j staff member sends a postcard to the passenger.
j The second event is the passengerreceiving the postcard, filling it in, and returning
I it to the staff mem ber
. This is denoted by the arrow in the reverse direction with theI
h label 2. return postcard.
1 The third event is the staff member receiving the postcard and updating the
I
l relevant flight record to refleet the passenger's opinion of the special meal he or she
l

) received. A vertical line is drawn between the icon representing the Air Gourmet
.
i staff member and the box representing the Air Gourmet database
. Finallys an arrow is!
' j added bearing the label 3. record meal quality. The remaining interaction diagramsl
j are constructed in the same way.
;
I(
'
1 1 s.ep Q. toss,rve. ee p-olled tloss plogrom The detailed class dia-
1 I ram for the c++ implementation is shown in Figure 13.20 and for the Java imple-g
.
1 jl mentation in Figure 13
.
21 . One difference between the two figures is that Java has
I built-in classes for handling dates, pvq.textwDcieformct and pvcoutil.culendor,
.
1
'
,
j .
!
(
'
1
'
j .
!
Please purchase Image To PDF Converter on to remove this message, thank you.
' h

'
.
'
. i
'
) :Date Flight Record Passenger
.
i
month : short passenger ID : string passenger ID : string !
!
' month name : string reservotion ID : string first name : s'ring k
day : short ffight number : string middfe initial : char '' '
!
year : short flighi date : string Iast name : string I 1
ber : string 1 * suffix : string 1stc date : string seat num
meal type : m-type address 1 : string .
et month () meol Ioaded : boolean address 2 : string j i
i9
.
set month () on board : boolean city : string I j
t month name () perc meal quolity : int state/province : sùring ' ''9e J jt sef monfh nome ()
posàal code : sàring
t day () 9et passenger ID () jry : strino j!, :,ge coun
'
et day () 5et Possenger ID ()s I
et year () 9et reservation ID () get jassenger ID () 1:
.
9 I
set year () set reservation ID () get flrst name () I :
et str. dute () get flight number () set middle initial () 1

.
'
9
set str. date () set flight numLer () get last name () 1
. .
is Ieap year () :et flight date () get suffix () ' ''
da s in month () set flisht daie () get address 1 () ' :t'
t number () get address 2 () !r ' :valld date () :et sea
breok up date () set seat number () get city () k .
set meal type () get state () E
set meal type () get postal code () ' E
get meal Ioaded () et country () j ;@
iset meal loaded () lnsert () . E
.
jgef on board ()
write () '. I ! I
set on board () read () : i . ' .
get perc meal quality () get passenger () ' . l
t erc meal quality () get descripfon () '
,
: l 1se p
l ! k
'
insert () . i
write () . : .'
reud () : ( '
' g
'
J
gef reservofion () l ;:

'
!
check in possenser () ; ' ,
scan speciol meals () ! E
scan postcard () .1
check reservation id () !
4check flight number () . !
5 h k seat number () i 1: :C ec
I
.
1 Ialready exists ()
.
!
.
j '* . I
1 'C
) !t '
Report 1
from date : string 2 '
date : string i 'to
)
I l
get from date () 'I l
get to date () !l
set from date () I'
!
set to date () . Ii
! Iprint ()
'
)

'
)
'
1
*
'
'

'
virtuol
I
l
'
ge# juolificofions () . i J '' I
quullfies for report () '
rint record () ; 'P
1! ,
I
Flgvre 1a.Q@ Detailed class diagram for C++ implementction of the Air Gourmet product.
j '.
Please purchase Image To PDF Converter on to remove this message, thank you.
)
'
.
i
i
1 *Q*
t H A p T E R 'a * Design Phose5
1 Report
!

l from date : oate
.
1 to dafe : Date
1
. . oet from dote ()
.
'
t gej to dote ()
.
1 set from date ()
.
1
1 set to date ()
1.
print () .I
virduol
.
1 et qualijicagions ()
: 9I
ualifies for report ()q
.
1
print record ()l
!
l
l
I
l
!
; Percentage Report Low-sodium Report Poor-ouality Report

i 1
'
l Iouded as specified
,i 1 Iifies for report () quolifies for report ()
pussenger on board, qua:
l int record () .
.
totol encountered, pr'
.
j j tj tj : ; nt j g a jnot oa e
I
, ! print ()i
' Iifies for report ()
.
) : l qUa
.
! print record () '! .
'
j
i N
ot-Loaded Report Onboard Report Caterer Report
:
j flight number : string fligh@ number : string
j print () special meal tally :
.
1 qualifies for report () i
nt () kntl 1 a)l Pr
print record () jjgcotions ()l get qtla
au
, already encountered () q jifjes jor

report () print ()l no9 Ioaded > once () ' ef qualifications ()9
1 qualifles for report ()l
Flgure 13.2* Detailed class diagram for C++ implementation of the Air Gourmet product (continued).)
1
E
) '
whereas a user-defined class Do1 is needed in the C++ implementation. Another :
'
I difference is that Java is a pure object-oriented language, that is, a Java program
l consists of a set of classes
,
whereas C+ + supports functions. W ith regard to this
! I difference, the class Air Gourme' Applkadion corresponds to C++ function mcin,
'
i and class Air Gourmel Uiilities corresponds to C++ utility functions.
l The methods for the product appear in the various interaction diagrams
. The task
of the designer is to decide to which class each method should be assigned. ln the
.
j '
Please purchase Image To PDF Converter on to remove this message, thank you.
i
' IAi
r Gourmet Application Flight Record Passenger
passenser ID : string pussenser ID : string . .
'
ID tring first name : s'ring E .reservation : s
flight number : string middle initial : char C ,
flight date : Date Iast name : string I i
1 * suffix : string ! 1seat number : strinn

.
''''' 1
meal type : m-type address 1 : string j
meal Ioaded : boolean address 2 : string iAir Gourmet Utilities
.
on board : Eoolean city : string i
.
perc meal qualiiy : int state/province : string ! , !
get character () ostol code : string E IP
read string () get passenger ID () country : string 1; '
clear screen () set passenger ID () lE .
'
press enter () get reservation ID () get passenger ID () 1.1 E
.
. display main menu () set reservation ID () get first name () 1.
'
display report menu () get flight number () get middle inifal () '!: .
set flight number () get Iast name () li y
'
get flight date () get suffix () 1';
set flisht date () get address 1 () ( '
get seat number () get address 2 () I '
set seat number () qet cify () 1 '
j '' ê' ' .get mea type () get state () !
set meol type () get postal code () !
. et meal Ioaded () get country () t9
set meol Ioaded () insert () j . i
board () write () ! : lget on l
set on boord () read () ! . IE
:

get perc meal quality () get passenger () ! . l
'
I Ii () et description () ! ' 'set perc mea qua ty g l!
'
insert () ' i
.
-
I
write ( ) . !
, J
read () : i I
get reservation () . ' .
check in possenger () g '
scan special meals () '
scan postcard ()
check reservation id () ''
,
.
)
'
check flight number () I . i
check seat numlxr () .1 1:1
'
already exists () ,
.
l 1
* j
1'
1 1.
neport Ii

Ii
.
11f
rom date : Date !
to date : Date !
,
.
!i
get from date () j !
d te () iget to a j I
set from date () . 1 , ' '
t to dote () ! ' 1se j
.
int () ' ! i 1pr !
obsirod i j j
get qualifications () ! 1 :lquclifies for report () '
: '
print record ()
Flgvee la.Ql Detailed closs diogram for Java implementaiion of the Air Gourmet product. j:
1-
Please purchase Image To PDF Converter on to remove this message, thank you.
I i
I 1 ,
! I .
' ' 21 t u A p T : m Ia * Deslgn Phose*!
.
!
!
? ReportIi
Il 1 from dote : Dote

l ' to date : Date1
I l f
m da. ()i 9Of UOl
:
E ! get to date ()
! set from date ()
( !
'
.
! Set tO date ()
.
j prjnj ()l
obstrotjl
j ualifications (); e; 9 qi
j ualifies for report ()q
.
, j prknt record ()
'
rï
j
.
1 '
1 1
2 . jl
ti
; .
l Percentage Report Low-sodium Report Poor-ouality Report
, l .1
:
i l Ioaded as specified,

'
f passenser on boord
,
qualifies for report () quolifies for reporf () :
.
I i d ( ) .t
otal encountered, Print recor'
'
;
'
11
I not loaded : intg 1 31
1 ' ''
'
'''
.
1 1 .
i print ()1 :
t
y
j qukaoltifies for report (), pr record ()
.
q à!
!
Not-Loaded Report Onboard Report Caterer Report
flight number : string flight number : string .
'
.
print () iaI meal tally : .spec
r qualifies for report () i

nj () jnfjla) 'l i
nt record () PVpr
ej qualifications ()1
already encountered () 9
' 1 aualifies for report () print ()
not Ioaded > once () ' t uolificafions ()i l ge q
: i i Iifies for report ()i i 9t11
.
' ! j 'i
2! ! Flgur. 1a
.
24 Detailed closs diagrom for Javo implementation of the Air Gourmet product (continued), .
j ô -
l 1
i I
! l
1 !
,
i ! case of the Air Gourmet product, the assignments of methods to classes is straight-I
k q forward. For example, method get passenger ID clearly belongs in class Pcssenger.
.
i
.
'i
! s'ep a. peslgn :lxe produe In Tey-s ol oblees d Th@lr tII@nI,
1 The third step of OOD is to design the product in terms of objects and their clients
,
'
j
1 as described in Section l 3

.
7. The client-object relations are shown in Figure 13.22! 1
.
j l
)
.
I!
Please purchase Image To PDF Converter on to remove this message, thank you.
I
:
I
! .
laaa AIR GOURMET CAS: STUDY: OBJKT-ORIENTED DKSIGN #2T i ;
.
(
main I :
.
L
2'
j
. . .
j .
' j
display main menu j
! !
'
j l l. I .: 1
!
display report menu : é f
.

j .
*
1
. (
'
1
i!
'
.
; j .
1!
percentage Not-Loaded onboard ; 1
Report Report Report 1! ;
i :
- lC
aterer Poor-ouality Low-sodium :
Report Report Report i ë
E
' j- t j
I q l:
,
!
-
1t -
i r I .
g ; lR
eport ' i ' '
; :
t .l
.

i i '
.' ' )
'
j
: . 'i
j 'i è
,
Flight Record Passenger
l
. 1
l : :
' 1!
t .
I
j j
IDate
12
j 1 '
l
jj
d
-
'
'
'Igure 'a.2Q Client-obiect relations for C++ implementation of the Air Gourmet product.
.
r
i
l i1
i

(for implementation in C++) or Figure l 3.23 (for implementation in Java). These 1 il
:
-'
are not UML diagram s. They are included in this book because my experience is that , !
' jdiagrams of this kind can assist in gaining an understanding of how the various pieces ' i
h 4 j 1 .
of the product fit together and, in particular, can make the detailed design easier to ) r I
1 I 7 j !
construct. j
The client-objeet relation diagrams were construeted by taking each CRC card !
and determ ining which methods of other classes are invoked by methods of that class.
'
II
Ii .
I .
11; '
i ;
Please purchase Image To PDF Converter on to remove this message, thank you.
1 1I
i 't
*2a t u A p T z * Aa @ Deslgn Phose
l
1
l Air Gourmet
1 Application1
j '
!
I
l 2 .
l Air Gourmetq

i tJ tilititr i;
.
I
i s
'
l
.
i
l .
'
'
(.
.
'
.
'
!
'
.
:
) Percentage Not-Loaded Onboard '
: 1 Report Report Report '
! II
j J caterer Poor-ouality Low-sodium ,
! Report Report Report
1
; -
1
l ; .l
i

'
1 ! e
l ReportI .1
t . .
l
1 '
i
' ! Flight Record Passenger
''
i !
'
y
'
1
è Flguee laooa client-obiect relations for Java implementation of the Air Gourmet product.
1
1 In general, if CRC cards have not been constructed, then class diagrams can be used '
i for this purpose
.
l
I The rapid prototype of the Air Gourmet product (Appendices C and D) showed '
! that a menu-driven design would be feasible. The main menu allows the user to select
.
1 which of the six reports is to be printed. This is reflected in Figures 13
.
22 and 13.23.1
t
i s:@p *. pe:elled peslsn Finally, the detailed design is built. A complete
1 detailed design appears in Appendix H (for implementation in C++) and Appendix
!

j I (for implementation in Java). The detailed design was built by taking each method
i or function and determining what it does. The tabular notation for the detailed design
I j may seem somew hat cum bersom e, but its formality aids the programmers.
'
i t Now that the design is apparently complete, al1 aspects of the design must
I be rechecked
. No faults are found. Nevertheless, it is possible that the design will .i
2
' change again, perhaps radically, w hen the Air G ourmet product is implemented and
integrated.
:
1 :
l )
!
Please purchase Image To PDF Converter on to remove this message, thank you.
' )
I
I
' j ;
CHAPTZR Rzvlzw *2* 2
l
! 1I
:
.
lla
.
1* ZHALL:N/'S @F THz D E/I/N PHA*: l: I
' !
I tAs pointed out in Sections 1 l
. 16 and 12.9, it is important not to do too much in the .

specifications phase; that is, the specilication tcam m ust not prematurely start pa14s g
é
of the design phase. ln the design phase, the design team can go wrong in two ways: ! ! '
! I
by doing too much and by doing too little.
Consider the PDL (pseudocode) detailed design of Figure l 3.7. The temptation is .' '
ite the detailed design in C++ or Estrong for a designer who enjoys programming to wr
f sketching the detailed design in pseudocode, 1Java
,
rather than PDL. That is. instead o
le. This takes longer to write thanjust outlining !:the designer may all but code the modu I
'
the module and longer to tix if a fault is detected in the design (see Figure l .5). Like jë
.
the speeification team, the members of the design team must firmly resist the urge to :
do more than what is required of them. !
'
At the same time, the design team must be careful not to do too little. Consider the 11
tabular detailed design of Figure 13.6. If the design team is in a huny it m ay decide f r
:
to shrink the detailed design to just the narrative box. It even may decide that the i
programmers should do the detailed design by them selves. Either of these decisions
would be a mistake. A primary reason for the detailed design is to ensure that all ( k
'
interfaces are correct. The narrative box by itself is inadequate for this purpose; no i I
$ 1
detailed design at al1 clearly is even less helpful. Therefore, one challenge of the 1 ': l
1 ; (
'
design phase is for the designers to do just the correct amount of work. ! , j:

.
In addition, there is a much more significant challenge. ln his tûNo Silver Bul- ! I
let' article gBrooks, 19861, Brooks decries the lack of what he terms great design- j ', I
h h : k 'ers
,
that is, designers who are signihcantly more outstanding than t e ot er mem -
, I!
Ibers of the design team. ln Brooks's opinion, the success of a software project de- E , (
! lpends critically on whether the design team is 1ed by a great designer
.
Good de- f . (
sign can be taught', great design is produced only by great designers. and they are :1 l
Very rare. I 1
The challenge, then, is to grow great designers. They should be identihed as early ;
as possible (the best designers are not necessarily the most experienced), assigned a 'i
I
mentor, provided with a formal education as well as apprenticeships to greatdesigners, 1.
d allowed to interact with other designers. A speciéc career path should be available 1'an
!for these designers
, and the rewards they receive should be commensurate with the ji
contribution that only a great designer can make to a software development projeet. j:
l
i
l ;
' k
'
:
'
/ lCHAPTER REvlew
i !i

t l
: ; 1The design phase consists of architectural design
,
followed by detailed design (Sec- ) (;
tion 13. l ). There are three basic approaches to design: action-oriented design (Section : i . t
' il 3
.
2). data-oriented design (Section l 3.5), and object-oriented design (Seetion l 3.6). ; .
: JE
!
L
I
Please purchase Image To PDF Converter on to remove this message, thank you.
!
l
l *a@ t H A p T : R la * Design Phose
i
l
l Two instances of action-oriented design are described
, data flow analysis (SectionI
l 3.3) and transaction analysis (Section 13.4). Object-oriented design is applied to1 the elevator problem in section l 3
.
7. Techniques for detailed design are put forward a
.
j) in section 13.8. Real-time system design is described in Section l 3.9. In SectionC
I ! l3.l0s design inspections are discussed. CASE tools and metrics for the design phase % ,!
,
t are presented in Sections 13. l l and I 3. 12, respectively. The chapter concludes with **
'
1

E ii the object-oriented design of the Air Gourmet Case Study (Section 13. 13) and a
'
1 discussion of the challenges of the design phase (Section 13
.
14).
.
3@3
j I
! l
1 l
! 1 ' 3.4
; '(l
tj 3.5
lj FoR FuRTuzm Ruplxo a.o1
!
l Data flow analysis and transaction analysis are described in books such as (Gane and
' ) , $.7Sarsen
,
1979, and Yourdon and Constantine, 19791. Jackson s technique is described)
!
in glackson, 19751. For readers interested in Warnier's work, the original source is .
,.,'j l (Warnier, 19761. Orr's approach can be found in gorr
, 198 l1.l
Turning now to object-orientcd design, information can be obtained from 3.#.1
.
l
; i L'Wirfs-Brock, Wilkerson, and W iener, 1990., Coad and Yourdon, 199 lb; Shlaer and .
rf l Mellor, 1992,. and Jacobson, Booch, and Rumbaugh, 19991. Comparisons of a vari-$
'
ety of techniques for object-oriented design appear in rMonarchi and Puhr, 1992, and .1:l

walker, 19921. Acomparison of bothobject-orientedand structureddesign techniques j j
*! appears in (Fichman and Kemerer
, 19921.
.
J .12
t Formal design techniques are desclibed in (Hoare, 19871.l
.
l
; I W ith regard to reviews during the design process, the original paper on design
l inspections is gFagan
, 19761., detailed information can be obtained from that paper.: i
.13) j Later advances in review techniques are described in rFagan
,
19861. The use of walk-$ th
roughs to test user interface design is described in EBias, 19911. .
: l w ith regard to real-time design
,
specihc techniques are to be found in rWardj and Mellor
, 1985,. Levi and Agrawala. 1990., and Cooling, 1 9971. A comparison of
: 1
,
j four real-time design techniques is found in (Kelly and Sherif, 19921. The September
l 1992 issue of IEEE Software contains a number of articles on the design of real-time!
t systems, as does the June 1995 issue of IEEE Computer. The design of distributed
1 systems is described in (Kramer, 19941. The September/october issue of IEEE Soft-I
:1 wtzrtr contains a number of papers on architectural design, especially (Herbsleb and
:'I Grinter
,
19991.1
j Metrics for the design phase are deseribed in îl-lenry and Kafura, 1981; Brandl,

.
1 1990., Henry and Selig, 1990,. and Zage and Zage, 19931. Metrics for object-oriented
.
'
( .design are discussed in (Chidamber and Kemerer
,
1994, and Binkley and Schach,
.
)
j . 1996j.
'
) The proceedings of the International W orkshops on Software Specihcation and
!
k Design are a comprehensive source for information on design techniques.E
t
.
! I
i
1
) I
l
Please purchase Image To PDF Converter on to remove this message, thank you.
: t
REFERENCES *aI .
PR@BLKM: i i l
.
'
!
: i11
.

1 Starting with your DFD for Problem l l .6, use data flow analysis to design a product j
for determining w hether a bank statem ent is correct. 1
E
'
l ATM (Problem 8.9). At ' i11
.
2 Use transaction analysis to design the software to contro an
; r
'
k
'
this stage omit error-handling capabilities. j
11.3 Now take your design for Problem l 3.2 and add modules to perform error handling. ( 1 1
Carefully exam ine the resulting design and determine the cohesion and coupling of ' 1:
() 1
.
the modules. Be on the Iookout for situations such as that depicted in Figure 13.1 . (
i I .13
.3. l (Figures 13.6 and l 3.7). Compare and contrast the two techniques. 1
.
11.5 Starting with your data flow diagram for the automated library circulation systenz !
!(Problem l l
.8), design the circulation system using data flow analysis. ,(
.
'
. )
'
11.6 Repeat Problem 1 3.5 using transaction analysis. Which of the two techniques did you l!
E(find to be more appropriate?
I

113
.7 Starting with your object-oriented analysis for the automated library circulation sys- 1 j
tem (Problem l 2.2), design the library system using object-oriented design. 1 '
11.8 Design the ATM software (Problem 8.9) using object-oriented design. ' i
i l11
.
9 (Term Project) Starting with your specifications of Problem l l . l 5 or l 2.9, design the j j
' ital product (Appendix A). Use the design technique 1 ' 1Broadlands Area Children s Hosp :
1 !
specified by your instructor. I
: )
'
I1
.
1Q tcase Studv) Redesi/n the Air Gourmet product using data flow analysis. 7 , l
.
'' '''' - - ''''''''
I
; I1
.1 1 (Case Study) Redesign the Air Gourmet product using transaction analysis. : ' 1
1.12 (Case Study) The detailed designs ot Appendices H and Appendix l are represented in I
hoice. Which i ltabular form
.
Represent the design using a PDL (pseudocode) of your c
p lrepresentation is superior? Give reasons for your answer
. 4 !
1.13 (Readings in Software Engineering) Your instructor will distribute copies of (Stolper, 1 !
.
' t
l 9991. What are your views regarding the introduction ot the object-oriented paradigm i E: ;

into an organization using the classical paradigm? 1
.
1 '
1
11
.
*
.
'
-
1 :R KFKRENtES i
.
! ;
'
(Beizer, I 9901 B. BElzER, Software Testing Techniques, 2nd ed., Van Nostrand Reinhold, :
New York, I 990. 1 t
Bias, I 99 l 1 R. BIAs, ''Walkthroughs: Efficient Collaborative Testing.'' IEEE Software 8 l i
.
i l(S
eptember l 99 1 ), pp. 94-95. ; j jI
(Binkley and Schach, 19961 A. B. BINKLEY AND S. R. SCHACH, :'A Comparison of Sixteen : ! ! I '
- ,.
. s,txo. 6. . ë ,Quality Metrics tor Object
-
oriented Design, Iljlbrmation Prot-t?xxïfn.g Letters I
lJune 1996)
,
pp.271-75. li
! ,
'

(
Please purchase Image To PDF Converter on to remove this message, thank you.
. t
t
<n > *e <
1
l
I l
I1 I
:1 I k: : T TI :l I
l I
i $
l 1
.
l 1!
t ttI
1
j .
1
! .
.
' I i th
e process of translating the detailed design into code. When this is done by a singlemplementation s1 individual
,
the process is relatively well understood. But m ost real-life products today are too large to be
implemented by one programmer within the given time constraints. lnstead
,
the product is implemented by a
l team, working at the same time on different components of the product
. This is termed programming-in-tbe-

1 1 iated with programming
-
in-the-many are examined in this chapter. 'many
.
Issues assocl
'j
I 1* 1 tuo lt: o y ppoou - M lxo No uAozi e
!
! ln m ost cases
,
the issue of whieh programming language to choose for the implemen- '' i t
! i tation simply does not arise
. Suppose the client wants a product to be written in
,
say,I
i Sm alltalk
. Perhaps, in the opinion of the development team , Smalltalk is entirely un-
i suitable forthe product. Such an opinion is irrelevant to the client
. M anagement of thel
.
j development organization has only two choices: lmplement the product in Smalltalk
'
j or turn down the job.;l
' j Similarly. if the product has to be implemented on a specitic computer and thel
I only language available on that computer is assembler, then again there is no choice
.
!
i
l lf no other language is available, either because no compiler has yet been written for
any high-level language on that com puter or m anagem ent is not prepared to pay for a

new C++ compiler for the stipulated computer. then again clearly the issue of choice
of program ming language is not relevant.
A more interesting question is this: A contract specifies that the product is to be
' implemented in Sûthe most suitable'' programming language
.
W hat language should be
s chosen? To answer this question. consider the fbllowing scenario. QQQ Corporationt(
I has been writing COBOL products for over 25 years. The entire zoo-member software
'
1 j staff of QQQ. from the mostjunior programmer to the vice-president for software, hasi
1 COBOL expertise. W hy on earth should the most suitable programm ing language be '!
L anything but COBOL? The introduction of a new language, Java, tor example
,
wouldi
i
1
t 434
i
j ' .
'
(
Please purchase Image To PDF Converter on to remove this message, thank you.
!
.
!
.
,
' I
.
CHOICE OF PROGRAMMING LANGUAGE *a5 ; l1*.4

' j
.
; I
mean having to hire new programmers or, at the very least, existing staff would have 'r 1
in Java training, 'q 1to be intensively retrained. Having invested all that money and effort
!ma
nagement might well decide that future products also should be written in Java. ) ! ;
l l
Nevertheless. all the existing COBOL products would have to be maintained. There ' .
2 Ithen would be two classes of programmers
,
COBOL m aintenance programmers and ' i i
: jJava programmers writing the new applications
.
Quite undeservedly, maintenance i r
!almost always is considered inferiorto developing new applications
,
so there would be i
ldistinct unhappiness among the ranks of the COBOL programmers
. This unhappiness
E I !would be compounded by the fact that Java programmers usually are paid more r
lthan COBOL programmers because Java programmers are in short supply
. Although i
: j 1.QQQ h
aS excellcnt development tools for COBOL, a Java compiler would have to f
be purchased, as well as appropriate Java CASE tools. Additional hardware may ' 1
:l! h
ave to be purchased or leased to run this new software. Perhaps most serious of )ë
all, QQQ has accumulated hundreds of person-years of COBOL expertise, the kind I::
of expertise that can be gained only through hands-on experience, such as what to J

.
-
ld
o when a certain cryptic en'or m essage appears on the screen or how to handle the :
d' he most suitable'' programming i
,
1quirks of the compiler
.
ln brief, it would seem that t
language could only be COBOL- any other choice would be linancial suicide, either ':
.
from the viewpoint ol the costs involved or as a consequence of plum meting staff '
'
le leading to poor-quality code. l !mora
, r $i
itable programming language for QQQ Corporation's latest : l ' IAnd yet, the most su' l i i
project may indeed be some language other than COBOL. Notwithstanding its po- : ! . )i
.
'
sition as the world's most widely used programming language (see the Just in Case : ' 1I
You Wanted to Know box on page 436), COBOL is suited for only one class of soft- 1 j
' i has software 5 l 1ware products
, data-processing applications. But if QQQ Corporat on Ii
,
l .
needs outside this class, then COBOL rapidly loses its attractiveness. For example, j )
if QQQ wishes to construct a knowledge-based product using artilicial intelligence i !
: C
(Al) techniques, then an AI language such as Lisp could be used; COBOL is totally :
' I

unsuitable for AI applications. If large-scale comm unications software is to be built, I
perhaps because QQQ requires satellite links to hundreds of branch offices a1l over r '
the world, then a language such as Java would prove to be far more suitable than ! 1:
f iting systems software such as op- ' iCOBOL
.
If QQQ is to go into the business o wr j
erating systems, compilers, and linkers, then COBOL very delinitely is unsuitable. j!
' Corporation decides to go into defense contracting, management will IEAnd if QQQ
:1
.
soon discover that COBOL simply cannot be used for real-time embedded software. i
The issue of which programm ing language to use often can be decided by using
cost-benelit analysis (Section 5.2). That is, management must compute the dollar g
cost of an implementation in COBOL as well as the dollar benehts, present and j
( ! .future
, of using COBOL. This computation must be repeated for every language under j (
consideration. The language with the largest expected gain, that is, the difference j (I
between estimated benehts and estimated costs, is the appropriate implementation l i (
language. Another way Of deciding which programming language to select is to use ' 12 l
I : l I
risk analysis. For each language under consideration, a list is made of the potential : q .
7 ' Irisks and ways of resolving them. The language for which the overall risk is the : ! ,
'
I
smallest then is selected. ; ' '
.
!:è
.
:
!i

.
i
:
I
Please purchase Image To PDF Converter on to remove this message, thank you.
1 '
1
*a* t H A p # ; R '* @ Implemengolion Phose
1q
'
.
'
.
'
l
,
JusT IN G sz Yov W Axlzp To Kwow
Far more code has been written in COBOL than all Anotherreason forthe popularity of CoBol-aisthat
l other programming Ianguages put together. COBOL COBOL frequently is the best language tor implement-
l l is the most widely used langtlage primarily because ing a data-processing product
. In particular, COBOL'
,
1 j COBOL is a product of the U
.S. Department of De- generally is the language of choice when money is in-
k l
! fense (DoD). Developed under the direction of the late volved. Financial books have to balance, so roundingl f
OL was ap- errorscannot be allowedto creep in. Therefore, alI com-I Rear-Admiral Grace Murray Hopper, COB1
@ roved by DoD in 1 960
.
Thereafter. the DoD would not putations have to be performed using integerarithmetic.1 Pl

i t buy hardware for running data processing applications COBOL supports integer arithmetic on very Iarge num-l I unless that hardware had a COBOL compiler (Sammet
, bers (that is, billions of dollars). ln addition. COBOL
11 s
J 19781. DoD was, and still is. the world s largest pun can handle very small numbers. such as, fractions ofl
.
: chaser of computer hardware; and in the 1960s, a con- a cent. Banking regulations require interest computa-
l siderable proportion of DoD software was written for tions to be calculated to at least four decimal places of
t data processing. As a result, COBOL compilers were a cent. and COBOL can do this arithmetic with ease as'
' 1 Finally, COBOL probably has the best formatting,
.
written as a matter of urgency for virtually every com- we1 .
'
'
1 ter
. This widespread availability of COBOL, at a time sorting, and repol-t generation facilities of any third- 'j Pu
'
when the only alternative language usually was assem- generation language (or high-level language- see Sec-
bler, resulted in COBOL becoming the world's most tion 14.2). Al1 these reasons have made COBOL an .'
'( $ 1a1. programming language
. excellent choice for implementing a data-processing . '
'
l POPU$
.
i Languages such as C, C++, Java, and the 4GLs product.
1 undoubtedly are growing in popularity for new applica- As mentioned in Section 8.7.4, the upcoming
à
.
j tions. Nevertheless, maintenance still is the major soft- COBOL language standard is for an object-oriented
t ware activity, and this maintenance is being perforlued language. This standard surely will further boost the .'
:

.
r
l on existing COBOL software. In short, the DoD put popularity of COBOL.
1 its stamp onto the worldgs software via its hrst major
.1 programming language, COBOL.
!l
:
'
l:
.
1 .
I
.
i .
2 1
.
1 Currently, software organizations are under pressure to develop new software in .
! an object-oriented language any object-oriented language. The question that alises
i is this: Which is the appropriate object-oriented language? Twenty years ago, there '
i really was only one choice
,
smalltalk. Today, however, the majority of object-oriented1
software is being written in c++. There are a number of reasons for this. One is the1
.
widespread availability of C++ compilers. ln fact. many C+ + com pilers simply
,
1 translate the source code from C++ into C, then invoke the C eompiler. Therefore,
I any com puter with a C compiler essentially can handle C++ .
L1 But the real explanation for the popularity of C++ is its apparent similarity to
ujg C

.
This is unfortunate, in that a num ber of managers view C++ sim ply as a superset
.
k
1 of C and, therefore, conelude that any program mer who knows C can quickly pick
1 up the additional pieces
.
Indeed, from just a syntactical viewpoint, C++ essentially
.
'
i is a superset of C. After all, virtually any C program can be compiled using a C++
y compiler. Conceptually, however, C++ is totally different from C. C is a product efE
.
' ji
! l
:
l
I
!
Please purchase Image To PDF Converter on to remove this message, thank you.
2 t
,
j
'
(
'
FOURTH-GENERATION G NGUAGES *3F i :1*
.
% j ! .
I ;I

'
E
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''X
'
the structured paradigm, whereas C++ is for the object-oriented paradigm. Using j
C++ makes sense onlv if obiect-oriented techniques have been used and the product l
.
' '''' '-' '*
'
''
'
!
is organized around objects and classes, not modules. ;
Therefore, before an organization adopts C+ +. it is essential that the relevant
software professionals be trained in the object-oriented paradigm. It is particularly p
important that the information ot Chapter 7 be taught. Unless it is clear to all involved, j
and particularly to management, that the object-oriented paradigm is a different way ;!
of developing software and what the precise ditferences are, the structured paradigm
Ijust will continue to be used but with the code written in C++ rather than C
.
When j:
organizations are disappointed with the results of switching from C to C++. a major I 1
.
I
contributory factor is a lack of education in the object-oriented paradigm. 1:
Suppose that an organization decides to adopt Java. ln that case it is not possible 1'!
digm to the object-oriented paradigm. Java 1rto move gradually from the structured para
1.
:
is a pure object-oriented programming language; it does not support the functions and j

procedures of the structured paradigm. Unlike a hybrid object-oriented language such
as C++, Java programmers have to use the object-oriented paradigm (and only the
object-oriented paradigm) from the very beginning. Because of the necessity of an :
!
abrupt transition from the one paradigm to the other, education and training is even r
more important when adopting Java (or other pure object-oriented language such as :I i
Smalltalk) than if the organization were to switch to a hybrid object-oriented language . ! , 1
.
'
i llike C++ or OO
-
COBOL. Ii
'
.
W hat about im plem entation in a fourth-generation Ianguage? This issue is ad- I
1
dressed in the next section. ' l
.
; Ié
i . ji .
!
'
: l
.
.
l
-
1 II< 2 F@URTH-/ ENERATI@N N/UA/ES : 1 #
' 1 I
The first computers had neither interpreters nor compilers. They were programmed ) '

binary either hardwired with plug boards or by setting switches. Such a binary ' iin
, k!
machine code was a hrst-generation language. The second-generation languages ' j
'
l ywere assemblers
,
developed in the Iate 1940: and early l950s. Instead of having to : t; i
program in binary, instructions could be expressed in sym bolic notation such as ''
' j
lmov $1 7, next ë
1
In general, each assembler instruction is translated into one machine code instruction. 1
;
So. although assembler was easier to write than machine code and easier for m ainte- l
E
nance programmers to comprehend, the assembler source code was the same length i
as the machine code. ' l
The idea behind a third-generation Ianguage (or high-level language), such as C. I 1
: I
C++. Pascal, or Java, is that one statement of a high-level language is compiled to . I ë 1
: : Ias many as 5 or 10 machine code instructions (this is another example of abstraction'
,
. .
!
see Section 7.4. 1 ). High-level language code thus is considerably shorter than the : j
equivalent assembler code. lt is also simpler to understand and, therefore, easier to ( ,
: 1
! !
j '!
Please purchase Image To PDF Converter on to remove this message, thank you.

l
1 *aa e u . p . . . ,. . Implemenfokion phase '
I
1 .
l
'
j .
i
l zus' IN tAs: You w Axn p To Kxow
l
'
some years ago I hailed a cab outside Grand Central of New York City or the English language. As a re-
.
'
( station in New York City, and said to the driver, ''Please sult. I quickly replaced my nonprocedural request byi
ke me to Lincoln Centen'' This was a nonprocedural a procedural request of the form, ''Straight, straight. '1 j ta
! ) request because I expressed the desired result but left Take a right at the next light. I said right. Right, here,
' I it to the driver to decide how to achieve that result
.
yes, right! Now straight. Slow down, please. I said slowii
, s,
'
1 j lt turned out that the driver was an immigrant from down. For heaven s sake, slow down ! and so on, until( 1 Central Europe who had been in Ameri
ca Iess than two we finally reached Lincoln Center.
1 ! months and knew virtually nothing about the geography
l l
l
i
f :.
.

l
f maintain than assembler code. That the high-level Ianguage code may not be quite as
.
! efticient as the equivalent assembler code generally is a small price to pay for ease in
' m aintenance.
This concept was taken further in the late l970s. A major objective in the designof
'
1 h
-
generation language (4GL) is that each 4GL statement should be equivalent4 j afourt
l
.# 1 to 30, or even 50, machine code instructions. Products written in a 4G L such as Focus
J
,
) or Natural are shorter and hcnce quicker to dcvelop and easier to maintain.jj
j It is difficult to program in machine code. It is somewhat easier to program in
1 assembler. and easier still to use a high-level language. A seccmd major design objec-l
tive of a 4GL is ease in programming. In particular, many 4GLs are nonprocedaral1
) (see the Just in Case You wanted to Know box above for an insight into this term).i
: y' le consider the com mand shown in Figure 14
.1 . lt is up to the compiler ofOr examp ,r 1
J J the 4GL to translate this nonprocedural instruction into a sequence of machine code
I instructions that can be executed procedurally
.
.
I
! Success stories abound from organizations that have switched to a 4GL. A few
1 h t reviously used COBOL have reported a lo
-
fold increase in productivity through! t a p

1 use of a 4GL
. M any organizations have found that their productivity indeed increased' l
' j through use of a 4GL but not spectacularly so. Other organizations tried a 4GL and
' E
were bitterly disappointed with the results.l
. I , One reason for this inconsistency is that it is unlikely that one 4GL will be appro-
1
.
1 priate for a1l products. On the contrary, it is important to select the correct 4GL for the
'
j specific product. For example, Playtex used IBM 'S Application Developm ent Facility
(ADF) and reported an 80 to 1 produetivity increase over COBOL. Notwithstanding
t
.
2
Li lf rating ls excellent
1.
, odd 8500 to soloryj
i yl ue. ll
.
! xonprocedurali l 9
,
fourth-senerotion lansuoge.
!
(
1
1
l
j '
Please purchase Image To PDF Converter on to remove this message, thank you.

'
, 1
: C
'
ll*
.Q FOURTH-GENERATION LANGUAGES *3@ !
.
; 1i
1
br products deemed by ! ithis impressive result
,
Playtex subsequently used COBOL t
.
! ëman
agement to be less well suited to ADF (M artin, 1 9851 . ! l;
- i istent results is that many 4GLs are supported by ! 2A second reason tor these ncons
, 1
powerful CASE workbenches and environments (Section 5.5). CASE workbenches
. and environments can be both a strength and a weakness. As explained in Section i
I2
. 1 l , it is inadvisable to introduce large-scale CASE within an organization with a low I
maturity level. The reason is that the purpose of a CASE workbench or environment ,
is to surmort the software orocess. An oruanization at level l does not have a software l'
'' '''
.
* h''''
. r l i
process in place. It at this point CASE is introduced as part of the transition to a 4GL, 'j
; this will impose a process onto an organization not ready for any sort of process. J
.

: j .,The usual consequences at best are unsatisfactory and can be disastrous
. ln fact, a
numberof reoorted 4GL failures can be ascribed to the etfects of the associated CASE l
1
*
.
'':
'
'
'
p
'
:.
.
environment rather than to the 4GL itself. 11
The attitudes of 43 organizations to 4GLs is reported in gGuimaraes, 1 9851. It : l
:
Ii
: was found that use of a 4GL reduced user frustration because the data-processing y l
li
' depaftment could respond more quickly when a user needed inform ation extracted :
, from the organization's database. However, there also were a number of problems. !
1
Some 4GLs proved to be slow and inefticient, with long response times. One product j
consumed 60 percentof the CPU cycles on an lBM 433 l mainframe, while supporting, . ;'
!
at m ost, 12 concurrent users. Overall, the 28 organizations that had been using a 4GL ë
ifor over 3 years felt that the benefits outweighed the costs
.
j. ''' '''''''' . k

'
No one 4GL dom inates the software market. lnstead. there are hundreds of 4G Ls', , l
some ot them , including DB2, Oracle, and PowerBuilder, have sizable user groups. : j
.
j IThis widespread proliferation of 4GLs is further evidence that care has to be taken in
,
j
selecting the correct 4GL. Of course, few organizations can afford to support more 1
l
than one 4GL. O nce a 4GL has been chosen and used, the organization must either l
use that 4G L for subsequent products or fall back on the Ianguage used before the I
4GL was introduced. ; 1
i 1
Notwithstanding the potential productivity gain, there is potential danger in us- ! 1.
ing a 4GL the wrong way. M any organizations currently have a large backlog of 1.
. I :
roducts to be developed and a long list of maintenance tasks to be performed. A IP
Id
esign objective of many 4GLs is end-user programming, that is, programming by I
the person who will use the product. For example, betore the advent of 4GLs, the !
investment manager of an insurance company would ask the data-processin: manager l'
'''-'' ''' ''
'
'
'' ''''' ''''' j
: for a product that would display certain information regarding the bond portfolio. The j :' investment manager then would wait a year or so for the data-processing group to
.
j 'find the tim e to develop the product
. A 4GL was desired that would be so simple to l
use that the investment manager, previously untrained in programm ing, could write i

.
; Ithe desired product unaided
. End-user program ming was intended to help reduce the
development backlog, leaving the professionals to maintain existing products. i@
iln practice
,
end-user programming can be dangerous. First, consider the situation ( ;
when all product developm ent is performed by computer professionals. Com puter ;
.
i
q rofessionals are trained to m istrust com puter output. A fter all, probably less than l i
:
' lP
l9
.
! j '
percent of all output durinc product development is correct. On the other hand, the l
.
'''' '''' 'i''''''' ''''
'
'
* ; j
user is told to trust all com puter output, because no product should be delivered to ,!
1
'
' g
Please purchase Image To PDF Converter on to remove this message, thank you.
j
I .
i

1
I **@ t M A p T : R 14 * Implemenlofion Phosei
i
! the user until it is fault free
.
Now consider the situation when end-user programming1
is encouraged. w hen a user who is inexperienced in programming writes code with a. 1
t user-friendlys nonprocedural 4GL, the natural tendency is for that user to believe the
i output
. After all, tbr years the user has been instructed to trust com puter output. As '
.
' ( a result, many business decisions have been based on data generated by hopelessly
1 ! incorrect end-user code
.
ln some cases the user-triendliness ot certain 4GLs has led1
t to finaneial eatastrophes
.
iil Another potential danger Iies in the tendency
,
in some organizations, to allow
( 1 , - .
) j users to write 4GL products that update the organization s database. A programming
l error made by a user eventually may result in the corruption of the entire database.1
i 1l Th
e lesson is clear: Programming by inexperienced or inadequately trained users can
.
1
j be exceedingly dangerous, if not fatal, to the hnancial health of a corporation.
l n e ultimate choice of a4GL is made by management
.

In making such adecision,l
'
! management should be guided by the m any success stories resulting from the use of a ) .
1 4GL. At the same time, management should carefully analyze the failures caused by
l l using an inappropriate 4GL
,
by premature introduction of a CASE environment. or .
1
'! by poor management of the development process. For example, a common cause of
l failure is neglecting totrain the developmentteam thoroughly in all aspects of the4GL
,
'
including relational database theory rDate, l 9991 where appropriate. M anagement
'
should study both the successes and failures in the specific application area and leam
:1 1
! j from past mistakes. Choosing the correct 4GL can mean the difference between a
1
.
j major success and dismal failure.1
j Having decided on the implementation language, the next issue is how software
I engineering principles can lead to better-quality code.'
1 l
.
'
i
)
i
'
j i

!1
I
'
,
lA a G oop PRO/RAM M IN/ PU W ItK
2
'
j
l Many recomm endations on good coding style are Ianguage specitic
. Forexample. sug-!
lj gestions regarding use of COBOL 88
-
Ievel entries or parentheses in Lisp are of little
: j .i
nterest to programmers implementing a product in Java. The reader actively involved
! 'j in implementation is urged to read one of the many books
, such as those by Henry1
- :
j Ledgard, on good programming practice for the specific language in which the prod-
j uct is being implemented. Some recommendations regarding language-independent .)
: good programming practice are now given

j
' ?se ol tonsls:ex: oxd M eonlnglul Ve IobIe Nom es As statedinchap-
ter 1 , on average two-thirds of a software budget is devoted to maintenance. This1 implies that the programmer developing a module is merely the hrst of many who
.
I'J
l will work on that module
. It is counterproductive for a programmer to give names tof
) variables that are meaningful to only that programmer', within the context of software

ji j engineering, the term meaningjlll means é'meaningful from the viewpoint of future
'
1 5 !'j ' maintenance programmers. This point is in the Just in Case You Wanted to Know
i Box on page 44 l .
l .
t'
j
!
Please purchase Image To PDF Converter on to remove this message, thank you.
' j!
1
.
1
!
A*.a GooD PROGRAMMING PRM TICE **1 lI
i r
iJusT IN G sz You W ANTKP To KNow l
E :
In the Iate 1 970s, a small software organization in meaningful as they were to Portuguese speakerss were
Johannesburg, South Africa, consisted of two program- incomprehensible to the Israelis, whose linguistic abil- ( !
ming teams. Team A was made up of émigrés from ities were restricted to Hebrew and English. The 7 I
.
- - '
j I
Mozambique. They were ot Portuguese extraction, and owner of the software organization was unable to hire i.j
heir native language was Portuguese. Their code was enough Portuguese-speaking programmers to replace 1)t
lwell written
.
Variable names were meaningful but un- team A, and the company soon went into bankruptcy. l
fortunately only to a speaker of Portuguese. Team B under the weight of numerous Iawsuits from dis- j j

comprised lsraeli immigrants whose native language gruntled customers whose code was now essentially : 1'.
I
.
was Hebrew. Their code was equally well written, and unmaintainable. j:
the names they chose for their variables were equally The situation could have been avoided easily. The 1E
ly to a speaker of Hebrew. head of the company should have insisted from the 1meaningful- but on
11One day
,
team A resigned en masse, together with start that a1I variable names be in English, the language l
its team Ieader. Team B was totally unable to maintain understood by every South African computer profes- i
any of the excellent code that team A had written, sional. Variable names then would have been meaning- 1
.
because they spoke no Portuguese. The variable names, ful to any maintenance programmer. : ,
.
! i
,
: ë
l l
1 . l
.
1 jIn addition to the use ot meaningful variable names
, it is equally essential that .
. ;
variable names be consistent. Forexample, the following four variables are declared in j'
a module: averageFreq, frequencyMaximum, minFr, and frqncyTotl. A maintenance ij
ho is trying to understand the code has to know if freq, frequency, fr, 1 1programmer w
land frqncy alI refer to the same thing
. lf yes. then the identical word should be used, ( i !
ferably frequency, although freq or frqncy is marginally acceptable', fr is not. But i ipre l l
if one or more variable names refer to a different quantity. then a totally different . !

'
ë
name, such as rate, should be used. Conversely, do not use two different names to ' ;
denote the identical concept; for example, both average and mean should not be used
in the same program. j
A second aspect of consistency is the ordering of the components of variable 1
j .
names. For example, if one variable is named (requencyMoximum, then the name !
inimumFrequency would be confusing; it should be frequencyMinimum. To make 1m
1
the code clear and unambiguous for future maintenance programmers, the four vari-
:
'
ables listed previously should be named frequencyAverage, frequencyMaximum,
:
frequencyMinimum, and frequencylbtal, respectively. Alternatively, the frequency '
component can appear at the end of all four variable names, yielding the variable
names averageFrequency, maximumFrequency, minimumFrequency, and totalFre-
quency. It clearly does not matter which of the two sets is chosen; what is important I ,
is that all the nam es be from the one set or from the other. i 1
! iA number of different naming conventions have been put forward that are in
- . :
I
'
, 1tended to make it easier to understand the code
. The idea is that the name of a variable ! : j
Ch'l'm miVht denote a tem- ' lshould incorporate type information
. For example, ptr p : r
orary variable (Tmp) of type pointer (ptr) to a character (Ch). The best known of iP
;

such schemes are the Hungarian Naming Conventions (Klunder, 19881. (lf you want i !i
:
i'
j .
Please purchase Image To PDF Converter on to remove this message, thank you.
f
'j!
l a t u .p v . . ,. . Implemen,o'ion phose
l
'
C
l to know why they are called Hungarian. see the Jtlst in Case You Wanted to Know
7 box belom ) One drawback of many of such schemes is that the effectiveness of code
t
inspections (Section 14.9) can be reduced when participants are unable to pronounce
the names of variables. It is extremely frustrating to have to spell out variable names,
@
'
letter by letter. .
i
J
l Th@ Issue *1 Sell-polgm en:lng tlde W hen asked why theircode contains
i h t
soeveq programmers often proudly reply. 'çl write self-documentingI nocomments w a
i ,,
.1 code. The implication is that their variable names are chosen so carefully and their
j '
j code crafted so exquisitely that there is no need for comments. Self-documenting
l code does exist, but it is exceedingly rare. Instead. the usual scenario is that the pro-I
! grammer appreciates every nuance of the code at the time the module is written. It

j is conceivable that the programmer uses the same style for every module and that, in
jf 5 years' time, the code still will be crystal clear in every respect to the original pro-
I grammer. Unfortunately, this is irrelevant. The important point is whether the module
l can be understood easily and unambiguously by all the other programmers who have
l
to read the code, starting with the software quality assurance group and including a
number of different m aintenance programmers. The problem becom es more acute in
J the light of the unfortunate practice of assigning maintenance tasks to inexperienced
programmers and not supervising them closely. The undocumented code of the mod-
ule may be only partially comprehensible to an experienced program m er. How much '
worse, then, is the situation when the maintenance programmer is inexperienced.
To see the sort of problems that can arise, consider the variable xcoordinote-
OfpositionofRobotArm. Such a variable name undoubtedly is self-documenting inl
few programmers are prepared to use a 3 I -characterevery sense of the word, but1
variable name, especially if that name is used frequently. Instead, a shorter name is .
.
1
'! used, xcoord, forexample. The reasoning behind this is that if the entire module deals
'
.
i with the movement of the arm of a robot, xcoord can refer only to the v coordinate
:. l
', of the position of the arm of the robot. Although that argument holds water within
,1 the context of the development process, it is not necessarily true for maintenance.
The maintenance programmer may not have sufheient knowledge ot the product as al
i whole to realize that, within this module, xcoord refers to the arm of the robot or may
'i not have the necessary documentation to understand the workings of the module
. The
i
è'l way to avoid this sort of problem is to insist that every variable name be explained at

(.
the beginning of the m odule, in the prologue com ments. lf this rule is followed, the
JusT IN G s. You W ANTZP To KNow :
There are two explanations for the term Hungarian to the conventions are about as easy to read as Hun-
Naming Conventions. First. the conventions were garian. Neverthelesss organizations (such as Microsoft)
invented by Charles Simonvi, who was born in that use them claim that they enhance code readability
; '' -j Hungary
. Second, it generally is agreed that, to the tor those with experience in the Hungarian Naming
1 uninitiated, programs with variable names conforming Conventions.
11
*
.
*
7
Please purchase Image To PDF Converter on to remove this message, thank you.
I )
I l
:
l
g
:
w a GooD PROORAMMING PRAETIEE **a '
.
1
'
maintenance programmer quickly will understand that variable xcoord is used for i
'
h oordinate of the position of the robot arm. i
.:
t e x c

' Prologue comments are mandatory in every single module. The minim um infor- !
'
; '
'r mation that m ust be provided at the top of every module is the module name; a brief ;
14 description Of what the module does', the programmer's name, the date the module l '
:
.
was coded, the date the module was approved and by whom', the module arguments; j'
I der and their uses', the names l.tka list of variable namesa preferably in alphabetica or , ,
'
d b this module, if any; the names of files changed by this module. l lof hles accesse y
1:î
: ' lities', the name of the : l )if any; module input
-
output, if any, the error-handling capabi j
file containing test data. to be used later for regression testing', a list of modifications 1:
. , l
.
made, their dates, and who approved them; and known faults, if any. q
l
. Even if a module is clearly written, it is unreasonable to expeet som eone to have I
to read evel'y line to understand what the module does and how it does it. Prologue p I'
I
.'
comments make it easy for others to understand the key points. Only a member of t
t -' l .
the SQA group or a maintenance programmer modifying a specitic module should be r l
: !
expected to have to read every line of that module.
ln addition to prologue comments, inline comments should be inserted into the j

code to assist maintenance programmers in understanding that code. It has been II l
suggested that inline eomm ents should be used only when the eode is written in a ) ;
!
nonobvious way or uses som e subtle aspect of the language. On the contrary. con-
)fusin
g code should be rewritten in a clearer way. lnline comments are a means of T i
helping maintenance programmers and should not be used to promote or excuse poor :
Iprogram m ing practice
.
; ;U
se .1 Plelm e'ers There are very few genuine constants, that is, variables j
hose values will never change. For instanee, satellite photographs have eaused (W
l
changes to be made in submarine navigation systems incorporating the latitude and F
longitude of Pearl Harbor, Hawaii, to retlect m ore accurate geographic data regarding
'
the exact location of Pearl Harbor. To take another example, sales tax is not a genuine i '
'
t' legislators tend to change the sales tax rate from time to time. Suppose that j #: constan ,the sales tax rate currently is 6
.0 percent. If the value 8.0 has been hard coded in a jj '
number of modules of a product, then changinj the product is a major exercise, with lt(
'' tant'' 8 O being overlooked .1.
the likely outcom e of one or two instanees ot the cons . j
; and, perhaps, changing an unrelated 6.0 by mistake. A better solution is a C++ I
.
'
'' - -'''' - p
declaration such as j,
.
1 'tonst floo' salesTaxRate = 6

.
Q; ,
.
I :
j'or
,
in Java. j
1:publk sMtk finol flool salesTaxRate
=
(fIoc#) 8.0,.
1
Then wherever the value of the sales tax rate is needed, the constant saleslbxRate : i i
,
5 ' : .
) should be used and not the number 8.0. lf the sales tax rate changes, then only the line t (
: ! El containing the value of salesTaxRate need be altered using an editor
.
Better still, the ;
,i
. .
.
j j
value of the sales tax rate should be read in from a parameter file at the beginning of ' ,
'
the run. All such apparent constants should be treated as parameters. lf a value should ; '
- ;
; change for any reason, this change can then be implemented quickly and effectively. :
I
1
e

l k -
Please purchase Image To PDF Converter on to remove this message, thank you.
2
.
*** t H A p T : R 44 @ lm plem enko#ion Phase
t
.
tod. koyou: f@e Inlrees@d Reedebllla It is relatively simple to make a
.
module easy to read. For exam ple, no more than one statement should appear on a
.
line, even though many program ming languages permit more than one
. lndentation
is perhaps the most im portant technique for increasing readability
. Just imagine how .
difficult it would be to read the code examples in Chapter 7 if indentation had not beenl
.
l used to assist in understanding the code. ln C++ or Java, indentation can be used to .1
k1 I connect corresponding (
. . .
J pairs. lt also shows which statements belong in a giveni I
block. In fact, correct indentation is too important to be left to hum an beings
.
lnstead,1
l as described in Section 5.6, CASE tools should be used to ensure that indentation is
I done correctly
.l '
I Another useful aid is blank lines. M ethods should be separated by blank lines;
l in addition
,

it often is helpful to break up large blocks of code with blank lines. The
extra ''white space'' makes the code easier to read and, hence, com prehend.
i
1
t N@*@d if $:œ:@m@nH Consider the following example. A map consists of twol
kj squares, as shown in Figure 14.2. It is required to write code to determine whether a'
J point on the earth's surface lies in map square 1 or map square 2, or is not on the
.
'
map at all. The solution of Figure 14.3 is so badly formatted that it is incomprehen- '
$ sible. A properly formatted version appears in Figure 14.4. Notwithstanding this, the
'
,
l ( combination of if-if and if-else-if constnlcts is so complex that it is difficult to checki
l hether the code fragment is correct. This is fixed in Figure 14
.
5.WJ
,' W hen faced with complex code containing the if-il construct, one way to simplify'!
,
. it is to use the fact that the if-if combination
.
kj vcondition j >
:1
! I if <condition 27-!
t '
' ! I
j is equivalent to the single conditionl
i I
: i if <condition 1 > ond <condition 27.
:7

11
1!
1
E
; .
i
1 o
I 90I
map
.
t squars
r
2
1 jatitude 60 O
maP
Square
'
1
'
30O
)'
j 4I
.
i ' o o oj 9oo 12O 150 180
j Iongitude
i
I ylsuee 4- a coordinates for map
.
I
Please purchase Image To PDF Converter on to remove this message, thank you.