The Tinkertoy™ Exercise for Motivating
Formal System Modeling

Leslie J. Waguespack, Jr., Ph.D.
LWaguespack@Bentley.edu
Computer Information Systems Department, Bentley College
Waltham, Massachusetts, 01254 USA
ABSTRACT
Effective system modeling is a critical skill and essential learning for every information systems professional – undergraduate and graduate. The novice finds the modeling task deceptively difficult. Complicated by multiple stakeholder perspectives / interpretations, large amounts of information gathered and transmitted, and an almost totally abstract problem domain, system modeling relies heavily on formal, disciplined language and representation. The benefits of formality and discipline are not easily impressed upon the novice student. A standard academic course setting must be so compact as to render most classroom practice trivial. The “Tinkertoy® Construction” exercise is a tangible and effective metaphor for the systems analysis and design task. It highlights and explains the challenges of disambiguation, domain knowledge capture, and efficient team communication in a non-threatening, profoundly engaging and portable experience. Once lived, the exercise evinces insight that can anchor virtually every aspect of the systems analysis and design syllabus.
Keywords: modeling, pedagogical learning devices, systems analysis and design curricula, IS curricula.


1.  INTRODUCTION
At the core of IS and IS education is systems analysis and design (Gorgone, Davis, Feinstein, Longenecker 2002). At the core of systems analysis and design is modeling (Brooks 1987, Waguespack 2005). The ability to identify, describe, explain and communicate one’s understanding of a problem, its context, the concerns and the desired results defines the function of systems analysis and design (Hoffer, George, Valacich 2005). All IS professionals (analysts, designers, architects, programmers, managers – all stake holders) need a firm grasp of modeling if for no other reason than to be an effective consumer of system documentation. Systems analysts, designers and architects need to be effective authors of system documentation and the models that they enfold.
The pivotal position that modeling holds in the education of IS professionals leads to the importance of motivating and training IS students in the role and practice of modeling. This is a traditionally difficult task because of the abstract nature of information system content and operations in general and because of the breadth of issues that come into play in describing an effective information system. This paper presents a description and discussion of a pedagogical device to aid in student preparation for the learning of formal modeling. The device evokes a physical and emotional participation by the students that imprints an experiential memory of the modeling activity. The device also reveals many subtleties of the communication challenge of system description that shows the benefits of formal modeling syntax and semantics found in contemporary modeling tools (DFD, ERD, UML, etc.).
2.  PEDAGOGICAL DEVICE DESIGN
There are two particular needs for this learning device to satisfy. The first is learning opportunity fit and the second is metaphor casting potential.
Learning Opportunity Fit
Systems analysis and design looms remarkably amorphous in the novice mind of the graduate or undergraduate learner. It is a conglomerate of common sense, sage experience and arcane diagramming forms and formats. (This is perhaps even more pronounced for those students with some experience at programming where the compiler or integrated development environment readily indicates right and wrong constructions.) Modeling pedagogy involves two spheres of ignorance to be overcome: 1) the problem which is the object of analysis and design and 2) the system of modeling abstractions and representation syntax with which to portray the former. This is Brooks’ classic dichotomy of essential and accidental difficulties (Brooks 1987). Finally, these pedagogical obstacles need to be recognized and targeted at the outset (usually in a single, early class period) lest the time lost to poor or absent motivation leave the student in a persistent state of “catch up” as the intricacies of abstraction and representation flood in the ensuing course content.
The pedagogical device must fit the opportunity. It must happen at or near the introduction to modeling. It must be terse – preferably fitting comfortably within a single class meeting. It must engage the students (Lowman 1995). It needs to be active rather than passive; and thus imprint a “physical and visual experience” on each student, “staining” a persistent recollection of the topic introduction (Arnheim 1969). It should be non-threatening; but it should evoke some benign emotional response to reinforce the memory. Ideally it should appear on the surface to be intuitively obvious in scope and structure, but possess sufficient sophistication to support the metaphor casting to follow.
Metaphor Casting Potential
In addition to fitting into the structure of the course in terms of time and motivation the learning device needs to provide a means of casting participants’ experience forward onto the relevant course content to follow in the days and weeks ahead. To achieve this the learning device should have the characteristics of a metaphor such that the events and actions of the device portend the formal aspects of modeling to be taught. Metaphor is used here in perhaps a more technical manner than most are familiar. That is that here it goes beyond a “play on words” as most use the term. We use the term in the manner explained by the architect Christian Hubert as follows (Hubert 2006):
Metaphors depend on drawing attention to the similar in the apparently dissimilar, and they trade on secondary comparisons between the two terms. Max Black describes the "interaction" model of metaphor as not reducible to a literal paraphrase. [...] Thus the metaphor "selects, emphasizes, suppresses, and organizes features of the principal subject by implying statements about it that normally apply to the subsidiary subject (Black 1962).
Our metaphor should parallel aspects of modeling and communication that motivate the need for abstractions and formal syntax. The learning device with a well-crafted metaphor serves as a stable reference for both instructor and student when we wish to contextualize the abstraction and representation content as the course progresses.
3.  THE LEARNING OBJECTIVES
The primary objective of this learning device is to model the communication aspects of the systems analysis and design task of the software development life cycle as a concrete experience of a) identification, b) description, c) explanation and d) communication.
Identification is one of the first challenges in systems analysis, the “naming” of artifacts (physical, abstract and dynamic). Terminology and the ability to focus both the clients’ and the developers’ attention on the same business issue is critical to clear and effective communication.
Description requires either the creation of (or reference to) shared experience between the client / developer team with the problem domain being analyzed. The predisposition of a shared experience permits “a shorthand” of expression and shared expectation in the modeling discourse. If a shared experience does not exist the analysis process must begin with the construction of a basic model of the problem domain in order to create a shared experience.
Explanation of trivial facts is simple (sometimes trivial). As the complexity of the domain of analysis grows, the complexity of the structure of explanation also grows. To meet this challenge analysts rely on formal syntax and diagramming semantics to organize and normalize the expression of assembled information.
Communication even in the presence of perfect domain knowledge among clients and analysts may fall short of effective or efficient information collection, documentation and/or cataloging which in turn renders shared understanding impossible. The communication process itself must be carefully conceived, managed and safeguarded lest the best efforts of gathering and understanding aspects of the problem domain are garbled and lost in translation.
4.  THE LEARNING DEVICE
The essence of this learning device is the placement of the student in a live experience where the challenges of each of the four modeling activities above are concretized making them self-evident and available for discussion and evaluation.
The learning device is based on communicating requirements for the construction of assemblies using a wooden set of Tinkertoys®.
(Stonemason Charles Pajeau and partner Robert Petit dreamed up the "Thousand Wonder Toy" in 1914 after watching children create endless abstract shapes with sticks, pencils, and old spools of thread. Adding holes on all sides of a round wooden wheel sized for sticks included in the set, they named their creation Tinkertoys®. [Wikipedia 2006]. These have been used in a variety of scientific and pedagogical adventures [Dewdney89])
A series of five abstract assemblies are constructed using a standard set of wooden Tinkertoys®. These assemblies represent real world systems of parts, connections, relationships and assemblies. Each assembly is photographed with varying degrees of detail (color, single perspective, multiple perspective, etc.).
Each of the pictures of abstract assemblies is presented in turn to a different set of three students in what is called an experiment. The complexity of the assembly increases with each experiment. One of the three students is designated as the guide who is allowed to see the picture of the assembly in each experiment and to give instructions enabling the physical reconstruction of the pictured assembly. The second student is the builder who sits at a table with the same Tinkertoy® set used to create the pictured assemblies. The builder is not allowed to speak or see the assembly picture until the end of the experiment. (The builder is in fact the only student who cannot see the picture.) The third student is the judge who indicates to the guide and the builder whether the ongoing reconstruction by the builder is consistent or inconsistent with the picture. The remaining students are asked to observe the behavior of each of the experiment participants. In each experiment constraints limit the form of communication the students may use. Each experiment is timed and is terminated after approximately 10 minutes.
The exercise is compact enough and sufficiently self-contained to fit many different pedagogical or curricular situations. Once lived, the exercise evinces insight that can anchor virtually every aspect of the systems analysis and design discussion or syllabus.
The following section presents the visuals used and attempts to demonstrate the learning device in action. Reading about the exercises is a pale substitute for observing or participating in the learning process described.
5.  “PLAY BY PLAY”
A brief introduction to the topic of modeling may be used to set a general context for the series of experiments at which point having prepared the setting as described above the experiments begin.
Experiment One
The first experiment begins with the instructions and picture in Figure 1 below.
Experiment One provides an intentionally obscure depiction of the construction to be reproduced. The lack of primary colors creates an added challenge in identifying particular Tinkertoy® parts for the construction effort. Interestingly enough, not only are the guide and builder challenged, but also the judge is hard pressed to determine if the attempt by the builder is “consistent” or not since the length of the rods is almost impossible to judge without color queues.

Figure 1 – Experiment One Assembly
The “writing” requirement for instructions (unique to experiment one) is particularly onerous for most students. Although this assembly is the least complex of any in the experiments, the “natural language” writing requirement makes the exercise almost impossible.
As the ten-minute time period draws down, a volunteer calls out the remaining minutes.  “Time keeping” on each experiment introduces some artificial pressure on the construction team – a stress not uncommon in “real” systems development.  Depending on the success of the participants this experiment may be terminated before the construction is complete or extended to take advantage of the moment. As students become more involved, they often become animated and boisterous which lightens the atmosphere and diffuses any tension. After the experiment the class and participants are asked to offer their observations of the process: communication, challenges and feelings (particularly those of the participants).
Experiment Two
The introduction of color in experiment two resolves some of the identification issues found in experiment one and improves the communication between the three participants. (As an interesting twist, however, in one class the guide was color-blind and the introduction of color was not an improvement for him. This occurrence led to an interesting discussion about client versus developer perspective as well as citizens with disabilities.)

Figure 2 – Experiment Two Assembly
Experiment Three
Experiment three introduces the concept of disciplined terminology. The participants share a common “name” for each of the parts. However the names are intentionally chosen to be less than intuitive.

Figure 3 – Experiment Three Parts List
A copy of the parts list is provided to the builder so he / she can refer to it without looking at the assembly picture referenced by everyone else in the class.
Besides the use of a parts list to structure identification and description, this construction introduces the potential of some shared domain knowledge. Virtually every student participant in this experiment chooses to describe the upper part of this construction as either a “propeller” or “helicopter” subassembly. This introduces the concept of projecting experience from one domain into another as a means of “describing by metaphor.” At the same time that this descriptive approach imparts quite a bit of information quickly (e.g. rotation, propellers, and hub), some students make erroneous assumptions about the guide’s intent (i.e. whether the vanes of the “propeller” rotate in a vertical rather than the horizontal plane) that can actually retard a shared understanding.

Figure 4 – Experiment Three Assembly
Experiment Four
Experiment four mirrors the previous, but introduces a parts list with names that are more intuitive (Figure 5 below).

Figure 5 – Experiment Four Parts List
The use of “intuitively obvious” names for parts almost always improves the efficiency of communication because less individual description is needed by the guide to identify the part to be manipulated. The names also convey some characteristics of the part’s “dynamic potential” in some construction (e.g. pulley, shaft bearing, or axle cap) which in many instances provides “hints” to the use of the part in a larger assembly.
In addition this experiment allows the guide to view the progress of the builder. With this added knowledge of the builder’s perception of the guide’s direction, the guide is able to address misconceptions promptly and in some cases adjust the description to merge with the builder’s evolving “model” of the final product. This arrangement is indicative of “prototyping” as a systems analysis and communications tool.

Figure 6 – Experiment Four Assembly Views
In this variation it is common to find the team working on this construction referencing the previous team’s experience with experiment three, particularly in referring to a “two bladed propeller” rather than the “four bladed propeller” as was seen earlier. The use of previous experience and familiarity with the predecessor teams’ effort provides another discussion opportunity.
Another twist is to have the students interrupt construction and start over at some point – a demonstration of “rework,” having to retrace both the analysis and construction steps. It is remarkable how frequently the builder becomes impatient with the guide’s directions and their pace of instruction delivery. It is common for the builder (after some frustration with not understanding the guide’s directions) to simply begin building “something” rather than to sit, waiting, and “do nothing” – another reflection of the “real world!”
Experiment four is the first time that multiple perspectives are provided. Almost every time the experiment is conducted, multiple perspectives improve the fidelity between the builder’s attempts and the guide’s instructions primarily because the guide’s instructions seem to be much more internally consistent and clear. As the objective is clearer, so the judge’s performance also tends to improve.
Experiment Five
Experiment five introduces a “red herring.” By now the students who have been spectators of the previous four experiments have developed quite a bit of insight and confidence about their prospects of building the construction. Some even lobby to serve in a specific team role. They have developed theories for overcoming the difficulties experienced by the teams that have gone before.

Figure 7 – Experiment Five Assembly
As a direct reference to the need for feasibility analysis in development projects, the picture that the team is given to reproduce is made from a set of Tinkertoys® with more parts than the set they are given to build with. To date only one team has ever performed an “inventory” of the available parts prior to commencing construction.  Most expend several minutes of enthusiastic and confident work only to discovery near the “end” of the process that their task is not possible given the existing constraints.
The exercise session concludes with a recap of the issues surfaced by the class.  Depending on the available time, students are asked to find examples in the experiments of the four aspects of modeling listed in the learning objectives. The Tinkertoy® construction exercise highlights and demonstrates the challenges of disambiguation, domain knowledge capture, and efficient team communication.
6.  EXPERIMENT EXTENSIBILITY
The Tinkertoy® exercise is replete with opportunities to discuss additional systems development metaphors that may be specific to the modeling context of the course in which it is used. The following are but a few examples:
* The toy parts themselves are metaphors for programming language constructs, syntax, components, and subsystems.
* The construction task can be augmented with prefabricated subassemblies of parts denoting modules, components or “web services” with the potential to explore cohesion and coupling characteristics.
* The interoperability of some of the parts (the variety of round hubs) can demonstrate a degree of inheritance / polymorphism as some hubs connect at 90º, others connect at 90º and 45º, and others connect at 90º and 45º as well as spin which makes them interchangeable with lesser capable parts.
* The individual parts can be evaluated for their potential for reuse (versatility and contribution).
* The students can be tasked to conceive additional parts for the set to achieve various “architectural” extensions for expanded construction opportunities.
* The introduction of “movement requirements” presents the possibility of exploring dynamic aspects of modeling and in particular the challenge of describing dynamic behavior with natural language versus formal modeling dialects.
7.  SUMMARY
Exploring the intrinsically abstract elements of modeling and teaching the tools and syntax for representing the same in IS education is challenging. But, these are essential to systems analysis and design as is motivating students to take learning them seriously. The pedagogical device presented here demonstrates the potential for creating custom exercises that enable and encourage students to map the physical and visual experience in the exercise to the abstractions and concepts of modeling, systems analysis and design. (Although the potential of this approach appears obvious, confirmation requires formal validation beyond the scope of this paper.)
We discussed the underlying pedagogical basis and structure of the device and the details of its application. The metaphor at the heart of the learning device is readily extensible permitting the moderator to accentuate any of a variety of relevant IS issues that emerge during the experiments.
The device has been used by three teachers in America and Europe with undergraduate and graduate IS and business students. The device has also been used in training with practicing IS professionals. The experience is somewhat different in each group – a characteristic that seems to keep the exercise fresh and interesting each time a new group experiences it. Both informal and formal (anonymous course reviews) feedback by teachers and students alike indicate that Tinkertoy® exercise is an engaging, satisfying and edifying experience.
8.  ACKNOWLEDGEMENTS
I wish to offer special thanks to my colleagues, Bill Schiano and Ed Kaplan who have used the exercise in their IT and business classes over the past two years and offered several helpful suggestions for improving the Tinkertoy® exercise. Foremost, the author wishes to recognize the contribution of the hundreds of students who have bravely and enthusiastically participated as subjects and contributors in the development of this learning device.
9.  REFERENCES
Arnheim, R., (1969), Visual Thinking, University of California Press, Berkley, CA.
Black, Max, (1962), Models and Metaphors. Ithaca, N.Y.: Cornell University Press.
Brooks, F. P. (1987), “No Silver Bullet:  Essence and Accidents of Software Engineering,” IEEE Computer (April), 10-18.
Dewdney, A. K. (1989), “Computer Recreations: A Tinkertoy computer  that plays tic-tac-toe.” In Scientific American, pages 120-123, October, 1989.
Gorgone, John T., Gordon B. Davis, Joseph S. Valacich, Heikki Topi, David L. Feinstein, and Herbert E. Longenecker, Jr. (2002), Model Curriculum and Guidelines for Undergraduate Degree Programs in Information Systems, Association for Computing Machinery (ACM), Association for Information Systems (AIS), Association of Information Technology   Professionals (AITP).
Hoffer, J., J. George & J. Valacich, (2005), Modern Systems Analysis & Design (4th Ed.), Upper Saddle River, NJ: Pearson Education, Inc.
Hubert, C., (2006), “Contents Under Pressure – A Hypertext in Progress by Christian Hubert,” June 2006, www.christianhubert.com/hypertext/index.htm 
Lowman, J., (1995), Mastering The Techniques of Teaching 2ed, San Francisco, CA. Jossey-Bass Inc.
Waguespack, L J.  (2005), Metaphors, Polymorphism, Domain Analysis and Reuse: Teaching Modeling in the Object-Oriented Paradigm.  In The Proceedings of ISECON 2005, v 22 (Columbus OH): §2332. ISSN: 1542-7382.
Wikipedia, (2006), http://en.wikipedia.org/wiki/Tinkertoy