a laboratory for teaching object-oriented thinking.mht

十篇国外的重要资料

to where=20
they will put it when completed.=20
<P>Design with the cards tends to progress from knowns to unknowns, as =
opposed=20
to top-down or bottom up. We have observed two teams arriving at =
essentially the=20
same design through nearly opposite sequences, one starting with device =
drivers,=20
the other with high-level models. The problem demanded a certain set of=20
capabilities which both teams discovered in the course of fulfilling the =

requirements of the design.=20
<P>We suggest driving a design toward completion with the aid of =
execution=20
scenarios. We start with only one or two obvious cards and start playing =

"what-if". If the situation calls for a responsibility not already =
covered by=20
one of the objects we either add the responsibility to one of the =
objects, or=20
create a new object to address that responsibility. If one of the object =
becomes=20
too cluttered during this process we copy the information on its card to =
a new=20
card, searching for more concise and powerful ways of saying what the =
object=20
does. If it is not possible to shrink the information further, but the =
object is=20
still too complex, we create a new object to assume some of the=20
responsibilities.=20
<P>We encourage learners to pick up the card whose role they are =
assuming while=20
"executing" a scenario. It is not unusual to see a designer with a card =
in each=20
hand, waving them about, making a strong identification with the objects =
while=20
describing their collaboration.=20
<P>We stress the importance of creating objects not to meet mythical =
future=20
needs, but only under the demands of the moment. This ensures that a =
design=20
contains only as much information as the designer has directly =
experienced, and=20
avoids premature complexity. Working in teams helps here because a =
concerned=20
designer can influence team members by suggesting scenarios aimed =
specifically=20
at suspected weaknesses or omissions.=20
<P><A name=3Dexperience>
<H3>4. Experience</H3></A>One of the contexts in which we have used CRC =
cards is=20
a three-hour class entitled "Thinking with Objects," which is intended =
for=20
computing professionals who have programmed, but whose jobs do not =
necessarily=20
involve programming every day. The class proceeds by introducing a data =
flow=20
example (a school, with processes for teaching and administration) which =
is then=20
recast in terms of objects with responsibilities and collaborators (such =
as=20
Teacher, Janitor, and Principal). The class then pairs off and spends an =
hour=20
designing the objects in an automatic banking machine, an exercise =
chosen=20
because of everyone's familiarity with the application and its ready =
breakdown=20
into objects to control the devices, communicate with the central bank =
database,=20
and control the user interface. (See the appendix for a sample =
solution.) The=20
exercise is followed by a definition of the terms "class", "instance", =
"method",=20
and "message", and the class concludes with a brief discussion of the =
history=20
and features of a variety of object- oriented programming languages.=20
<P>In teaching over a hundred students this course we have encountered =
no one=20
who was unable to complete the exercise unaided, although one pair in =
each class=20
usually needs a few hints to get started. Although we have done no =
follow-up=20
studies, the class is considered a valuable resource in the company and =
is still=20
well attended with a long waiting list almost a year after its =
inception.=20
<P>We have also asked skilled object programmers to try using CRC cards. =
Our=20
personal experience suggests a role for cards in software engineering =
though we=20
cannot yet claim a complete methodology (others <A=20
href=3D"http://c2.com/doc/oopsla89/paper.html#references">[5][6]</A> =
have more=20
fully developed methodologies that can take advantage of CRC methods). =
We- know=20
of one case where finished cards were delivered to a client as (partial) =
design=20
documentation. Although the team that produced the cards was quite happy =
with=20
the design, the recipient was unable to make sense of the cards out of =
context.=20
<P>Another experiment illustrates the importance of the context =
established by=20
the handling and discussing of cards. We had videotaped experienced =
designers=20
working out a problem similar to the bank machine. Our camera placement =
made=20
cards and the designers' hands visible but not the writing on the cards. =
Viewers=20
of the tape had no trouble following the development and often asked =
that the=20
tape be stopped so that they could express their opinions. The most =
telling=20
moments came when a viewer's explanation required that he point to a =
blurry card=20
in the frozen image on the screen.=20
<P>Finally, we have used CRC cards to advantage in explaining complex =
designs. A=20
few minutes of introduction is sufficient to prepare an audience for a =
card=20
based presentation. Cards can be made out in advance or written on the =
spot. The=20
latter allows the complexity in a design to be revealed slowly, a =
process=20
related to Dave Thomas' "lie management". The cards are being used as =
props to=20
aid the telling of a story of computation. The cards allow its telling =
without=20
recourse to programming language syntax or idiom.=20
<P><A name=3Dconclusion>
<H3>5. Conclusion</H3></A>Taking our perspective as a base we give =
novices and=20
experienced programmers a learning experience which teaches them =
something=20
valuable about objects. CRC cards give the learner who has never =
encountered=20
objects a physical understanding of object-ness, and prepares them to =
understand=20
the vocabulary and details of particular languages. CRC cards also give =
useful=20
and convincing experience with objects to those who has learned the =
mechanisms=20
of objects but do not yet see their value.=20
<P>Ragu Raghavan <A=20
href=3D"http://c2.com/doc/oopsla89/paper.html#references">[7]</A> has =
said that in=20
the switch to objects strong programmers become stronger, but weaker =
programmers=20
are left behind. Using the cards in group settings we found that even =
weaker=20
programmers, without a deep understanding of objects, could contribute =
to object=20
designs. We speculate that because the designs are so much more =
concrete, and=20
the logical relationship between objects explicit, it is easier to =
understand,=20
evaluate, and modify a design.=20
<P>We were surprised at the value of physically moving the cards around. =
When=20
learners pick up an object they seem to more readily identify with it, =
and are=20
prepared to deal with the remainder of the design from its perspective. =
It is=20
the value of this physical interaction that has led us to resist a=20
computerization of the cards.=20
<P>It is just this problem-integrating the cards with larger design=20
methodologies and with particular language environments, that we feel =
holds the=20
most promise for the future. The need to retain the value of physical=20
interaction points to the need for a new kind of user interface and =
programming=20
environment as far beyond what we have today as our current systems are =
beyond=20
the tool-oriented environments of the past.=20
<P><A name=3Dreferences>
<H3>References</H3></A>[1] DeMarco, T.: Structured Analysis and System=20
Specification, Yourdon, 1978.=20
<P>[2] Smalltalk-80 image, Xerox Corp, 1983.=20
<P>[3] HyperCard manual, Apple Computer Inc.=20
<P>[4] Cunningham, W. and Beck, K.: "A Diagram for Object-Oriented =
Programs," in=20
Proceedings of OOPSLA-86, October 1986.=20
<P>[5] Wirfs-Brock, R. and Wilkerson, B. "Object- Oriented Design: a=20
Responsibility-Driven Approach," submitted to OOPSLA '89.=20
<P>[6] Reenskaug, T.: "A Methodology for the Design and Description of =
Complex,=20
Object- Oriented Systems," technical report, Center for Industrial =
Research,=20
Oslo, Norway, November 1988.=20
<P>[7] Raghavan, R.: "Panel: Experiences with Reusability," in the =
Proceedings=20
of OOPSLA '88, October, 1988.=20
<P><A name=3Dappendix>
<H3>Appendix</H3></A>Here we provide a sample solution to the banking =
machine=20
problem discussed in section 4.=20
<P>Account and Transaction provide the banking model. Note that =
Transaction=20
assumes an active role while money is being dispensed and a passive role =

thereafter.=20
<P><IMG src=3D"http://c2.com/doc/oopsla89/fig3.gif">=20
<P>Transactions meet their responsibilities with the aid of several =
objects that=20
serve as device drivers. The Dispenser object, for example, ultimately =
operates=20
the dispensing device.=20
<P>The CardReader object reads and decodes the information on the bank =
card's=20
magnetic strip. A common mistake would be to itemize all of the =
information=20
stored on the bank card. Card encoding formats must certainly be well =
thought=20
out and documented. However, for the purpose of designing the objects, =
we need=20
only identify where that knowledge will be placed in the program.=20
<P><IMG src=3D"http://c2.com/doc/oopsla89/fig4.gif">=20
<P>The RemoteDataBase drives the communication lines and interprets data =

transmitted across them. It creates Account objects and consumes =
Transaction=20
objects.=20
<P>The device drivers signal exceptional or asynchronous events by =
adding Event=20
objects to a shared queue.=20