Whiteboards, Flip Charts, and JAD Workshops JOST OBJECT-ORIENTED model- Mirco nti analysts, designers, or programmers using informal sketches on sheets of paper, fi charts, or whiteboards, If they are lucky, developers may also be able o exeate and maintain thee diagrams with an upperCASE tool that provides editors for the relevant object-oriented diagrams (e.g., semantic nets, modified entity-relationship diagrams, inheritance diagrams, interaction oF collab- oration diagrams state transition diagrams) Interaction with other developers is often limited to occasional meetings and peer re~ views. When multiple developers perform analysis and design as a group, they may sso (or instead) use Class-Responsibilty-Col- Inboration (eRC) cards to capture informa- tion about individual classes. Tn either ease, the analysis and design ae too often done by software engineers with tele domain exper- tise and limited aceess to domain experts or the users ofthe system, ‘Most of the time, the requirements, design constraints, quality goals, and customer de- sires that developers need to properly model the aplication come via written requirements from customers who often do not know what they or the user really want until aftr the ist version ofthe application i fede. This article recommends using white- boards and flip charts to capeure the initial object-oriented models during joint appica- tion development (JAD) workshops involving domain experts and users as well a8 analysts and designers. Although JAD workshops are reasonably common in the information engi= neering (IE) community, they ae stil only seldom used for object-oriented requirements elicitation, requirements analysis, and logical design. JAD workshops are now even more useful Because of the directness and com= 4 smith as Feet ites cnn an tig oie ‘enol He eloped nd inins ADN, a fou eatin 00 deren et. ei he author of nr aero Rumen AA mo GEA. DOE ‘A Str Enaar Regs an ner Oner> Dern Mars Sirs, mo Proce He ean be mache thane Sot Techy Spit 810 ste Se, Fr Way, 4807, 18 AS. 728, 7865 38t5eearpaene com pleteness of object modeling and the iterative and incremental nature of object-oriented de- velopment cycles. ‘The approach recom- ‘mended by this article has been proven to be very successfil for the rapid development of quality object-oriented models, (0-0 JAD REQUIREMENTS ELICITATION AND MODELING WORKSHOPS Most object-oriented development methods NEEDSEDESIRES —_REQUIAMENTS| aa do not adequately address requirements elic- tation. Instead, they assume the prior exis- tence of well-documented formal customer requirements to be analyzed by developers during object-oriented requirements analysis, Such customer requizements, if they exist, are almost always textual, vague, incomplete, in consistent, out-of-date, and ambiguous, Un- fortunately, any requirements models pro- vided by the customer ace often still in the form of functionally decomposed data-flow liagrams or traditional entity lationship di- grams that ignore inheritance and the en- capsulation of data and operations. Even if they exist, such obsolete models are not opti~ smal inputs for analysis and design, especially if the object paradigm has been chosen. ‘The current document-driven process of- ten separates requirements generation, spec> ification, and analysis into disjoint user, cus- tomer, and developer activities. This is not only ineffective, i also promotes “waterfall” development, which is inconsistent with the incremental and iterative nature of the ob- ject-oriented development paradigm and development eycles. As illustrated in Figure 1, the resulting communication of requite- ments is inefficient and may easily become garbled between the domain experts, cus- tomers, and analysts/designers when they belong to separate organizations" and all in- formation must be formally ‘passed over the wall” to the next group, Incremental and iterative development is preferable, because many customers do not accurately know what they want until pre~ sented with functioning prototypes to eluci~ date, verify, and validate their desires, needs, When softwar ir bring developed for an cena | organisation (eg, the government) the eastmerie ‘often an experi conte isis rather than in | the aplication domain, May-June 1994and requirements. In turn, this is one of the main reasons why “maintenance” typically re~ ‘quires 70%-90% of the total effort expended ‘on many applications. An object is far more than merely an encapsulation of data (atrib= utes) and funetions (operations) on that data Iisa madel ofan application thing. To prop erly model reality, an objec often must also encapsulate exceptions, rales (c.g. invari~ ants), and component objects. Its impossi- ble to develop good models of things with= ‘out the necessary domain expertise of the NABLES_p0_DISABLES Ta thing being modeled. tis critical to have do- ‘main experts and uses involved in the mod~ eling process if good modes are to be pro- duced within a reasonable time frame, Otherwise, software engineers must all too often guess at the users intent from written requirements in a domain they do not truly understand. Whereas the domain experts bing needed domain knowledge, analysts and designers can use object technology to "TURNS_ORL_AND_TURNS_OFF PRESSURE "THE_MRILTTPLEXTNG_ 510 HARIARE_VIA sve "THE_ MULTIPLE DIGITAL T0_ANALOG_, FA rressune, CROCE, T MERSIRES ye PRESOIRE. OF ‘TWe_PRESSURE RES PRESSURE WARING wasas_DE_LOW., PRESSUR supsvsra4 Figure 2 Goneral Somantc Net (QBN) of THE_ Olt SUBASSEMBLY. Vou : Numer r recommend ways to perform business reengi- neering and ensure that inefficient manual processes are not merely automated as “Much of the high-level modeling should therefore be done during JAD workshops in Which JAD team members have adequate ex- pertse in object-oriented modeling and the pplication domain. Often, they require sys- tems and hardware expertise as well as soft- ware expertise. Thus, JAD team members should contain domain experts and users in addition to analysts and designers. JAD teams should be neither too small nor 100 large. Experience teaches us chat an op- ‘imum size should be between two and five total members. On the one hand, ifthe team is too small, iis difficult to ensure adequate expertise. Quality will suffer ifthe JAD team does not contain atleast two members to en sure adequate peer-evel review and iteration, (On the other hand, having too many mem= bers produces design by committee and low- cs productivity. JAD workshops provide many advantages cover using teams consisting only of develop. crs Inadaition to overcoming the previously mentioned problems, domain experts can get immediate feedback and answers to theit questions. By reforrnulting domain expertise inthe form of object-oriented models, do- main experts develop a deeper understanding oftheie domain and have a greater confidence thatthe developers understand their domain and needs. Object-oriented analysts and de- signers also get ongoing “eality checks” ofthe models, which also increases ther confidence, Different team members bring different per- spectves on the problem, increasing the rate of iteration and making peer reviews more productive. The formal dog-and-pony-show reviews become more efficent and contain fewer surprises. By alo including rapid pro totyping with a language such as Smalltalk, domain experts can alo obtain feedback fom executable models in near realtime. Object technology makes JAD workshops more practical. Object-oriented modeling techniques are more understandable to the domain expert and systems engineer because objects better model understandable parts of the application domain. For example, good object-oriented diagrams are more readable than data-flow diagrams. Hardware engi- neers often prefer semantic nets oF objeet- oriented entity relationship diagrams because of thei similarity to traditional hardware schematics, Figure2is an ADM General Se~ eo‘mantic Net (GSN) from an automotive dash- board application,? one of several types of ‘object-oriented diagrams that can be devel ‘oped. The GSN shows four software objects, their corresponding hardware devices as in- direct terminators, and the direct and indirect, links between them." (Once i is accepted that most of the high~ level modeling will occur during JAD work- shops, the next issue is how the modeling should be done to promote iteration and communication among team members who are not experts in object-oriented modeling. PROBLEMS WITH CRC CARDS AND UPPERCASE TOOLS No object is an island, Classes must be ana- lyzed and designed in terms of the services they provide to their clients and the services they require of ther servers.” Scenarios (eg. use cases), idioms, mechanisms, and other patterns involve multiple collaborating ob- jects and classes. Even an individual class consists of numerous interacting features, the ‘0 most important of which being its at- tributes and operations. Thus, during analy- sis and design, the relationships berween things are often as important asthe structure ‘of the things themselves. Because ofthis, almost all object-oriented iagrams consist of nodes (e.g. classes, states) connected by relationship arcs (eg., links, messages, transitions). It is not enough to merely ist the collaborators, as on CRC cards A graphical structure consisting of nodes and arcs should be depicted graphically. A single ‘object-oriented picture is literally worth a dozen CRC cards and pages and pages of code ‘when it comes to human understandabilty, "The sofhume sabusembly at the top of the GSN contains one visible concurrent object, the ol nd ‘hee hidden sequential objects connected by thee Tink, one of which is conditional, Ther hee hid den software objec az indict inked othe v0 hardware converters which in tum eink tothe Visible hardware senor, gauge and ight objects in the oil beste, which alba eacapeaates the ps ical moto oi objec. One ofthe important reasons to distinguish berveen software and hardware ob- jectson dhe diagrams that he direction ofthe inks ‘mong and contol ow between) te rftrare ob- ject is often the opposite ofthe direction of the Tinks among the hardware object “Thisis perhaps an oversimplication, because mes age may actualy be sed foe four dine prpowes: to request serie, to nippy dat, to provide not Seaton fan event, oto synchronize the thread oF contol of tro concent objet. 46 Te A single object-oriented picture is literally worth a dozen CRC cards. especially during JAD workshops when eff- cient communication between developers and domain experts is critical ‘Thus, most object-oriented analysis and design methods include models that are largely graphical. These models (See Fig. 2) use diferent diagrams to capture different views (eg, logical vs. physical or static vs. dynamic) of a system or its software. The scope ofthese diagrams also varies from the entire application (eg, context diagrams) t0 an individual class or object (eg, state transition diagrams, whitebox interaction diagrams) with the majority of diagrams documenting a smal, logiclly-related col- lection” of collaborating objects clases, and terminators. UppercAse tools exhibit several limita tions as initial tols for object-oriented analy- sis and design. They may (or may not) sup- port the specific diagrams of the project object-oriented development method. More important, they tend to inhibit inital e- quirements elicitation and interaction by pri marily being tool for single developers rather than for groups. I is difficult to gather a group of domain experts and developers around a single monitor. Even when the drawing is displayed by an overhead project, spontaneity is lost when additions and changes to the drawing must be funneled through the single person at the keyboard. Developers tend to spend too much time and effort trying to make the drawing look good before it stabilizes rather than concentrating on the evolving content of the drawing, Those not doing the drawing do not feel as much a part of the development process asthe person doing the drawing, who [atc dam angst tends to view the drawing as his or her own rather than as the product of the group. Be- cause one diagram often influences other di- agrams in real time, its important for sev eral diagrams to be simultaneously visible to the JAD team. This is easy to achieve with multiple whiteboards but difficult when re~ stricted to monitor, even with multiple win~ dows. WHITEBOARDS: Most of these problems are solved by initially using whiteboards instead of eRC cards and UupperCASE tools. Whiteboards are very cheap and easy for the entie JAD team to use, even for domain experts new to object technology. Whiteboards promote JAD team interaction and collaboration because all of the members of the JAD team ean see and use the white- board simultaneously. Whiteboards promote iteration because lite efforts invested in the diagrams. Team members fee fre to jump up and make changes to the evolving diagram. Everyone feels themselves tobe an active and valuable member ofthe team because they all take partin the development and modification of the models. By actively developing and it- exating the diagrams, the domain experts, users, and customers understand and buy into the resulting model Large whiteboards are preferable to flipcharts and chalkboards for drawing ob- jectoriented diagrams. Flipehars limit ier- ation and are too smal for typical diagrams, which may easly contain seven to fifteen nodes.* This is especialy true ifthe labels of| the nodes and acs ae to be easily read by JAD team members sitting across the room, Chalkboards ae very similar to whiteboards in many ways but do not allow the use of node cards (see below), because chalk dust prevents the taping ofthe cards tothe chalk Dour surface, During JAD workshops, team members incrementally develop the diagrams, one node or arcat a time. Because modeling is an ‘exploratory process, each diagram will usually ‘evolve through two or three iterations over several hours before stabilizing. Nodes must ‘often be moved around the diagram as initial relationships are replaced by new ones or the diagram is rearranged to avoid clutter and the crossing of lines The amr oes maybe ven lager rng the inal brintorningolater when dg bs jrewnoy be aed Mar June 1994T recommend node cards a a labor-saving device used to eliminate the need to con- seantly redraw and relabel nodes when they are moved around the diagram. Node cards are merely pieces of paper that have been preprinted with the icon’ fora node used on an object-oriented diagram (eg. a class or objet), When a new node is needed, a JAD team member selects the appropriate ed and uses tick et-ipped pen to label itn block leeers that cam be read from anywhere in the JAD workshop room. The card is then taped to the whiteboard and appropriate eelation- ship ares are drawn on the whiteboard, con- necting it with other nodes. 1 do net recommend listing responsibil ties, atsibutes, or operations on the node card. Initial modeling should be at a higher level of abstraction, level that treats objects and classes as software blackboxes. Listing resources on node cards also clutters up the cards (and digram), making the diagram di ficult to understand and the cards dificult to read from across the room. It also makes it difficult to usea standard-sized card, because some nodes would require larger lists of fea- tures than others. Also, once one stars list ing information auch a5 encapsulated ze- sources, when should one stop? Why not list exceptions, invariants, and part? T have re- cently removed such information from most ofthe diagrams of my ADM method because such information is best eaptured sing up- erCASE tool dialog boxes. Instead, ecom- :mend using ipchasts for informally capeur- Jing such information prior to its entry into a CASE tool ceposiory. Originally, I used large Post-it notes as node cards. Unfortunatly, they had several drawbacks. One had to either draw the icon shape on each Post-it note which took time, or pay an inordinate amount to have the Post-it notes preprinted with the sppropr- ateicon.* Amore serious aw was that Post it notes are only sticky along a thin stip at the top. The next day or after turing fom lunch, one often found part of one's design lying on the floor at the foot ofthe white- board. briefly taped the Post-it notes to the board, but quickly realized chat as engineer ingoverkill. Currently, I use the deawing tool ‘MacDraw to draw two large annotated icons * Often, the co i alo annotated with te meaning (Gps clas, jet, stat, operation) in smal leer se amemory ad for tear members who ave not yet ‘memprized ll he eons. Vouse 1 Nummer : Tao In object-oriented JAD workshops, analysis and design should consume 50-60% of the effort fon a standard sheet of paper. These I copy with a standard office copier before bisecting them with a paper cutter to produce pairs of new node eards, [Node cards share many ofthe advantages of CRC cards, They are cheap and easy to se. Because litle effort and time is invested in creating them, developers have no hesitation in replacing or modifying them, thus pro- ‘moting iteration. Because they ate physical, developers more easily think of them (and of the corresponding classes, objects, etc.) a things rather than functions. Unlike CRC cards, node cards are intended to be used on whiteboards to create object-oriented dia grams. They do not need to list collaborators, because relationships are drawn as ars con- necting the cards FLUIPCHARTS Flip charts should be used to initially capture analysis and desiga information that does not belong on the diagrams, prior to recording it via the project upperCASE tool. Flip charts can be used to list requirements, responsibil- ities, objects and clases, protocols of mes~ sages and exceptions, and resources such as antributes, operations, exceptions, invariants, and component objects RECOMMENDED JAD FACILITIES ‘When using object-oriented JAD workshops, analysis and design should consume 508-608 of the effore of the project, and ‘more than half ofthis effort should take place in specially designed conference rooms. Be- cause many small (eg, two to five member) analysis and design teams willbe working in parallel, many smalfeonference rooms willbe required.” As illustrated in Figure 3, each room should contain a single table that is lange enough to seat cight (i.e. the team members and any guests such a8 additional domain experts and representatives from other JAD teams). Very lage whiteboards should be mounted onthree ofthe four walls. These whiteboards ‘ill be used to develop the graphical models, using the notation of the chosen object-ori= ented development method. Two fip charts will be used to lst objects and classes, class + Many incremental tertiveobjecvorented devel lopmenccyles prodace many sal incremenrs (eg, {eee than the Miler Bit of seven ploe or mins wo) classes. Often, more than one eld increment ‘an be spared of ofa single parent increment, producing multiple tern working in parle oa Large Whiteboard A Flip chart Computer with Large Screen. —3> and CASE tool Large Table with Chairs Large W a Flip chart >, Vhiteboands Y Figures JAD Workshop Room a7PLEASE RUSH ME __ OPES OF “DESIGN MASTERS” 2 Domest 120 min VHS) $88 (chek Erle Payable to SIGS Boos) Charge my: Vise O Mastercard CAE Gud #___ 1S. do ot 5 er tipi /tntig Cae 1, ge 05 HY Sesto pe ae Ne onan ‘tds iy. ouney/Posta Code Poe ‘TO ORDER [MAIL SIGS Books, S88 Broaden, YW 1012 FAC 22/280845; PHONE 72/2 | Ss | 8 TTT Sometimes low-tech tools are the best, especially ifused by the right people, in the right way, at the right time resources, lists of things to do, and so forth A personal computer or workstation with a very lage sereen should beset on one end of the table so that its user can easly see the whiteboards and fip charts, The computer willbe loaded with the uppercase tool and sed to capture the models generated by the team on the whiteboards and fip charts A large wastebasket willbe used to hold the re= sults ofiteration (eg the cards of classes that do not survive. RECOMMENDED MODELING PROCESS Object-oriented requirements such a ei tation, analysis, and design should be per- formed incrementally and iteratively using small increments (aa. assemblies, class eat egories, clusters, kit, or subsystems). Sys- tems analysis and design should typically be peeformed before software analysis and de- Sign, at easton a subsyster-by-subsystern basis Once the context diagrams) have been developed, intial increments (eg, subsys- tems, subassemblies) should be identified. (Onan increment-by-increment basis, the JAD team members iteratively develop the associated diagrams onthe whiteboards." For ‘ficiency sake, JAD team members may well prepare intial sketches ofthe diagrams prior to the workshops, but the main modeling should take place asa group. ‘Three whiteboards are recommended be- cause it is usually useful to simultaneously hhave thee diagrams on the boards: (1) the curent diagram being worked on, (2) the pre- "These incrementsmaybe Wentifed and modeledin smany onder: top-down or outde in by mestoge pasting, bottom-up by inheritance, by horizontal ayes by vertical partitions vious diagram, which i stl subject to sg- nificant iteration due to discoveries made while working on the eurent diagram, and (3) its previous diagram, which should by now be relatively stable and should be eap- tured using the projet upperCASE tool ‘Capturing stable diagrams with the CASE tool is a good job for junior members ofthe team in that it requites les expertise, costs Jess, andi a good way for jusior members develop experience in modeling, For each diagram, the main abstractions (codes) are identified and associated node card are chosen, labeled, and taped to the whiteboard. The cards ae then connected with elationship aes My ADM method recommends placing clients above servers, with the directed rela- tionship arcs drawn from the client to the server. New nodes and ares are added as nec~ essary, and the diagram is iterated. Usually ‘oto three iterations over the course of two to three hours are required before the dia fram i reasonably stable. The next diagram recommended by the development method is started, and the JAD team members often jump from one diagram to another as in~ sights gained in one diagram result in changes to another Flip chares are use to caprute inital lists ‘of textual information that is best left off of the diagrams, Stabe information is captured using the upperCASE tool. Information that oes not survive the elicitation, analysis, and esign process is consigned to the rash can, ‘coNcLUSION ‘This article has recommended using white- boards and flip charts to capture the initial object-oriented models during JAD work- shops involving domain experts and users as ‘well as analyses and designers. This approach has proven tobe avery efficient, user-friendly ‘way of eliciting and analyzing object-oriented customer/user requirements, Sometimes, low-tech tools are the best, especially if used by the right people, in the right way, at the right time. 3 References 1, Beck, K, and W. Cusninghar. A aborstory for teaching object-orened thinking, SIGPLAN Nomees, 24(10}, 1988, 2. Firesmth, D.G, Omrer-Oniexra9 Requuasaiters Fox Axanysts xp Loctent Destons A Sorrwane Excinssnin Arraaacit, John Wily and Sons, New York, NY, May-June 1994