Software Engineering (phần 5) pdf

.
j 1:
**************************************************************************************************
'
j . , .Ji t ' .
'
'
l i! 1 'j g E., .
p
'
' ' Ilo t u A p T : p l . TeskingE
(
j l ; ; peer at the screen and say, <ûI guess that looks right.'' Equally futile is for the tester toI
: '
t à ; plan test cases with great care, execute each test case in turn, look at the output, and1
i ! ! EEàres that certainly looks right
.'' It is far too easy to be fooled by plausible results.l j say, ,;
'
!I
: i E If programmers are allowed to test their own code
,
then there always is the danger .1 .l l ! l
: tlaat the programmer will see what he or she wants to see. The same danger can occur 'j ; ! j j
' 2 1 1 : 1 even when the testing is done by someone else
. The solution is for m anagement to k
i i '! ! j ' ' .
j : ( : insist that, before a test is performed, both the test data and the expected results of '( @ l
l j : j that test be recorded. After the test has been performed, the actual results should be
l i : 1 recorded and compared with the expected results
.
I I l !

, ! ! '
, Even in sm all organizations and with small products, it is important that thisl
l I l : - . .j 1 ! ' . j recording be done in machine-readable form
,
because test cases should never be
! : @ 1
.
! j thrown away. The reason for this is maintenance. W hile the product is being main- .I 1 I
,I
j . tained, regression testing must be performed. stored test cases that the product hasj ( j , i : 1 previously executed correetly must be rerun to ensure that the moditications made :
: ! ; I ' y
'
j r . . to add new functionality to the product have not destroyed the product s existing
1 ) functionality
. This is discussed further in Chapter l6.i
;
ll
j . i ( .i i
I
i
!
.
I E - . ;
.
( ; , '
li '-,
'
,
'
!jj r

'
:.
,
'
.
'
.
'
l i l y u,x n sylxo svops
j ' , *'j : : . g
.
1 1 l After a product has been successfully maintained for many years
,
it eventually mayl
.
. !I . !
1 l 4 I lose its usefulness and be superseded by a totally different product, in much the same
! t : E i ,
; ! . ë j w ay that electronic valves were replaced by transistors. Alternatively, a product still
l l l ) 1 j 1 may be useful, but the cost of porting it to new hardware or running it under a new
ii j i :! i
operating system may be larger than the cost of constnlcting a new product, using! ' l 1 '
. 1 1 the old one as a prototype
. so, tinally, the software product is decommissioned andI ( . .
!
-
l( I removed from service
. Only at that point, when the software has been irrevocably: i
! I
l ! discarded, is it time to stop testing.i ! l .

2 @ i .j j j I Now that a1l the necessary background material has been covered
,
objects can be.
1 . .l
k E I examined in greater detail. This is the subject of the next chapter.
, ,
1 : i i
(
'
i ! I I ' .
l 1 ' i ;!
'
) : .qj' ! ë
.T :
'
! '1 ë
:
I -
i '
. 1 tHA- ER Rzvlzw
1 . ' .(
'
-
(
'
i ; 1 A key them e of this chapter is that testing must be carried out in parallel with all '
k j ' . : t .! ' activities of the software process
.
The chapter begins with a description of quality j: .li :
f . l ( r ; issues (Section 6. 1). Next, nonexecution-based testing is described (Section 6.2), with j'

: a careful discussion of walkthroughs and inspections. This is followed by a defini- j1 1 -
.
! . j tion of execution-based testing (Sections 6.3 and 6.4) and a discussion of behavioral
' '
roperties of a product that must be tested, including utility, reliability, robustness, ëj P
E ! rform ance
,
and correctness (sections 6.4.1 through 6.4.5). In section 6.5, correct- I. pej i
7 y ' !l l
l , I !
j ' lI
I i
'
!i i i
2
Please purchase Image To PDF Converter on to remove this message, thank you.
!
.
l
F
2
FoR FURTHER READING X@1 ',
E) ness proving is introduced and an example of such a proof is given in Section 6.5.1.
:1 The role of correctness proofs in software engineering then is analyzed (Sections 6.5.2 :
I
;. and 6.5.3). Another important issue is that systematic execution-based testing must
T be performed by the independent SQA group and not by the programmer (Section I
Lr 6.6). Finally, the issue of when testing can linally stop is discussed in Section 6.7.
o
k

f
e
S FoR FURTHZR REAPINI
e :
i- The attitude of software producers to the testing process has changed over the years, '
S from viewing testing as a means of showing that a product runs correctly to the modern l
e
.
attitude that testing should be used to prevent requirem ent, specilication, design, and '
# ' implementation faults.
This progression is described in gGelperin and Hetzel, 19881.
'
The nature of software testing and the reasons why it is so hard are discussed in C
) lgWhitt
aker, 20001. : j
The Januarv 1996 issue of IEEE Software contains a number of articles on soft-
'
*''
'
'' 1
warequality, including (Tevonen, 19961. The November l 996 issue of IEEE Computer !
- also has articles on software quality. Yet another series of articles on software quality l
!
is in the June 1997 issue of the Communications ofthe ACM. Of particular interest are '
(Herbsleb et al., l 9971, which describes the effect on software quality of improving
y the software process, and gArthur, 19971, a description of how total quality manage- ;
e ment was used to improve software quality within M cDonnell-Douglas. A different
11 approach to achieving quality is described in gonoma and Yamaura
, 19951. A way :
& of assessing the overall quality of a software product is described in gBoloix and

g Robillard, 19951. M yths regarding software quality are discussed in gvoas, 19991.
d Reliability is discussed in a set of articles in the May 1995 issue of IEEE Software.
y ' B ber 19871 is a good introduction to proving programs correct. One of the stan- ig a , j!
.
i dard techniques of correctness proving is using so-called Hoare logic, as described in : !
'
e gl-loare, 1969J. An alternative approach to ensuring that products satisfy their speci-
hcations is to construct the product stepwise, checking that each step preserves cor-
rectness. This is described in gDijkstra, 1968a, and Wirth, 1 97 l 1. An important article
regarding acceptance of correctness proofs by the software engineering comm unity
is gDeMillo, Lipton, and Perlis, 19791 . : .
-
The IEEE 4sstandard for Software Reviews'' (IEEE 1028, 19971 is an excellent E ë
source of information on nonexecution-based testing. A paper on how to conduct 1
linspections as well as theireffectiveness is (Ackerman
, Buchwald, and Lewski, 19891. 2
11 Inspection of a very large software product (2.5 million lines of code) is described jl
in gRussell, 19911. Other sources of information on experience with inspections are '!y
h gDoolan, 1992, and Weller, 19931. Cost issues, such as reducing the size of a team and . l
! !:
- minimizing the time lost while waiting for reviewers to meet, are described in gvolta, 2
tl 19931. An experiment evaluating the costs and benefits of inspecting a large-scale ;(
'
.
;, software product is described in (Porter, Siy, Toman, and Votta, l 9971. A variety of I
2- useful papers on inspections appears in gW heeler, Brykczynski, and M eeson, 19961. 1
' j(
.
l
1 z

: 1
Please purchase Image To PDF Converter on to remove this message, thank you.
'
I 1
( j 1 ' .l ' l ;
: j j ' ' )
'
.
1 1. - ' :
'
' ' i 1l2 t u A p . : w l . Tesding
I I :
'
: I l
1 Possible future developments in the area of inspections are put forward in (Johnson, bl!
. ;1 ë . 19984. s.1
.
j é , r j jI ; ; The classic work on execution-based testing is (Myers, 19791, a work that has pl1
j .
I ! ; ' had a signihcant impaet on the seld of testing
.
kDeMillo, Lipton, and Sayward, 19781 l g AI i ' .
t ' 1 : remains an excellent source of information on selection of test data
.
(Beizer, 19901 is ntjll !! . 11.
*
i
'
1
,j j : ; a compendium on testing, a true handbook on the subject. A similar work is gHetzel, ctl

.
.
î 1 1988j
.
,
l
, t l pt
' I ' @ : Turning specihcally to the object-oriented paradigm, the September 1994 issue of '' !
!
1 1 ! 1 *.@ YtI j j Communications ofthe ACM contains a number of articles on testing object-oriented
'
:
t i i I 21 :7 software. (Kung, Hsia, and Gao, 19981 is a book on object-oriented testing, and so is , 01:1 $ j so1
:
(Sykes and McGregor, 20001. '
. I i I , i so
j l ! . The May 1989 issue of IEEE Software has a wide variety of papers on testing
1 ; issues
.
Both execution-based and nonexecution-based testing are covered. The pro- **1P %i
'
; 1 i(
j E ' à ceedings of the lnternational Symposium on Software Testing and Analysis cover a .
T i ' .
) : ! similar broad spectrum of testing issues
.
The April 1997 issue of Communications of .j !
.
j j ', the ACM is devoted to debugging.
. ! js!

'
It ,
j 5 @. j j AjI i
. r :i ; '
:
in,' j
1 ) sjli
.
J .(
'
'
i ; i pposkgm s *.12 C(!
: .i
.
'
! :
g
'
.
: '
p
'
I : ) 'j 6.1 How are the terms correctnessproving, ver/cation, and validation used in this book?11 l
.
' l 6 Q A software development organization currently employs 83 software professionals
,
I1 !
.
è *'
l ' ' including 17 managers

, a1l of whom do development as well as verihcation andI - 1 ! 1
-! ' lidation of software
. Latest figures show that 28 percent of their time is spent on; I : va
i 1 l 1 verification and validation
. The average annual cost to the company of a manager is
! I ! 1
1 l ! j : $140,000, whereas nonmanagerial professionals cost $104,000 ayearon average; both' ' 1 !
i j . I ; figures include overhead. Use cost-benefit analysis to determine whethcr a separate ,
'
t ï! i i SQA group should be set up within the organization
.pl : . I pr
il i l 'r l.a Repeat the cost-benefit analysis of Problem 6
.2 for a firm with only seven soft- l
.
1a clI j j l .1 ,1 ; 7 ware professionals
,
including two managers. Assume that the other figures remain m ;
.
1l
1 unchanged. ,l i . 1
.1* I!4' ! l 1
: p -l : ' f
.4 You have been testing a module for 1 1 days and found two faults. W hat does this tell pr.i ;1
.
j ! ; ! you about the existence of other faults? l ! s D(t ;
:
*
! ') ô
.s w hat are the similarities between a walkthrough and an inspection? W hat are the US!
: '' ! differences? . th1

,
faIt
$ , I . ô.l You are a member of the SQA group at Ye Olde Fashioned Software. You suggest to . sul I i !
your manager that inspections be introduced. He responds that he sees no reason why
or1 ; - i'
j four people should waste their time looking for faults when one person can run test ti
.
yl! ! 1 cases on the same piece of cod
e. How do you respond?! 4 '
,
.
h w., 6 (-rt i '
r + y You are the sQA manager at Tex's Taxes, a tax preparation franchise with 154 fuj j *
l 1 i . l
; , branches, all in Texas and Tennessee. The owners of the franchise are considering AI'
j ; r
' I
; 1
.
! .
j 2 J
Please purchase Image To PDF Converter on to remove this message, thank you.
( '
i !
I '
PROBLEM: %*a ' è
. r
'
:
'

i
3n, ' buying a new type of tax preparation package for use throughout the organization. g '
' Before authorizing the purchase of the package, you decide to test it thoroughly. W hat : 7
'
roperties of the package do you investigate? Izas p
i '781
.
ô.g All 154 branches of Tex's Taxes are now to be connected by a communications i '
1 is network. A sales representative offers you a 4-week free trial to experiment with the ':
rel, communications package he is trying to sell
. W hat sort of software tests would you
.
perform and why? .
, of .:
.
9 You are a vice-admiral of the Navy of the Republic of Claremont in charge of devel-
ted i the software for controlling the new ship
-
to-ship missile (Problem l .3). The. op ng
7 iS has been delivered to you for acceptance testing
. W hat properties of thesoftware
software do you test? .
ing &1Q Wh
at happens to the correctness proof of Section 6.5. l if loop invariant
ro-
i
s = y!O) + yl 1 ) + . . . + y(k - 1 ) !r of
1i
s used instead of (6.4)? 2
é.1 1 Assume that you have some experience with loop invariants and that you know that '

;
' invariant (6.4) is the correct invariant for the loop of Figure 6.6. Show that output
specification (6.3) is a natural consequence of the Ioop invariant. ;
:.12 Consider the following code fragment: '
'
Ik
=
Q,. I
)k? ' !
g = 1 ; :
àls, while (k < n)
tll (1 ( ii
on , k = k + 1 ; !
r is = g + k. : '9 ' I
h !Ot
I
l ! l
'ate Ii I
I
t prove that this code fragment correctly computes g = n! if n is a positive integer.
aft- é 1a can correctness proving solve the problem that the product as delivered to the client*
ain : ' t be what the client really needs? Give reasons for your answer
.
.
may no
:.14 How should Dijkstra's statement (Section 6.3) be changed to apply to correctness
tell proofs rather than testing? Bear in mind the case study of Section 6.5.2.
é.15 Design and implement a solution to the Naur text-processing problem (Section 6.5.2) è
) using the language specihed by your instructor. Execute it against test data and recordthe !
the number of faults you tind and the cause of each fault (e.g., logic fault, loop counter 11

fault). Do notcorrect any of the faults you detect. Now exchange products with a fellow :
t to : student and see how many faults each of you finds in the other's product and whether I
/hy ' he are new faults
.
Again record the cause of each fault and compare the fault 'or not t y
Eest found by each of you
.
Tabulate the results for the class as a whole. ). types
.
;é
.
1é (Term Project) Explain how you would test the utility, reliability, robustness, per- :
L54 formance, and correctness of the Broadlands Area Children's Hospital product in i 1'
i !i
ng Appendix A. ! iI
.
'
k :
I
J 1
i
!
Please purchase Image To PDF Converter on to remove this message, thank you.
; ë I ;i :
.
:
I ' i 1, : . 1 .'
:
t 1 E l ( .'
l I t ' . j .'

.
1l* t u A p T . R l . Tesging1

)
'
' ! .2 '
i '
! ! i y
.
j ! ' ' f.1 7 (Readings in Software Engineering) Your instructor will distribute copies of gWhit- 1
! ) taker, 20001. Brooks (Section 2.9) considers four difficulties of software to be essen- ,I
. . .
I I tially hard. Do you consider testing to be essentially hard or accidentally hard? I1 I
; : i (
k j 1 .
t
,
( k j 1 l '!
l ; I - , é 1)
T ; I :i q i i
; '
t 9 I ' : t! l l Ruyzu xtzs ,
: l l .
.
l II
: I 1 2
'
1 j (Ackerman, Buchwalds and Lewski, 19891 A. F. ACKERMAN, L. S. BucHwALo. ANn ,l
1 I i F
.

H. LEwsltls t'Software Inspections: An Effective Verification Process,'' IEEE Sojtware j. I
'
I I 1
. q 6 (May 1989), pp. 31-36. t (
i j ' j (Arthur, 19971 L. J. ARTHUR. çtouantum lmprovements in Software System Quality,''E ! j i
F Communications of the ACM 40 (June 1997), pp. 46-52.l ;
; : )
'
! r j ! gBaber, l 9871 R. L. BABER. The Spine ofsohware: Designing Provably Correct Software: (
1 l . j Theoty and Practice, John Wiley and Sons, New York, l 987. (: é
1 1 gBeizer
,
1 9901 B. BEIZER, Software Testing Techniques, 2nd ed., Van Nostrand Reinhold, (1, :l
41 : 1 New York, 1990.
' ; ' y <i l ! ! . gBel'ry and W ing
.
l 9851 D. M. BERRY AND J. M. WING, Specifying and Prototyping: Some , lik j ' .
(.I J i '
. !
Thoughts on Why They Are Successful,'' in: Formal Methods and Software
1 l h Developmentb Proceedings ofthe lnternational Joint Conference on W/lcory and Practice E1:
.
'
j . k ' ofsoftware Development, Volume 2, Springer-verlag, Berlin, 1 985. pp. 1 l 7-28. ;
E ' i ' ' ; B hm l 984a1 B
.
W. BOBHM, çtverifying and Validating Software Requirements and Design (1. , r oe .è
'
'
1

''
'
'
r
1 : 1 ' i specificationss'' IEEE Sopware 1 (January 1 984), pp. 75-88. 'I l
,
( ' -
qqlj I , r , i (Boloix and Robillard. 19951 G. Bot-olx Axo R N. Rosll-l-xRo, A software system
. (Jl
l . 1 Evaluation Framework
,
'' IEEE computer 28 (December 1995), pp. 17-26.l l I : 1
j j l 1 j (Bush, l 990j M. BUSHS ttlmproving Software Quality: The Use of Formal lnspections at the ' (2l 1
i .,l
; j I i Jet Propulsion Laboratory, Proceedings ofthe 12th International Conference on
i 1 l Software Engineering, Nice, France, March I 990, pp.
1 9* 99. 11I
j '
'
! r (DeMillo, Lipton, and Perlis. 19791 R. A. DEMII-LO, R. J. LlpvroN, ANI) A. J. PERLIS
, 'tsocial
l i t l ! prooesses and Proofs of Theor
ems and Programs,'' Communications of llle ACM 22'; I 1 1 t l
i j 1
:
i
j (May l 979), pp. 27 1-80. (1i !
I (DeMillo, Lipton, and Sayward, l 9781 R. A. DEM ILLO, R. J. LlpTox, AND F. G. SAYwARD,' ! ?
'
: l

çKl-lints on Test Data Selection: Help for the Practicing Programmer,'' IEEE Computer 11 El;1 1 ' , t
j t 1 s (April 19,78)- pp. 34 43.1
, ' jt p 2 p goijkstra
,
19681 E. W. DIJKSTRA. G'A Constructive Approach to the Problem of Program (1
' p p ! ' colvectness
.
'' B11- 8 (No. 3. 1968), pp. 174-86. )l ;
.
1 ; (
'
1 ê ' g tDijkstra, 19721 E. W. DIJKSTRA. ''The Humble Programmer,'' Communications of the ACM (1l ! :
1 15 (October l 972), pp. 859-66.1
' : l
, ,,j j r , fDoolan, 19921 E. P. DooLAx. Experience with Fagan s Inspection Method,
! ! ' ; Sopware- practice and Experience 22 (Febrtlary l 992). pp. l 73-82. (hq ' '
ij ! . gFagan, 19761 M. E. FAGAN, 'resign and Code Inspections to Reduce Errors in Program
! 5 ,,
I ! ' 1 . Development, IBM Systems Journal 15 (No. 3, l 976), pp. 182-21 1. . IA
E , ; ,,
; ( ; (Fagan, 1 9861 M. E. FAGAN, Advances in Software Inspections, IEEE Transactions on
h t i
'
-
'
I
I i Software Engineering SE-12 (JuIy 1986). pp. 744-51 . (h
I
I '
'

! gFowler. 1 9861 P. J. FOwLER, Açln-process lnspections of Workproducts at AT&T,'' AT&T t Eh
'
! ' 7 i Teclmical Journal 65 (March/April 1986)
, pp. l 02-1 2. .F l l
t ; l 8 (Garman, l98 1) J. R. GxRMxx, 'The 'Bug' Heard 'Round the World,'' ACM SIGSOFT (h
' 2 1 i sohkvare Engineering Notex 6 (october I 98 1), pp. 3-10. IhI ! !
.
!
! ,
t
'
:
.
; ll ! :
I i 1
I ' ) 1 '
Please purchase Image To PDF Converter on to remove this message, thank you.
.
l
'
r
' j
.
j
I .
ë .
e *- > * e <
2
.
(

!
1
t
'
E
kES T JKZT: i
,
'
! .
-
)
)
: ,: '
'
.
j
l
'
j
'
(
.
j. ' j
'
Some of the more lurid computer magazines seem to suggest that the object-oriented paradigm was a sudden 'pi
I'
,
and dramatic new discovery of the mid-lgsos, a revolutionary alternative to the then popular structured
. :
: paradigm. That is not the case. Instead, the theory of modularity underwent steady progress during the 1970: j

and the 1980s, and obiects were simply a logical development within the theory of modularity (but see the g
Just in Case You Wanted to Know box on page 168). This chapter describes objects within the context of : $
modularity. 1
.
!This approach is taken because it is extremely difficult to use objects correctly without understanding r
'
wby the object-oriented paradigm is superior to the structured paradigm. And to do that, it is necessary to l
appreciate that an object is merely the next step in the body of knowledge that begins with the concept of $
a module.
L .
I
y.I HAT Is A M opukz*. 1*
:
W hen a large product consists of a single monolithic block of code, maintenance is a
nightmare. Even for the author of such a m onstrosity. attem pting to debug the code is l
;
extremely difécult; for another programmer to understand it is virtually impossible. I
'
The solution is to break the product into smaller pieces, called modules. W hat is i
a module? ls the way a product is broken into modules important in itself or is it I
important only to break a large product into sm aller pieces of code? @ i
j 'An early attempt to dcscribe modules is by Stevens
,
Myers, and Constantine, i (
.
(k d;
'
;who defined a module as A set of one or more contiguous program statem ents hav- I
Ii
ng a name by which other parts of the system can invoke it, and preferably having j

.
its own distinct set of variable names'' Istevens, M yers, and Constantine, l 9741. In : !
'
. l
.
other words, a module consists of a single block of code that can be invoked in the lr
way that a procedure, function, or m ethod is invoked. This definition seems to be
.
extremely broad. It includes procedures and functions of all kinds. whether inter-
,
nal or separately com piled. lt includes CO BO L paragraphs and sections, even though
1ô7
) .
:
I
I
Please purchase Image To PDF Converter on to remove this message, thank you.
;
; '! 1
: :
:
'
:
'
I
,
.
'
.
'

jj:
'
I .
j'
:
'
1
.
j ('
'
,
@ Ile t a A p 4 z R y . From Modules 'o obiedsi ( i
@
.
1i
'
! $ : !
,
g
'
.
!
'
' i ! .
2 q I JusT lN ZAS: You W ANTKP To Kxow1 '
:
'
q
j ' :2
.

I j jj I
.
r
'
jj object-oriented concepts were introdueed as early as luding (section 7.6) was first proposed within the soft-1 i ' ) i j 1966 in the simulation language simula 67 loahl and ware context by Parnas in 1971 (Parnas
,
1971 1, but the tI 'l !
@ j l , ' Nycaard
. 19661. However, at that time, the technoloMy technology was not widely adopted until about l 0 vears> i !
! E 1 ' - '''-' -'- - - - tlj l ! was too radical for practical use
,
so it lay dormant un- later, when encapsulation and abstract data types had
1 l I tiI the early l980s, when it essentially was reinvented become part of software engineering.l , . !
jj'j ' j ' 1 i within the context of the theory of modularity. It seems that we human beings adopt new ideas
I I j 7 j There are other examples in this chapter of only when we are ready to use them, not necessarily 2:l t ;; th
e way that leading-edge technology lies donnant when they are lirst presented.! j 4
.: ( I i until the world is ready for it. For example, information
.
! .i
'
j 1è l j .;
! j I I :
1)
*
ik .
'
'
-
'
1.

,
*
'
'
! l , . I .
1 .ë .E ;
i l they cannot have their own variables, because the detinition states that the property ;
'
q 1 ( of possessing a distinct set of variable names is merely ççpreferable
.
'' It also includesi
j C.t
, : modules nested inside other modules. But, broad as it is, the detinition does not go1
! ' ' 1 far enough
. For example, an assembler macro is not invoked and therefore, by thel )
.
! '
,
'
.
preceding detinition, is not a module. In C and C++, a header file of declarations1
:
,
I , , that is #included in a product similarly is not invoked', neither is an Ada package '.
'
! ' ,
( ; ' (implementation of an abstract data type) nor an Ada generic (macro). In short. this1
gi p :
!
definition is too restrictive. .

1 ' I l 1 Yourdon and Constantine give a broader detinition: 'çA module is a lexically 'l
: @ .i. i!
;
1 ! contiguous sequence of program statements, bounded by boundary elements, having .
1 ' '' Yourdon and Constantine
, 19791. Examples of boundaryi an aggregate identitier (!
j ;
i 1 j' elements are begin aend pairs in a block-structured Ianguage Iike Pascal or Ada or:
'
t -: i in C++ or Java
.
This detinition not only includes all the cases excluded1 l l 1 1. ' .1 Pa rsf 1
!
'
.
-j l I j by the previous detinition but is broad enough to be used throughout this book. ln
j E
'
' j r
'
'
l '; q particular, procedures and funetions of the dassical paradigm are modules. In the!
'
l ) 1 'l
; j . j object-oriented paradigm, an object is a module and so is a method within an object.: f ,
i ! To understand the importance of modularization, consider the following some- 'il ) . i :i 1
hat fanciful example. John Fence is a highly incompetent computer architect. He' j 1 ; I I w
,
1 ; h k still has not discovered that both NAND gates and NOR gates are complete', that
'

'
t 1 ' is every circuit can be built with only NAND gates or with only NO R gates. John '2
,l : ; , :
'
i
k k , . tr therefore decides to build an ALU, shifter, and 16 registers using AND, O R, and
'
1 ' 'i NOT gates. The resulting computer is shown in Figure 7.1. The three components g
! ! ' !'
T 1 ' are conneeted together in a simple fashion. Now, our architect friend decides that the
! J ircuit should be fabricated on three silicon chips
,
so he designs the three chips shown:
2
ci . 7
' : . in Figure 7.2. One chip has all the gates of the ALU, a second contains the shifter, ' thill
1 - ' ,I
! j j and the third is for the registers. At this point John vaguely recalls that someone in cor
i ! it is best to build chips so that they have only one kind of gate
, ed!l ' i i l a bar told him that) . .
: j i ! so he redesigns his chips. On chip l he puts all the AND gates, on chip 2 all the OR AL
l
l l l . t gates
,
and a1l the NOT gates go onto chip 3. The resulting tiwork of art'' is shown ha&
i : 2 q
! j j schematically in Figure 7.3. Fig
! ,
1 - :
l i

'
p; j
.,
.
.
j
j ' i .! :
l ë !l
(
,
Please purchase Image To PDF Converter on to remove this message, thank you.
;
w HA: Is A Mopuu? 1l* 1
,
x,
i
lChi
p 1 Chip 2 '
i
i
! l
t- '
le ' Registers Registers
rs
td . ALU ALU
zs :
I)r :
t
shifter Shifter :'
Chip 3

Flgvre KI Design of a FIgue* Ya Computer of Figure 7, 1 i
computer. fabricated on three chips. jAe11y :
l
udes r
. !
lt go .
the ' Chip 1 Chip 2f
tions ; I
Ek
age
this)
AND uates OR gates
cally - h
tving ;
dary
ja Of
I
uded
k. ln chip 3 '
:
R the
lject.
Jm e- NOT gates
t. He .I
that j' (
'
John i
.
Flgvee Ka Computer of Figure 7.1 fabricated on 1
,

and . three other chips
.
1
.
1Aents
1tt the
,
lown Figures 7.2 and 7.3 are tknctionally equivalent', that is, they do exactly the sam e :
ifter, thing. But the two designs have markedly different properties. First, Figure 7.3 is I
ne in considerably harder to understand than Figure 7.2. Almost anyone with a knowl- t
1gate
,
edge of digital Iogic imm ediately will know that the chips in Figure 7.2 form an ë
O R ALU a shifter, and a set of registers. However, even a leading hardware expert will @D
,
lown have trouble understanding the function of the various AND. O R, and NOT gates in
'
Figure 7.3. 1
1
i
i
,
'
'
j
'
1
'
j
Please purchase Image To PDF Converter on to remove this message, thank you.

. !
j ' '
'
.
!
.
k
i .
'
.
: 1 '! fi
1 ' ' 7
1 : : 1y@ t u A p T K * y * From Modules 'o Obiees
i j : !
ù $ ii
5! 1. ! : second, corrective maintenance of the circuits shown in Figure 7.3 is difficult.
! ' : ' . should there be a design fault in the computer and anyone capable of coming up
,
1
.
I I
'
11 E p @
with Figure 7.3 is undoubtedly going to make lots and lots of mistakes it will be
.
! ! ; j :
:j j i g : difhcult to determine where the fault is located. On the other hand, if there is a fault
l l ' ! i in the design of the computer in Figure 7
.
2, the fault can be localized by determining

l ( l
! k I j j whether it appears to be in the way the ALU works, the way the shifter works, or
' t i ' the way the registers work. Similarly, if the computer of Figure 7.2 breaks down, itj ë
.
i l l ë is relatively easy to determine which chip to replace; if the computer in Figure 7
.3
, I l 1 i
! h ! 1 breaks down, it is probably best to replace all three chips.
'1 l 1 1 Third
,
the computer of Figure 7.3 is difficult to extend or enhance. If a new type '
: l l 11
l i i of ALU is needed or if faster registers are required
,
it is back to the drawing board. But C
. 1 I 1 l ':
'
: ! ; 4 ' the design of the computer of Figure 7.2 makes it easy to replace the appropriate chip. .
: j .1 : .Perhaps worst of all
, the chips of Figure 7.3 cannot be reused in any new product.l l l
.
.
t i ' ' There is no way that those three specihc combinations of AND, OR, and NOT gates! E
'
I .i , ! ' can be utilized for any product other than the one for which they were designed. In a1l
1 l ; bability the three chips of Figure 7
.
2 can be reused in other products that requirepro ,l !
'
r ; ! ; an ALU. a shifter. or reeisters.

i : '' '' ''''''''' .1
'
The point here is that software products have to be designed to look like Figurei : E
-
.
i i : ! 7.2, where there is a maximal relationship within each chip and a minimal relationship
! ! ' between chips
.
A m odule can be likened to a chip, in that it performs an action or '
î
'
) . . ' :
4 î ' series of actions and is connected to other modules. The functionality of the prod- :
! ( ''
.
ë : ( uct as a whole is hxed; what has to be detennined is how to break the product into!
: '
yi ! ' : 1 modules. Composite/structured design (Stevens, M yers. and Constantine, l 9741 pro-
j i i 1 vides a rationale for breaking a product into modules as a way to reduce the costl
1 . .'! $
;
i of maintenance, the major component of the total software budget, as pointed out in
l ' ! 1 l Chapter 1
.
The maintenance effort, whether corrective, perfective, or adaptive, is re- :' i h
- 1
i I p j ' duced when there is maximal interaction within each module and minimal interaction1 1 1
1 between modules. ln other words, the aim of composite/structured design (C/SD) is : 1' I! ! 1 y
'
.

l $ to ensure that the module decomposition of the product resembles Figure 7
.2 ratherl ' , 1 (
l E I than Figure 7
.3.
;
) : ! (
1 l ! M yers quantilied the ideas of module cohesion
, the degree of interaction within aèl l '
! E q é!
module, and module coupling, the degree of interaction between two modules gMyers, jài 2 1 i
'' i ' E I 1978b1. To be more precise, Myers used the term strength rather than cohesion
. ,
tl ; i l ' . li
l ; i ;1 However, cohesion is preferable because modules can have high strength or low t
'
i ' ' I :l q
1 ; strength, and something is inherently contradictory in the expression Iow strength-t i
' '
: I if something is not strong, it is weak. To prevent terminological inexactitude, C/SDt '
' ! i 1 h ion
.
some authors have used the term binding in place of! i now uses the term co esj ' .
'
. l ë ! coupling
.
Unfortunately, binding also is used in other contexts in com puter science,
! '; 1 such as the binding of values to variables
.
But coupling does not have these overtonesi
.

: .'
and therefore is preferable.i -
.
I
i I i It is necessary at this point to distinguish between the action of a module, the
! l ' ' l ic of a module
,
and the context of a module. The action of a module is what it does,, ; . og! l
-
.
:
: : ; ; that is, its behavior. For example. the action of m odule m is to compute the square
!
i I
.root of its argument. The Ionic of a module is how the module performs its aetion,t
! .
j iI i
: ! 'j in the case of module m, the specilic way of computing the square root is Newton's!
.
i 1 ! ' 1 method (Gerald and Wheatley, l 9991. The context of a module is the specific usage of
'
, : : I .1
j ' !j l
1
I : ; 1
: ( '
.
Please purchase Image To PDF Converter on to remove this message, thank you.
.
:

u COHESION In :
lt. . that module. For example, module m is used to com pute the square root of a double
:
lp . precision integer. A key point in C/SD is that the nam e assigned to a module is its
le action and not its logic or its context. Therefore, in C/SDS module m should be named i
lt compute square roof; its logic and its context are irrelevant from the viewpoint of !L
lg its name. .
nr ,
it .
3
'e 72 touzslox@
ut
P' Myers delined seven categories or levels of cohesion (Myers, 1978b1. In the light of
't. dern theoretical computer science
,
Myers's irst two levels are considered equallymo
CS 11 be shown functional cohesion is optimal for the struc- Igood
. M ore precisely, as wi .
tl1 tured paradigm
,
whereas informational cohesion is optimal for the object-oriented
re
g paradigm. The resulting ranking is shown in Figure 7.4. This is not a linear scale of .
)any sort
.
It is merely a relative ranking, a way of determining which types of cohesion ;
re
ï are high (good) and which are low (bad). : ,
ip ' To understand what constitutes a module with high cohesion
.

it is necessary to l
' tar
start at the other end and consider the lower cohesion levels. i
d- . I
1 'ttl
!0
- xQa tolxelpzxvat touzslox ë '
pst
in A m odule has coincidental cohesion if it performs multiple
,
completely unrelated :
e- actions. An example of a module with coincidental cohesion is a m odule named
m print next Iine, reverse ihe string of characters comprising the second crgument,
is add 7 to the fihh argument, convert the fourth orgument fo floating point. An : j !
er bvious question is
,
How can such modules possibly arise in practice? The most '(lO (
common cause is as a consequence of rigidly enforcing rules such as tçevery module 11I
!
E a shall consist of between 35 and 50 executable statements.'' lf a software organization 1
'S, insists that modules must be neither too big nor too small, then two undesirable things .
n. will happen. First, two or more otherwise ideal smaller modules have to be lum ped .
W together to create a larger module with coincidental cohesion. Second, pieces hacked j
-
j
D '
af . .I
nformational cohesion o
ood) ' :e
,

7. ( Functional cohesion t j
zs .
5. communicationol cohesion I
zt Frocedural cohesion ;
le .
3, Temporal cohesion I
.
S,
2. Logical cohesion 1
1re
n; 1 . Coincidentol cohesion (Bad) l l
's : I
i lnf Fl
gvee x* Levels of cohesion. :: j
I ,
I
,
E
l'
j
Please purchase Image To PDF Converter on to remove this message, thank you.
. : i1 '
,
*
!t
'
1 l i .I
l : !
'
; i :

:
1 E j ' ''i ; ,ya t u A p T : w y . Fx m Modules 'o obiet's
i i I : ' ê
'
l : ; ' .
l k
, :
from well-designed modules that managem ent considers too large are combined,
1 1 i again resulting in modules with coincidental cohesion
.: ! ; ! '
( ( j i :, Why is coincidental cohesion so bad? Modules with eoincidental cohesion suffer!
' '' E i drawbacks. First such modules degrade the maintainability of the prod- !'.i two ser ous ,
I I
.
j uct, b0th corrective maintenance and enhaneement. From the viewpoint of trying to ' 1
'
k 1 i derstand a produ
ct, modularization with coincidental cohesion is worse than no 1.1 j ; l un
I
j i : I
1 j ( E : modularization at a1l gshneiderman and M ayer, 19751. Second. these modules are not : 4
'
-
I 1 1 : ''' ;! 1 reusable
.
It is extremely unlikely that the module with coincidental cohesion in the 1; l
! k jf
.
! j j first paragraph of this section could be reused in any other product. '! l l
I 1 Laek of reusability is a serious drawback. The cost of building software is so ,l

'
l , ,i l ' ' T great that it is essential to try to reuse modules wherever possible. Designing, coding, ' iù
l i : f
'
! ' documentings and above all, testing a module are time-consuming and hence costly '! ! :
.
l J rocesses. lf an existing well-designed, thoroughly tested, and properly documentedi : p
i 1 :
'
: '
I t ' ' t module can be used in anotherproduct, then management shouldinsistthatthe existing !
i . : i d le be reused
.
But there is no way that a module with coincidental cohesion can beà ? mo ui !
! l
! q è y reused, and the money spent to develop it can never be recouped. (Reuse is discussed ii
1 i in detail in chapter 8
.
) zi f f .
I ' : It is generally easy to rectify a module with eoincidental cohesion
-
because it rE ;
'
i ! . y
I l j perfonns multiple actions, break the module into smaller modules that each perform l
! ! ' i : (. one act on
.! i
'
.
: ' .

li r
'
.
'
:
'
,
'
:
'
i )
'
.
- . -
t , ; 7 2.2 kooltAk toueslox) !
1 : .
.
l i : ' 'l
i A dule has logieal cohesion when it performs a series of related actions, one of .ëj ! I : mo
( l ' ( i which is selected by the ealling module. All the following are examples of modules 'l l
.
l I j ! with logical eohesion:' l
( 4 j
.
t
,
: I 1 1 .
j k j : ; Example 1 M odule new operation which is invoked as follows: .
-
1 - : - 1

f f ( f tion code = 7
,
.
j l ! . ! unc
i 1 i 1 1 fkon (funcfion code
,
dummy 1 , dummy 2, dummy 3),.l ) . new opero
I 1 1 '
'
i
! I 1 i // dummy 1 , dummy 2, and dummy 3 are dummy variables,l 1 :l
7 ( // not used yfunction code is txatz/ to 7! I 1 1 l
I ! 1 :
l ' ? 7 In this example, new operction is called with four arguments, but as stated in
.
1 . l1 l C
, the comment lines, three of them are not needed if funclion code is equal to Z. This
1 1 ' 1
: , , degrades readability, with the usual implications for maintenance, both corrective andI
p
i ; 2 enhancem ent.j
. .
t .
,
f
.k
'
1
.
. -Example 2 An object that performs a1l input and output.'

ë I ( :j
. .
1 : Example 3 A module performing editing of insertions and deletions and modisca-1 1 ' i tions of master tile record
s.13 I
1 ; '
j I j ; j Example 4 A module with logical cohesion in an early version of OS/VS2 per- ''
l ' l formed 13 different actions; its interface contains 2 l pieces of data (Myers, l 978b1.; ;!
i 1 i
! E é ' l
! q
'
:
. .
)
r 'ii
: !
'
! ; I '
Please purchase Image To PDF Converter on to remove this message, thank you.
1
n COHESIQN 1Ta
2 ( ,
'
Led, i Two oroblems occur when a module has logical cohesion. First. the interface is
: ''''' :
diffcult to understand, Exam ple 1 is a case in point, and comprehensibility of the :
gfer ', module as a whole may suffer as a result. Second, the code for m ore than one action . E
I '
od- may be intertwined, leading to severe maintenance problems. For instance, a module
to that performs all input and output may be structured as shown in Figure 7.5. If a new '4

no tape unit is installed, it may be necessary to modify the sections numbered 1, 2, 3, 4, :
not 6, 9, and 10. These changes may adversely affect other forms of input-output, such as
the laser printer output, because the laser printer will be affected by changes to sections
1 and 3. This intertwined property is characteristic of modules with logical cohesion.
; so A further consequence of this intertwining is that it is difficult to reuse such a module
4
Lng, in other products. .
stly l
ltt, (1 !
j '
Eing X2.3 W MpleAk Z/HE:I@N I
; I
z be '
ed A module has tem poral cohesion when it performs a series of actions related in time.
,s
.' An example of a module with temporal cohesion is one named open oId moster file, i 1
:
1
-
it : . new master file, transaction file, and print file, initialize soles region table, read ,ie
xm
first transociion record, and first oId master file record. In the bad o1d days before
Id be called perform iniùialization.(7sD, such a module wou
ë
'
.
h
.
?
!1

. Code for aII input and output I
z of
Jles 2
. code for input only '
:
3. Code for output only
I 1
z. code for disk and tape 1/O I
'
.
j .
5. Code for disk I/O
6. Code for tape I/O
7. Code for disk input !
I
:1 in ;
rhis 8. Code fOr disk output i '
.
j
and j9
. Code for tape input
E l
.
1
1 0. Code for tape output r
;
: . : (
.
: . ' jica
- j

37. Code for keyboard input $
p
'
.
ner- ;
ibj. FI@we* 7k5 Module that performs aII input cnd output.
t
' j
Please purchase Image To PDF Converter on to remove this message, thank you.
: ! '
.
l k . ';
'
;
'
-
:
j
'
'
: !
'
' .
:'
11 i 1
*
ii
,
'
-

'
1 ' 1y* t x A p &. K R y * From Modules fo obiet's '. I ! , à
.
î l j il 4 : .l
I ! i k The actions of this module are related weakly to one another but more strongly to
i t : 1 actions inother modules.consider- forexample,the sales region toble. lt is initialized' ! '
,
i i
n tlais module, but actions such as update scles resion table and print sales region .h
-1 l . !
.
'
,
1 ( 1 , table are Iocated in other modules. Therefore, if the structure of the sales reoion
i h i ' 1 ) table is changed
,
perhaps because the organization is expanding into areas o-f thel
-
1 (I j 1 country where it previously has not done business
,
a number of modules will have@ # @ l(
! p ! p to be changed. Not only is there more chance of a regression fault (a fault causedl ! s
. .
t 1 : : by a change made to an apparently unrelated part of the product), but if the number'
t : f ted modules is large
, there is a good chanee that one or two modules will be 1of af eck I E
: I 1 overlooked. It is much betterto have all the operations on the sales region table in one # 41
i ' ' dule as described in Section 7
.
2.7. These operations then can be invoked, when J; l $ l 1330 5

; i ' needed, by other modules. In addition, a module with temporal cohesion is unlikely ) 1.
j
'
q
'
: i
; t : ' to be reusable in a different product. ? 1
)
'
j l g
'
jl ; ' ! 1
4 j : i ) ! 1
1 i ' I xa 4 ppotxpuox: toHzslox
i ? ) *
! 1 ' #
- ! .
!l
à k , A module has proeedural cohesion if it performs a series of actions related by the lj
j .
'
. î l sequence of steps to be followed by the product
. An example of a module with f2 E
'
) ë , procedural cohesion is read part number from datobuse cnd updcte repoir record . t
'
;
.
jjjjyi
.

on maintenance .
! 2 i
'
2 ' t This clearly is better than temporal cohesion at least the actions are related f1
è ; d lly to one another
.
Even so, the actions still are w eakly connected, and a; ; ! proce ura
i I again the m odule is unlikely to be reusable in another product
. The solution is to ' cI I i
l t
'
.! l i j break up a module with procedural cohesion into separate modules, each performing t,
I i ' ! one action
.
ep l l !! ,
l ) i l tI
I ! '! i ai I :
-
It I : ' j 72.5 toM-uultvloxlk touzslox n
i I E
i I : ! i.l
I 1 i ; , A module has communicational cohesion if it performs a series of actions related by 11
. j t j ! . ji q j r the sequence of steps to be followed by the product and if all the actions are pen : v
' i l ' ' formed on the same data
.
Two examples of modules with communicational cohesion E1 t t - t :
1 , ! ! j are update record in dotabase and write it to the audit trail, and calculate new f
1 i i l I ' frajec@ory and send itto the printer. This is better than procedural cohesion because FI ?
'
- i 1

! ) ' the actions of the module are more elosely eonnected, but it still has the same draw- f
;
. l1 ! b
ack as coincidental, Iogical, temporal, and procedural cohesion', nam ely, that the'
, j . : 1
: '
,
. ; ' m odule cannot be reused. Again the solution is to break such a module into separate
'
. .
.
j i f; modules, each pertorming one action. :
;
' : '.1 In passing
,
it is interesting to note that Berry uses the Lermllowchart cohesion1
1 . .
7
*
l ! !' to refer to temporal, procedural
,
and communicational cohesion, because the actions A
j I .j 1. ( performed by such modules are adjacent in the product iowchart gBerry, 1 9781. The it$
1 i( : j
,
:
, j actions are adjacent in the case of temporal cohesion because they are performed d
i j '
,
t j at the same time. They are adjacent in procedural cohesion because the algorithm oll

: ( requires the aetions to be performed in series. They are adjacent in communieational . e
ë
.
9 1 ;
1 ! r;
! ( : ;
g 1
1
; !!
1
Please purchase Image To PDF Converter on to remove this message, thank you.
7a CQHESION lF5 '
:
r
'
:
y to cohesion because, in addition to being performed in selies, the actions are performed
zed on the same data, and therefore it is natural that these actions should be adjacent in .
ion the iowchart. '
ion I
the .J
aVe 12.* FuxtTloxAk toueslox
sed
rber A module that performs exactly one action or achieves a single goal has functional co-
l be hesion. Examples of such modules are get temperature of furnace; compute orbital
f eledron; write to diskeqe; and calculate sales commission. 'one o
hen A module with functional cohesion often can be reused because the one action
Eely that it performs often needs to be performed in other products. A properly designed, :
thoroughly tested, and well-documented module with functional cohesion is a valu- '
able (economic and technical) asset to any software organization and should be reused !

as often as possible (but see Section 7.5).
M aintenance is easier to perform on a module with functional cohesion. First,
functional cohesion leads to fault isolation. If it is clear that the temperature of the !
the furnace is not being read correctly, then the fault almost certainly is in module gel
i
vith iemperature of furnace. Similarly, if theorbital of anelectron is computedincorrectly, :
d then the first place to look is compute orbital of eledron. ' 'or ,
Once the fault has been localized to a single module, the next step is to make I
tted the required changes. Because a module with functional cohesion performs only one
!
and action, such a m odule generally is easier to understand than a module with lower I ;
E !
q to cohesion. This ease in understanding also simplihes the maintenance. Finally, when j
king the change is made, the chance of that change affecting other modules is slight,
especially if the coupling between modules is low (Section 7.3). i
le when a product has to be extended. For ex- iFunctional cohesion also is valuab
am ple, suppose that a personal com puter has a 10 M b hard drive but the manufacturer 'j
now wishes to market a m ore powerful model of the computer with a 30 M b hard drive !
! 1i
nstead. Reading through the list of modules, the maintenance programmer finds a lI .l b
y module named write to hard drive. The obvious thing to do is to replace that module y
Iorger hard drive. I :ler
- with a new one called write to
kion ln passing, it should be pointed out that the three çémodules'' of Figure 7.2 have
lew functional cohesion, and the arguments made in Section 7. 1 for favoring the design of
use Figure 7.2 over that of Figure 7.3 are precisely those made in the preceding discussion :
a.w- for favoring functional cohesion. g
itll kr
!
,rate

.
!%A
.V IXFORMATIONA: touzsloN 1
'
i t??k 1
ons A module has informational cohesion if it performs a number of actions, each with t
h action, a1l perform ed on the same irhe its own entry point
,
with independent code for eac j
gled data structure. An example is given in Figure 7.6. This does not violate the tenets I
hm of structured programming'. each piece of code has exactly one entry point and one
knal exit point. A major difference between logical cohesion and informational cohesion j
J 1 I
' k
'
!
1 .
i'
j
Please purchase Image To PDF Converter on to remove this message, thank you.
: j '1
,
l ' :
i i I .
l 1
.
1 i:
.
i l i 4yl t u A p 4 : R y . From Modules 'o obieest :
i :i

.'
1l
1 I t i :
: r
'
ii ( 1 o
efinition of .
1 i . (l 1 l
I Sales region table
i
1 ) ! r
-
j j j j j
i l , i Entry initialize sales region table
.
l ! . 2 I
:1 I ' i ! j Exit 'I
I . i l ;'j 1 j 1 i y Entry update sales region tablel
. ! .
1 -1 . ji
.
i . . j j Exit hl I
:1 ! '
q ! Entw print sales region table ,. 1 j
( l f ; . jI
. j ! j Exit' j '
q l ( 2
j ' . C
'
: ! . Flgure xl Module with informational cohesion

.! . I . .!
.
I : ë
,i i
i i ; 1
l ' : ; is that the various actions of a module with logical cohesion are intertwined
,
whereas! I
: . I .l ! ' !
;
in a module with inform ational cohesion the code for each action is completely inde-
t
.
pendent.
i $ ' 5
i A module with informational cohesion essentially is an implementation of an ab-i ;
! E '
. ,
stract data type, as explained in Section 7.5, and aIl the advantages of using an abstract
j : i '
, . data type are gained when a module with informational cohesion is used. Becausei 2 !
!i '
j ; j an object essentially is an instantiation (instance) of an abstract data type (Section!
:E l ( 1 7.7), an object, too, is a module with informational cohesion. This is why Section 7.2!
It t j Stated that informational cohesion is optimal for the object-oriented paradigm. '.! i l
l ! i t !
i I !'
)
'
j :

j 'i l i xa
-a touzslox zxx-pui l .
I
1 .' i j : 1 ;
.
i 1 ; f f ior further insight into cohesion, consider the example shown in Figure 7.7. Two11 k
: ;i j , modules in particular merit comment
. You may be somewhat surprised that the mod-i
i l I les initialize sums ond open files and close files ond print averoge temperatures 'I I j
s
1 l tl
l i I ' 1 i both have been labeled as having coincidental cohesion, rather than temporal cohe-
l 1 I 1 I ' ion First
,
consider module initialize sums and open files. It performs two actions! : : i S -
t j related in time, in that both have to be done before any calculations can be performed, .!
! r
.
and therefore it seems that the module has temporal cohesion. Although the two ac-1 i
' l : , ' tions of initialize sums and open files indeed are performed at the beginning of the!
; 1 ? i ther factor is involved
. Initializing the sums is related to the problem,, i calculat on, ano
l ' )
:
but opening hles is a hardware issue that has nothing to do with the problem itself.
l ' k .
I j I ; The rule when tw o or more different levels of cohesion can be assigned to a mod-
l i ( ule is to assign the lowest possible level. Thus, because initialize sums ond open files
. '
j

ll
2 - ;l p - :
i ,
'
.
2
. ;
j . r
'
1 : !
.
j . j j
!
1 , . r ! The discussion in this parograph ossumes that the obstract doto type or obiect is well designed. If tlae methods
! 1 : I l of an obiect perform completely unrelated actions, then tlne obiect has coincidental cohesion. '
j ' - 1
! .
Please purchase Image To PDF Converter on to remove this message, thank you.
. :
xa CoupuNG 1yF
: '
coincidental functional functional coincidental
initialize sums create new store close files and '
and temperature temperature print average
open files record record temperatures
functional functional I
d in site, store record @rea
time, and for specific I
.
temperature site 1

:
;
Iogical : '
.
ks
dit site, time, i
.
.
s e
or temperature .
field ;
)- i
I 2
st yI
, xy Module interconnection diagram showing cohesion of eoch module. IJ;() I
I
in ' .
a could have either temporal or coincidental cohesion
,
the low er of the two levels of ,
ohesion coincidental is assigned that module. That also is the reason why closec
:
files and print average femperatures has coincidental cohesion. I
:
I i
l !
I 1
'
1 I
-

) 1
o . Jf
1. V.3 C@UPLING 11
,S .
)- Recall that cohesion is the degree of interaction within a module. Coupling is the
ls degree of interaction between two m odules. As before, a number of levels can be
â, distinguished, as shown in Figure 7.8. To highlight good coupling, the various levels .
:
'
)- will be described in order, from the worst to the best.
l
Le !
'j . '& I
f. ' 5. Dota coupling (Good) 'r
1- 4. stamp coupling '
j 'js a
. control coupling !
2 common coupling ;( .
! I1
.
Content coupling (Bad) . i
'
i
2 Ils
Flgve. K* Levels of coupling. l
lI
iI
.
i
Please purchase Image To PDF Converter on to remove this message, thank you.

,
'
' ë
'
)
( ( . ' ,:
I I .
. : I r
! j 1F@ t H A p T : R 7 @ From Modules to Obieds '.
i t l
1 ! .
i q Kaa toxnx: toupux.
2 ! E':
-
I ;! :
'
t q Two modules are content coupled if one directly references the contents of the other.
j 5 AlI the following are examples of content coupling:
l il
i i Example / Module p modifies a statement of module q
.
l l
t l 'I
1 .i I I This practice is not restricted to assembly language programming
. The olierverb, nowl
i 1 : mercifully removed from COBOL. did precisely that: It moditied another statement.: ! '
.
i
.
j j 1,

.
'
j
'
'
'
,
r
'
'
l I ; . Example 2 M odule p refers to local data of module q in terms of some numerical
' I I
' j : displacement within q.
- ! 2 i
i ; j t ') $
r
Example .3 M odule p branches to a local label of module q.
,l ; ! .!
i .
'
! . .I ( )
( . : 7 i Suppose that module p and module q are content coupled. One of the many!
i i . dangers is that almost any change to q, even recompiling q with a new compiler ori
: '1 l ' bler requires a change to p
.
Furthermore. it is impossible to reuse module p in: assem ,i i -
. ë
'
I
) g ! some new product without reusing module q as well. W hen two modules are content

' ! ' coupled
,
they are inextricably interlinked.i
, -
l . )
'
'
! ) . ' '
'
,
i l i ; .'
.
Ka.Q to-Mox touptlx.j !
: r r1
l ! l : I 1
l j ; I Two modules are common coupled if both have access to the same global data. The
1 I '' i situation is depicted in Figure 7
.9. Instead of communicating with one another by; 1
'
: b d change the value of globalj J t t passing arguments, modules cca and cc can access ani
i ' i variable. The most common situation in which this arises is when both cca and ccb1 I
I i
i ) ; j j have access to the same database and can read and write the same record. For common) l : !
) y : 1 coupling, it is necessary that both modules can read and wlite to the database', if the
l l database access mode is read
-
only, then this is not common coupling. But there arel r ' !i
l ,j I j other ways of implementing common coupling, including use of the C++ or Java d
l ! modiher publk. .j '
l This form of coupling is undesirable for a

number of reasons. First, it contradicts , ql ; !
à ! : ;
j i ! ! j the spirit of structured programming in that the resulting code is virtually unreadable
.
$l ' I . .
! 2 consider the pseudocode fragment shown in Figure 7
.10. lf global voriable is a 1
1
i ll q
'
global variable, then its value may be changed by module 3, module :., or any i
!
l
1 ë ; ' module called by them. Determining under what conditions the loop terminates then t: ) p :
j . is a nontrivial question; if a run-tim e failure occurs, it m ay be difhcult to reconstruct (
j C . :: : what happened
,
because any one of a number of modules could have changed the II ; ;
I ) I value of global variable. ($
! j A second difficulty is that modules can have side effects that affect their readabil- :
1 !
j
l
$
ity. To see this. consider the call edit this transaction (record 7). If there is common ti
! ling
, this call could change notjust the value of record Z but any global variable: ? coupi r 1
1 j that can be accessed by that module. In short, the entire module must be read to lind i
1 ; t recisely what it does
.

:q I : Ou p
: ! , 1
! ';
.
! t
'
! j
' j j '
Please purchase Image To PDF Converter on to remove this message, thank you.
I
, j .
'
y.a coupuNo ly*
2
ccb while (globol variable == 0)
cca j j
-
if (orgument xyz > 25) z:'
'
d le 3 (); 1 11mo U
else l
module z. (); .: global variable
l
V Flgure %* Common coupling
. Flgvee K1@ Fseudocode
T. fragment reflecting common
couplino. '
,
' '*''' I
Ll !' Il

l 1Third
, if a maintenance change is made in one module to the declaration of ,(
-
a global variable, then every m odule that can access that global variable has to be
,
I
changed. Furthermore. all changes must be consistent. J
y A fourth problem is that a common-coupled module is difhcult to reuse because I
;
r the identical list of global variables has to be supplied each time the module is reused.
'
i
n The fifth problem is potentially the mostdangerous. As aconsequence of com m on
kt ' coupling, a m odule m ay be exposed to more data than it needs. This defeats any ;I
attem pts to control data access and ultim ately may lead to computercrime. M anytypes
'
of computer crime need som e form of collusion. Properly designed software should
: I
.
not allow any one programmer access to al1 the data or modules needed to com mit l
I
'
. a crime. For example, a program mer writing the check printing pal4 of a payroll '
product needs to have access to employee records', but in a well-designed product,
z such access will be exclusively in read-only mode, thus precluding the programm er
making unauthorized changes to his or her monthly salary. To make such changes, thef
11 , programmer has to find another dishonest employee, one with access to the relevant I
n records in update mode. But if the product has been badly designed and every module l t1
ja can access the payroll database in update mode, then an unscrupulous programmer ,
t

z acting alone can make unauthorized changes to any record in the database. $ j
1 Iz ' Although it is hoped that the previous arguments will dissuade al1 but the most l
1à daring of readers from using common coupling
,
there are situations where common k
?
l
coupling might seem to be preferable to the alternatives. Consider, for example, a 1
s product that performs computer-aided design of petroleum storage tanks (Schach
and Stevens-Guille, 19791. A tank is specihed by a large number of descriptors such
: :
, as height. diameter, maximum wind speed to which the tank will be subjected, and
; insulation thickness. The descriptors have to be initialized but do not change in value :,
.
1 thereafter, and most of the modules in the product need access to the values of the : '
t descriptors. Suppose that there are 55 tank descriptors. If all these descriptors are : ë
! .
) passed as arguments to every module, then the interface to each module will consist ;
E
of at least 55 argum ents and the potential for faults is huge. Even in a language like
'
' Ada which requires strict type checking of arguments, two arguments of the same @ '
l ' type still can be interchanged, a fault that would not be detected by a type checker. r '
1 I
r . One solution is to put all the tank descriptors in a database and design the product ; j
ë ' in such a way that one module initializes the values of all the descriptors, whereas : 1
i iall the other modules access the database exclusively in read
-
only mode. However, !1
i 1

.
! j !
!
.
i ;
,
i '
Please purchase Image To PDF Converter on to remove this message, thank you.
'
. :i i : -
h l I 'I I
! I ! . :'
:1
i ! :
'
'
: $ 1*@ t H A > T E R 7 * From Modules fo Obiet's
i l I . 5 i, '1 1 :
j :l j , if the database solution is impractical, perhaps because the specified implementation1
- -i l I ! language cannot be interfaced with the available database management system
,
then :' ë
:! 1 an alternative is to use common coupling but in a controlled way
. That is, the productI
! ; t
'
.
should be designed so that the 55 descriptors are initialized by one module, but none
: .
!

5 i of the other modules changes the value of a descriptor. This programming style has
.
1 ( t t : to be entorced by management, unlike the database solution, where cnforcement isI
' : ' i imposed by the software
. Therefore, in situations where there is no good alternative
.
l I-1 r
j : : to the use of common coupling, close supervision by management can reduce somel
1 ' ' of the risks. A better solution. however, is to obviate common coupling by using1
l 1 I ! r l! j j I : information hiding. as described in Section 7.6.
I I : ;
'
t t
'
.
l :l l i
j ! :.
l l ? q i '
j 1 'l F x a a touvRot touptluol l
I ' *I j - jI
1 I é , i : Two modules are control coupled if one passes an element of control to the otherl
i i '. - . .;
( module, that is, one module explicitly controls the logic of the other. For example,
' i 1 control is passed when a function code is passed to a module with logical cohesion .l
; . .I l ) ' (section 7
.
2.2). Another example of control coupling is when a control switch is 1( i .
i
-I E i passed as an argument.
1 I ' . d; (

j t If module p calls module q and q passes back a flag to p that sayss I am unable !
t : ' ,,
q<j ( . to complete my task, then q is passing data. But if the flag means, l am unable 1
1I 2 j , to complete my task; accordingly, write error message ABCI 2379 then p and q are 4
t ; control coupled
.
In other words, if q passes information back to p and p decides what Il i i ! )
j l ; k action to take as a consequence of receiving that information, then q is passing data. ; tl i
.
j! 1
: j. ! But if q not only passes back information but also informs module p as to what action
'
1 I ' p must take
,
then control coupling is present. .l
! l : 1 iI l
1 t The major difficulty that arises as a consequence of control coupling is that the .) l !
d les are not independent', module q. the called module, has to be aware ofp two mo u'1 l (
/1 I 'j i the internal structure and logic of module p. As a result, the possibility of reuse is)
'
i
I j jj I
r reduced. ln addition, control coupling generally is associated with modules that have
'
; ë 1 logical cohesion, and the difficulties associated with logical cohesion then are present.
: l t( .
:l
.
; i ;i l
1 ' 1 't xax sva-p toupuxo

,! )
'
LI
:
:
t I 1 . l
; E j ln some programming languages, only simple variables such as part number, sotelliie .
t : i
altitude, or degree of multiprogromming can be passed as arguments. But manyi :
.
: 1
l i E Ianguages also suppol't passing data structures
,
such as records or arrays, as arguments.
r '
1 C In such languages
,
valid arguments would include purt record, soiellite coordinotes,i
'
ë
'
.
'
:
'
.
'
!
: E or segmenf tcble. Two modules are stamp coupled if a data structure is passed as an
.1 ' ?

'
1 2 argument, but the called module operates on only some of the individual components
$ .J j . of that data structure.
I ; ; :1 Consider, for example, the call calculate withholding (employee record). It is :
'
j
( ''; j not clear
, without reading the entire calculote withholdinq module, which lields of
' 1 , j '*'@' ,g :
I the employee record the module accesses or changes. Passing the employee s salary
! 1 ;
)
'
I : 1; j
g -
!I
.
(
l l
'
j .i
-
Please purchase Image To PDF Converter on to remove this message, thank you.
1
. f
'
j .(
.
xa CoupuNG lm ,
' !

nn obviously is essential for com puting the withholding, but it is difhcult to see how the .
cn employee's hom e telephone number is needed for this purpose. lnstead, only those
'
I 1
lct fields that it actually needs for com puting the withholding should be passed to module 1
ne cclculate withholding. Not only is the resulting module, and particularly its interface, 11
'
'
i tLas easier to understand
,
it is Iikely to be reusable in a variety of other products that also
: !
)I .is
.
need to compute withholding. (See the Just in Case You W anted to Know box below ,
ve for another perspective on this.)
ne ' Perhaps even more important, because the call colculate withholding (employee
ng ' record) passes more data than is strictly necessary, the problems of uncontrolled data
access, and conceivably computer crime, once again arise. This issue was discussed
: in Section 7.3.2.
. 1
i Nothing is at al1 wrong with passing a data strtlcture as an argument, provided that I
I Iall the components of the data structure are used by the called module
. For example,
calls like invert matrix (originol matrix, inverted matrix) or print inventory record
' h d) ass a data structure as an argument, but the called modules l1er (ware ouse recor p
j
le . operate on a1l the components of that data structure. Stamp coupling is present when
5 . x '*. '' ''' ''''' ''' '
on a data structure is passed as an argument, but only some of the components are used

is by the called module.
A subtle form of stamp coupling can occur in Ianguages like C or C++ when a 1
le pointer to a record is passed as an argument. Consider the call check oliitude (pointer ' '1.
to position record). At hrst sight, what is being passed is a simple variable. But the t71e
lled module has access to all of the fields in the posilion record pointed to by llre ca
inter to posifion record. Because of the potential problems, it is a good idea to 1Aat po ù
t,a examine the couplinn closely whenever a pointer is passed as an argument. 14
' 'K' *'*' '' A. 'w'' ''
'
'
'' '''' ''-'' !
On
:he
'
t i
of ,1
: I 1i
s ! j
'
l ,
L!ip 41, ' t
nt. Ju$T IN ZA*: Y@u W ANTEP T@ K N@W : '
-
i
'
I
'
.
1 l
l

I
.
Passing four or five different fields to a module may be any kind, including for performance reasons gKnuth.
.
slower than passing a complete record. This situation 19741.
leads to a larger issue: W hat should be done when op- But what if optimization really is required? ln this .
ite ' timization issues (such as response time or space con- case
,
Knuth's SecondLaw of Optimization applies. The
i :ny straints) clash with what generally is considered to be Second Law (labeled for experts only) is: Not yet? ln . .
Lts. good software engineering practice? other words, first complete the entire product using ap- l
s ln my experience, this question frequently turns propriate software engineering techniques. Then, if op- 19
, , :
out to be irrelevant. The recommended approach may timization really is required. make only the necessary gan
slow down the response time. but by only a m illisecond changes, carefully documenting what is being changed '
Ats
.fartoo small to be detected by users. Theretore, in and why. If at alI possible, this optimization should be i
rOr SON
accordance with Don Knuth's First Law of Optimiza- done by an experienced software engineer. .
is , !
tion: Don S there rarely is a need for optimization of
.f (O ;
; !tl-)
?- . I I
'
. 2 Il
i E
I
.
!I !

1.
'
Please purchase Image To PDF Converter on to remove this message, thank you.
: (j . 't ' ) .
I l ! 2
.
'
) '
:
1 i i
@
'
@ kl
j 1aâ t u A p T . w y @ From Modules 'o Obiees1:
-
*
1
*
j
'
j
'
:2
.
*
l 1 l !
i l l K a.5 P ATA toupuxo
f
'
-

1 ! qi !
i I Two modules are data coupled if all arguments are homogeneous data items. That is,
l ' 1 t is either a simple argument or adata structure in which all elements areevery argumen
'
! j E 1 used by the called module. Examples include display time of orrival (flight number),
' ; j ' compute product (first number, second number, result), and determine iob with1
t ' hi hest priority (iob queue).1 l g1
.
l i .; I
! i j Data coupling is a desirable goal. To put it in a negative way, if a product exhibits .
l 1 ! l t datacoupling exclusively, then the difhculties of content, common, control, and stamp .k l
h l . ,
j E ; coupling will not be present. From a more positive viewpoint, if two modules are data '1
,
1 1 coupled, then maintenance is easier, because a change to one module is less likely to.
, j r - !t
) ! t cause a regression fault in the other. The following example clarifies certain aspects .1
l i i ' f coupling
.
'l , I o .I
:l )
'
.$ ) ' ( .i i ;
'
l p yvxmp.!
,
%3.* touptlxo
1 ;
'
-

:1 Consider the example shown in Figure 7
.
1 1 . The numbers on the arcs represent :' . :I i
i :I
! ' interfaces that are defined in greater detail in Figure 7. l 2. For exam ple, when module
i l lls module q (interface 1 )
,
it passes one argument. the type of the aircraft. W hen q Si
:
P Ca :1
.
.
, ) returns control to p, it passes back a status tlag. Using the information in Figures 7. 1 1
l ! ' ' and 7. l2, the coupling between every pair of modules can be deduced. The results
i : i : ' are shown in Figure 7
.
13.I : q ;
!
. t some of the entries in Figure 7.13 are obvious. For instance, the data couplingl r : 1 1
between p and q (interface 1 in Figure 7. l 1 ), between r and t (interface 5), andi ' l) l l ' between s and u (interface 6) is a direct consequence of the fact that a simple variable
.
l l !
l i is passed in each direction. The coupling between p and s (interface 2) would be data1 i 1 1
I ' ( 1 1 ling if al1 the elements of the list of parts passed from p to s are used or updated
, .
j i , eoup. ; l
'
t i but it is stamp coupling if s operates on only certain elements of the list. The coupling
i 1 i ' between q and s (interface :) is similar
. Because the information in Figures 7.1 1 and

.
( :6 k
k p l 7.12 does not completely describe the function of the various modules, there is no
i 1 ! . way of determining whether the coupling is data or stamp
.
The coupling between q 'i I
kI l t and r (interface 3) is control coupling
,
because a function eode is passed from q to r. .
l 1 r
j ! 1 I Perhaps som ewhat surprising are the three entries m arked common coupling in '
i l l -l
: , Figure 7. l3. The three module pairs that are farthest apart in Figure 7. l 1- p and t, '! i
l ' l 1 p and u, and t and u- at hrst appear not to be coupled in any way. After all, there is
1 no interface connecting them
, so the very idea of coupling between them, let aloneI i ' t
! ' ' common coupling
,
requires some explanation. The answ er lies in the annotation on
-
) i .
l ' ' ; the right-hand side of Figure 7. l 1, that p, @, and u a11 access the same database in
1 ;
' update mode. The result is that a number of global variables can be changed by a1l '
i ; three m odules
,
and hence they are pairw ise com mon eoupled. '1 :
'
1 . I ' i
I i . ! !1

.
t!
'
1! ! . p K a.T TH: IMpoRTAN<z o: toupux.
! ' :i
.
i1 1
i p Coupling is an impoflant metric. lf module p is tightly coupled to module q, thenl !
) . .! k j a change to module p may require a corresponding change to module q. If this change: ! j -
?
'
! 1 j
.
i
. t
: j :!
: i
.
: ; '
Please purchase Image To PDF Converter on to remove this message, thank you.
L
u CoupuNo I*a
ë I
r'
.
: 11
! 1%
, .; 1 .
'e p, t, and u access : i
2 the same database i l)

: .
q I
in update mode !h '
3 4
rFi r :)
P
.a 5 6
'
.
O ' ! u
ts . .
' Flgvr. KI' Module interconnection 'Idiagrom for coupling exomple
.
IE
1
1
2 '
nt :
lk)
.
I
q iNumber In 0u'
.
1 ;
IE
ts 1 aircrah type status flag I
2 Iist of oircroh parts - ! ë
lg 3 function code - ' I
td z
. jisf of oircrah parts -

'e 5
art number part manufccturerP
La 6
part number part nome .
:l, '
.
l !
è l !lg i
i1
(j Flgvr. Kl.2 Interface description for Figure 7. 1 1 . . 11
.
I
tt;l j I
1 I
q j I
: 1 t
'
r. ) 1
Ln I
t
i q r S t U 2S
q
le '
,
Data or !
pn o Data - Common Common
:
'
stamp ! .
Ln .

11 Data or :
'
q Control - - :
stamp I
!
r - Dota -
s - Data !
Common l 1t
! I;
l
rn : j (i
.
lFlgure K1a C
oupling between paris of modules of Figure 7. 1 1 . i jje
ll
I
l
Please purchase Image To PDF Converter on to remove this message, thank you.
j ( sl
: 2 i
)
'
. .
f
'
t . '
I
.d ! !: 4a* t u A p T : w y . From Modules #o oblet's;
.
I ; ' I!

I ' EE ,
i ,, . .l
.
Abskrot. do- ppe: o aoto type tosether with the actions performed on instantiations ofll
'
! that data type (section 7.5)
,
k ! .
.
11
,
.
ë : Abstratgion: u meons of achieving stepwise refinement by suppressing unnecessary details
'
E ond uccentuating relevunt detuils (section 7.4. 1) .!
-
l
ï ' i ( closs: an abstract data type that supports inheritance (Section 7.7): j;
j '.1 ! cohesion: the degree of interaction within a module (Section 7
.
1 )1 i ' 1
i t t ' '. ; coupling: the degree of interoction between fwo modules tsection 7. ! ) '
! l l : '
! .1 q ' : i Dofa entopsuloeion: a data structure together with the actions performed on that data
I 'r ; i structure (section 7
.
:)1 i .
1 7 ' ' !
:
l q :

,
'
. Enqapsulalion: tFe gathering together into one unit of a11 aspects of tFe reul-world entity . .
! l - ! .1
I ; ; modeled by thot unit (Section 7.z. 1 )l
t i I . jl
; 7
. i i Informoeion hiding: structuring the design so that the resulting implementation detailsi
.
'
' will be hidden from other modules (Section 7.6) 1l l (
1 I ' ! 1 obie<': an instantiation of o class (section 7
.
7)I i '
.
i !
- i I , .
.
1l !
, .
ti i
. ! Flgure x1* Key definitions of this chapter and the sections in which they appear
.) 1 i ; ' (j S
! j ë .' . l
i ! !
t : ! '
,
'
is made, as required, during the integration or maintenance phase, then the resultkng E
,

! : '
'
. product will function correctly., however, progress durina that phase will be slower r1 : '
.
' '
. han would have been the case had the coupling been l Joser. on the other hand, if f,
.
ti
j ( k ) the required change is not made to module q at that time, then the fault will manifest '. f
l ' . ' .'œ '''''''' 11
.
j' i : itself later. In the best case, the compiler or linker will inform the team right away i
I ! l 2 that something is amiss or a failure will occur while testing the change to module (
; 1 il k l i
' w hat usually happens, however, is that the product fails either during subsequent r: p k h) ) P.
' 4 't ( 2 1 1 integration testing or after the product has been installed on the client s computer. In1 1
I l b
0th cases, the failure occurs after the change to module p has been completed. There tl.1 ! I :
t 1 I no longer is any apparent Iink between the change to module p and the overlooked 'I4! i . .l
I : convsponding change to module q. The fault therefore may be hard to lind. : liI I Ii
.
i d i n in which modules have high cohesion and low coupling is a nl 1 Given that a es g
1 1 i ' bl y good design
,
the obvious question is, How can such a design be achieved? Becausel
.1 l this chapter is devoted to theoretical concepts surrounding design
,
the answer to theI
I! :
r cluestion is presented in Chaoter l3. In the meantime, those nualities that identifv tl

t
'
: k '*
'
''' '*' '* '*'
.
; i ' a good design are examined further and resned. For convenience, the key dehni- ili I l
! i tions in this chapter appear in Figure 7. l 4, together with the section in which each e
1 :
'
1
! ! dehnition appears. 7
l . !
! . . tl
!
'
'
'
,
:
:
1 i
I ' . 1
.
al
:
l i ! ; y4 paya Extapsu. ATI@N1 1 l
,
*
i ; :

! ! ! , Consider the problem of designing an operating system for a Iarge mainframe com-
' 1 1 j$ i (
y puter. According to the specifications, any job submitted to the computer is classified
! j I . .
1 j as of high priority, medium priority, or low priority. The task of the operating system; 1
; 1 l ' j is to decide which job to load into memory next', which of the jobs in memory gets
j 'i'
;
: 1
'
,
.
'
!
. i ' ' ,
k
Please purchase Image To PDF Converter on to remove this message, thank you.
r
'
: 1 1 .
'
.
M DATA ENCAPSUGTION 1@5 1
the next time slice and how long that time slice should be', and which of the jobs that
has highest priority. In performing this scheduling, the operating lrequire disk access
system must consider the priority of each job; the higher is the pliority, the sooner l
)
'
.
'

''
that job should be assigned the resources of the computer. One way of achieving this . Il
is to maintain Separatc jOb Qtletles fOr each job-priority level. The job queues have I l
to be initialized, and facilities must exist for adding a job to a job queue when the 1
job requires memoly CPU time, or disk access as well as for removing a job from a
queue when the operating system decides to allocate the required resource to thatjob.
To simplify matters, consider the restricted problem of batchjobs queuing up for(
'
,
memory access. There are three queues for incoming batchjobs, one for each priority$
' level. When submitted by a user, a job is added to the appropriate queue; and when l
'
. j
the operating system decides that ajob is ready to be run, it is removed from its queue l l
.
'
.
I j
,
and memory is allocated to it. : l
7
This portion of the product can be built in a number of different ways. One I l .' )
'
!
possible design, shown in Figure 7. 15, depicts modules for manipulating one of the l
' three job queues. A C-like pseudocode is used to highlight some of the problems that i
can arise in the classical paradigm. Later in this chapter, these problems are solved !
'
using the object-oriented paradigm. : !'
'

t consider Figure 7.15. Function initialize-iob-queuez in module m-1 is respon- . j
.
* I '
sible for the initialization of the job queue; and functions add Iob
-
to
-
queue and : Ig -
'
remove iob from queue in modules m 2 and m 3, respectively, are responsible 1l1- -
!
if ) for the addition and deletion ofjobs. Module m-1 23 contains invocations of all three 1 !
rt functions in order to manipulate thejob queue. To concentrate on data encapsulation, i jI
! issues such as underflow (trying to remove a job from an empty queue) and overiow ly 1
e @ (trying to add a job to a full queue) have been suppressed here, as well as in the'
;
t t remainder of this chapter.1
n i The modules of the design of Figure 7. 15 have low cohesion, because actions on
. - p l
.e , thejob queue are spread all over the product. If a decision is made to change the way j I
'
ob queue is implemented (for example, as a linked list of records instead of as a i; l
,
d ' , l - j
'
linear list), then modules m 1 , m 2, and m 3 have to be drastically revised. M odule ) l
a m
-
1 23 also has to be changed', at the very least, the data structure dehnition has to ! 'r
.

k 1 (
z ; be changed. 1
i 1
te
'
Now suppose that the design of Figure 7.16 is chosen instead. The module on i j
y the right-hand side of the hgure has informational cohesion (Section 7.2.7) in that
i- 2 it performs a number of actions on the sam e data structure. Each action has its own
I fkon in Figurerh entry point and exit point and independent code. Module m
-
encapsu a
. 7.16 is an implementation of data encapsulation, that is, a data structure, in this case
the job queue, together with the actions to be performed on that data structure.
An obvious question to ask at this point is, W hat is the advantage of designing !
a product using data encapsulation? This will be answered in two ways, from the ' ':
-
viewpoint of development and from the viewpoint of m aintenance. !
5
'
()
'
1
1- . I
rd ' ; !
2For added clorifs the underscore is used in function names Iike initialize iob-queue to highlight that the I 2 I
7l1 '
( s@ruc@ured paradigm is used in @his section. When the obiect-oriented poraéigm is used in tlne next section, ! I
' the corresponding method is named initiulizeloboueue. '
,
1t

s l
1E
I
: !
( .1
!
Please purchase Image To PDF Converter on to remove this message, thank you.
.
,
1
I , ! .
1 : ! ;
l , : ':
i ' Il 1
I l .1
k j j 1@l t H A p # E R y * From M odules Io Obleds
; j ë E
( !
! I ; j m 1 ,
I I 1
:
l 1 . 5 ,
jë ' t
'
'
, .
'
; 1 l
! 1 (1 r ' j definition of
!

t job-queue
1 ! '
- i '5 1
.
! . t !
'
.
2 '
j initialize-job-queue ( )1
'
l 1 I i I l
i ! !1 ' t
J
E I
. : ! : :
t 1 ' @ @ .l ' : )i
t ' . )i
I ) ' I .
; I I . '
! l ! i ' m
-
2 m-a)
'
!
: .I i!
r
'
' ! i '! ! ' ::
t t 1 finition of definition of '! ?
.

. r . de
I 1 j ' 1 ! job-queue job-queuel
i ! I 1 )li
d
li
'
'
-
'
-
'
l 7 ' dd job
-
to-queue (job j) remove-job-from-queue (job j) ., ; ; a - ,1 j .
y ,
'
.
( .(
,.
! ! . : : : : : '
i . i * * @ *
; j g . ' j )
à
'
.
.
i )
-
$
,

) ! i , m-laa
j ' . . :i
,
-i i
.
! :
I 1 i ' . definition of 'I'i
I
1! ) i iob
-
queuei I !
l j .
'
I () 1 h l dd.
I ' i ( .
;j! I ( job job-a, job-b; . q,1 1
!
1
1 1 'j ' :
.
:
.
i 1 h ; ! rr
l l .: , initialize-job-queue ( ); ',
I l 1 ' i , ad( 1
,
1 l .: :. ' i sl
.
t l (jtj job
-

to-queue (job-al; d(i j 'r . ! a -I rI ( : :
tet * *
1 r i j t) from
- queue (job-bl; Irj 1 : remove-jo -
' j1 l : : re
j ; i . .
: .
j ) tj,l
I i . ' kt
't . . I '
j r Flgure K15 One possible design of iob queue portion of operating system. , th
1 : ' j .
k e;
j ! : : L ji #;
.
!$ : h , ; K*a PATA ExtApsutx,lox Aup ppoputv pwxkop of
:1 ; . dl1
'
i ;
! $ j 'j Data encapsulation is an example Gabstraction. Returning to thejob queue example, . thl .;
1 j i adatastructure (thejob queue) has been defined, togetherwith three associated actions ;
i ( 1 ' i (initialize thejob queue
,
add ajob to the queue, and delete ajob from the queue). The tvl ) i
, 'j ; : ,
' i k
'
.
I; ! ;
.

'
l
Please purchase Image To PDF Converter on to remove this message, thank you.