Techniques - Pearson Higher Ed

Object EngineeringTechniques 8

153

Executive Summary

This chapter presents a collection of some simple, just-enough techniquesthat can be applied in any project to quickly determine scope and develop-ment priority, and to effectively determine user requirements. Object engi-neering employs the techniques of play script modeling, use case modeling,and class-responsibility-collaboration (CRC) modeling. Play script modelstreat the organization as a series of scenes in a play. Different actors play dif-ferent roles in different scenes. Some scenes occur in parallel to other scenes.Use case models are detailed models of the stimulus-response behavior ofthe actors and the organization’s information systems within a particularscene. CRC models are detailed models of the behavior of an individual classof objects within a use case.

Key Points

Object engineering employs a hierarchy of models to discover and documentthe components and behaviors of an information system.

• These techniques, such as context diagrams, use case diagrams, usecases, CRC cards, design by contract, Abbott Textual Analysis, and playscripts, can be applied within the framework of any appropriatemethodology.

Prentice Hall PTR

This is a sample chapter of Mentoring Object Technology Projects ISBN: 0-13-034790-6 For the full text, visit http://www.phptr.com ©2002 Pearson Education. All Rights Reserved.

POSTHUMUS

Our countrymenAre men more ordered than when Julius Caesar

Smiled at their lack of skill but found their courageWorthy his frowning at. Their discipline,

Now wing-led with their courage, will make knownTo their approvers they are people such

That mend upon the world.

Cymbeline, The King of BritainAct II, Scene 4

William Shakespeare

Posthumus tells Filario that having great courage in the face of adversity isnot sufficient. The brave must also be skilled. This chapter presents some ofthe proven, practical techniques needed to capture requirements, involve theusers in the development of the system, and apportion development workamong team members. Since one of the leading causes of systems develop-ment failures is incorrect or inadequate requirements definition, it is impor-tant to employ new techniques to quickly capture and verify the most sig-nificant requirements of the system.

Object Engineering Techniques

A technique is a systematic way of carrying out a complex task or proce-dure. Techniques are only useful if performed within an appropriatemethodology. These techniques, however, can be applied within almost anymethodology, including the light approaches of XP (extreme programming)and agile modeling.

I recommend the use of a hierarchy of techniques to aid in the construc-tion information systems. These techniques include the development of aproblem or opportunity statement, the specification of a context diagram, the1-hour use case diagramming session, the development of three to five criti-cal use cases, the CRC card modeling session, and the Abbott TextualAnalysis.

154 CH A P T E R 8 ◗ OB J E C T EN G I N E E R I N G TE C H N I Q U E S

Object technology and component-based systems should be concernedwith 80/20 and just-good-enough development. The 80/20 developmentmethod is an iterative approach to systems development that initiallyattempts to discover and implement the 20 percent of the systems that con-tains 80 percent of the functionality. Typically, this critical 20 percent of thesystem consists of the mainline processing requirements of the users of thesystem, independent of error or exception conditions.

The initial iteration should consist of the three or four most important usecases together with the use case that involves the most difficult technicalrequirement of the system. Ideally, this first development iteration willdemonstrate that the users’ key requirements are understood and can beimplemented by the developers. Most projects will probably involve three tonine iterations to fully develop the rest of the system. The upper limit of nineiterations would be found in life-critical systems that might have as many as800 or more use cases, such as an air traffic control system or a majortelecommunications organization.

I usually recommend that error handling and exceptional processing bedeferred until the third iteration. The initial iterations are used to demon-strate quickly to the users that the system will be able to deal with their mosturgent requirements, that we have assembled the proper team, that we haveappropriate systems development and project management methodologiesin place, that the system architecture is able to handle all of the operationalconstraints, and that the organization’s learning curve maturity is appropri-ate to the object technology approach.

Problem or Opportunity Statement

A problem statement can describe in as little as 25 words of less “Why thissystem, and why now?” In any event, the problem statement should notexceed two pages in length. It should ignore implementation considerations,except in the case of the mandated use of a certain technology, vendor, or theinclusion of legacy systems into the new system. The problem or opportuni-ty statement is used to prioritize the work that will be done on the new sys-tem in terms of how the work and work products will solve the organiza-tion’s problem or how the work and work products will enable the organi-zation to take advantage of a new opportunity.

The goal of the development team is to initially capture those 20 percentof the functional requirements that will supply 80 percent of the system. Oneeffective way of identifying the critical 20 percent of the processes is to first

OB J E C T EN G I N E E R I N G TE C H N I Q U E S 155

develop a problem or opportunity statement and then use the problem state-ment to set system development priorities. Work should begin on those threeto five use cases that go the furthest to solve the problem or meet the oppor-tunity. An example of a problem statement for a new prescription drug con-trol system would be “The health care industry is concerned that prescrip-tion drugs can be obtained with fraudulent or duplicate handwritten pre-scriptions.”

The problem statement is usually developed with the project sponsor (themost senior manager who has the most to gain from the success of the new sys-tem) and then is reviewed and confirmed by all of the actors and stakeholdersof the new system. The problem statement will be used to assign the develop-ment priorities of subsequently identified use cases. After the development ofthe problem statement, the next step is to develop a context diagram.

Context Diagram

A context diagram is a very high-level, black-box view of the new systemthat indicates all of the actors (people or systems that will actually use ortouch the new system).

Use Case Diagram 1-Hour Brainstorm

One extremely powerful technique that can be quickly applied to any proj-ect is the 1-hour use case brainstorm. After the development of the problemstatement and context diagram, all of the significant actors and stakeholdersin the new system are invited to a 1-hour time-box session where they areasked to list all of the possible use case titles they can envision. The candi-date titles are recorded as 3-word to 5-word verb phrases that describe howan actor would use the new system. At the end of the hour, the total numberof titles is multiplied by 1.25 if the users seem to be very familiar with therequirements of the new system or by 1.5 if the users seem to be unfamiliarwith the new system requirements. This new number of use cases is a veryquick approximation of the final number of use cases that will make up thescope of the new system.

If there are expected to be more than 50 use cases, this is usually an indi-cation that the project is too big for a single small team to develop within a3-month to 6-month timeframe. The alternatives are to decrease the scope ofthe project or to employ multiple teams to work on the project in parallel. Itis also possible that the use case titles were developed at too low a level ofgranularity. My rule of thumb is that the main course of events of the actual


use case should fit on one page (about 8 to 16 sentences) and should contain5 to 15 candidate classes. These candidate classes are nouns in the use casethat refer to things and concepts in the business domain.

I have found it useful to develop a short description of each use case titlein one of the following formats:

Three-sentence summary:

This use case begins when…

This use case does…

This use case ends when…

One-sentence summary:

Time sequence, actor, action, and constraint. For example, “At theend of the month, the accounts receivable clerk will prepare an agedaccounts receivable report for all receivables outstanding for morethan 30 days”.

These summaries are used to quickly describe to all actors and stakehold-ers the expected functionality of the new system. I have found these sum-maries to be a very effective way of quickly explaining the functionality ofthe system.

Ivar Jacobson provides some guidance on the number of use case titles wecan expect to encounter: “From our experience, a smaller system (2 to 5 man-years) might include something like 3 to 20 use cases. A medium sized sys-tem (10 to 100 man years) might include 10 to 60 use cases. Larger systems,such as applications for banking, insurance, defense, and telecommunica-tions, may contain hundreds of use cases.”1

Use Case Models

Ivar Jacobson describes the use case model (see Figure 8.1) as a representa-tion of actors and use cases.

The actors represent what interacts with the system. They representeverything that needs to exchange information with the system. We dif-ferentiate between actors and users. The user is the actual person whouses the system, whereas an actor represents a certain role a user can play.

When a user uses a system, she or he will perform a behaviorallyrelated sequence of transactions in a dialogue with the system. We callsuch a special sequence a use case.2


The use case model is the basis for identifying the domain object model,the analysis model, the design model, the implementation model, and thetesting model. The use case becomes the documentation for the system. Iteventually serves as the acceptance test of the system.

User-centered documentation techniques such as Ivar Jacobson’s use caseor Ian Graham’s task case describe the services, responsibilities, and behav-iors of a system from the point of view of a typical user of the system.Traditionally, system requirements have been described in terms of featuresand services from the point of view of the system. In practice, this tradition-al approach requires redundant and time-consuming activities of document-ing the requirements, writing user training manuals, developing testing sce-narios, and instituting change management and project management report-ing procedures. Traditionally, systems development personnel have spentsignificant amounts of time trying to analyze and understand the user’s cur-rent operations in the hope that this will somehow lead to the design of anew system.

Users already understand their current operations. What users need is away to describe their new information system requirements to systems per-sonnel who are experts in implementation. User-centered techniques can beused to produce in the first few hours or days of a project a single documentthat records the users’ system requirements, the users’ training manual, theusers’ test acceptance criteria, the users’ change request form, and the users’key vehicle for project management planning and progress reporting.

Proper application of user-centered techniques can speed up systemdevelopment and allow the users of the information system to be 100 percentinvolved in the specification, development, testing, and maintenance of theirown systems. Errors in specification can be caught early in the systemsdevelopment process when they are easy and relatively inexpensive to cor-rect. Implementation begins immediately, starting with the most significant


Figure 8.1Jacobson use case model.

Diagram and narrativedescription of the sequentialinteractions an actorhas with the system.

Actors Use Case Actors

and most technically challenging of the user-centered. If implementation ofthese first critical parts of the system indicates that the rest of the system can-not be developed in an economical, efficient, and effective manner, the proj-ect can be modified or abandoned before additional resources are wasted.

I have found that an important part of the user-centered approach is theuse of stimulus–response use case documentation. Each sentence of the basicand alternative courses of action in a use case should be written in “SVDPI”(subject–verb–direct object–preposition–indirect object) grammar. Thisgrammar will result in short, active-voice sentences. The actor or user of thesystem always initiates the use case. All odd-numbered sentences are exter-nal “stimuli” to the system. All even numbered sentences are “responses”from the system. The use of stimulus–response sentences results in user-cen-tered requirements documentation that is also the basis of the user trainingmanual and the user test acceptance criteria, and the foundation of the workof the presentation interface team (since every stimulus–response sentencecrosses the boundary between the user and the system, everystimulus–response sentence must relate to input and output data elementsin the presentation interface). Stimulus–response sentences also form thebasis of user help screens and can be used to develop questionnaires to col-lect and verify requirements from large groups of users.

In the following example, an ATM transaction demonstratesstimulus–response use case documentation. The odd-numbered SVDPI sen-tences are user stimuli, and the even-numbered SVDPI sentences are systemresponses. All sentences are independent of presentation interface technolo-gy. Every sentence crosses the user interface; therefore, every sentence isused by the presentation interface team as a work assignment for interfacedesign. Even-numbered sentences are the features of the system.

Odd-Numbered SVDPI Sentences Even-Numbered SVDPI Sentences

1. The customer initiates the 2. The system requests the PIN from transaction with the system. the customer.

3. The customer provides the 4. The system presents a service PIN to the system. menu to the customer.

5. The customer selects a service 6. The system requests the account from the menu. type from the customer.

7. Etc. 8. Etc.


One very interesting technique I use to implement user-centered devel-opment is to videotape the JAD (Joint Analysis and Design) user presenta-tion interface design sessions. Videotapes of these development sessions canbe stored in streaming video format and embedded in the system documen-tation and code. These videos can be used by new team members and bymaintenance personnel to quickly acquaint themselves with the key person-nel in the project and the rationale for various design decisions.

Chandra Vemulapalli of the Advanced Software Technologies Group atWorldCom, Inc., developed the simple use case template detailed in Table8.1 that I have found useful for small projects.



Table 8.1Use Case Template

Field Description

Use Case Name of the use case.

Actors All the different user roles and/or other systemsthat initiate the use case.

Contact Person/Dept The name of the user who provided the informa-tion regarding this use case. This is especially use-ful for large corporations where team membersmay change during the middle of a project, or inthe event the use needs to be further explained, orsimply for accountability purposes.

Name The person who recorded the information in thisuse case.

Phone # The telephone number of the person who recordedthe information in this use case.

Summary A very brief description of what the use case isabout. Use the three-sentence or one-sentenceapproach shown previously.

Preconditions The necessary conditions that have to be met beforethe use case can be performed. The preconditionscould be other use cases as well.

Description (scenario) A detailed description of the interactions betweenthe actor and the system. This is the basic course orthe normal course that should be taken by the sys-tem if the system should perform as intended.

Post-conditions The state of the system after the use case is performed.

Exceptions All the different alternative courses that can poten-tially be taken for various reasons—for example, ifthe preconditions are not met.

Security Exceptions Any security considerations that need to be imple-mented while developing this use case.

Related Use Cases List of other use cases related to this use case.

Attachments Any attachments that need to be specified for thisuse case—for example, “IEEE std 829-1983; stan-dard for preparing a system test plan.”


Use Case Title

Version #

Use Case Sequence #

Date

Author

Contributors

Summary

Goals

AssumptionsConstraints

Actors

Related Use Cases

A three- to four-word verb phrase.

The sequence of this use case from the activity dia-gram or workflow diagram.

Date of this version.

Name and contact information of the person who wrotedown the use case.

Name, telephone, and email addresses of the peoplewho provided the information in this use case.

• This use case begins when…

• This use case does…

• This use case concludes (or ends) when…

or

Time sequence, actor, action, and constraint.

The actor wants to be able to…

These may be collected during the JAD sessions.This is just a placeholder. Assumptions and con-straints are formally collected during the design phaseof the project.

Roles of people and/or systems that will use this usecase.

This use case is preceded by the ______ use case.

This use case precedes the ______ use case. (Thisinformation may not be available during the first itera-tion of the project.)

This use case uses the ______ use cases. ("Uses"means that this use case must always be used withanother use case in order to accomplish its purpose.Usually, the use case being used is an abstract orgeneralized use case.)

This use case is used by the ______ use cases. (Thiswould indicate that this use case is an abstract or gen-eralized use case. Usually, these use cases are notidentified until the second or third iteration when thedevelopers realize that there are commonstimulus–response sentences appearing in multipleuse cases. Often, this discovery is made when theauthor finds that he or she is doing a lot of cut andpaste operations.)

Figure 8.2

In my own work, I have developed a use case template (Figure 8.2) thatcan be used on any size project.


Figure 8.2 (cont.)

Related Use Cases

Outstanding Issues

Business Owner

This use case is extended by the ______ use cases.("Extended" means that error handling and exceptionprocessing is the responsibility of each of the specialuse cases. Extended use cases often contain only fourto six stimulus–response sentences.)

This use case extends the ______ use cases. (Thiswould indicate that this use case handles errors andexception processing. Usually, these extended usecases are not identified until the third iteration of theproject.)

This is a list of questions and issues that could not beanswered by the participants of the JAD session. Theproject manager will have to assign the appropriatemember of the development team to resolve eachissue.

Name and contact information of the person responsi-ble to maintain this use case. This should be a user.

Use Case Title

Version #

Date

Precondition(s)

Business Rules

Three- to four-word verb phrase

The necessary conditions that have to be met beforethe use case can be performed.

The organization’s policies, rules, or directives thatgovern the performance of this use case. This is aplaceholder for policies, rules, and directives that wereidentified during the JAD session. The formal collectionand implementation of these policies, rules, and direc-tives will occur during the design phase of the project.


User Responsibilities(User stimulus)

1.

3.

5.

7.

9.

11.

13.

15.

System Responsibilities(System response)

2.

4.

6.

8.

10.

12.

14.

16

Figure 8.2 (cont.)Typical Course of Events

Interface

Postcondition(s) The state of the system after the use case is successfullyperformed

Use Case Title Three to four-word verb phrase.

Version #

Date

Screen and Report Mock-ups

Screen or Report Title

Interface Reference

The screens and reports used or produced bythe user and the system for each numberedsentence of the typical course of events. Use aseparate page for each different screen orreport.

Typical course-of-events line numbers that usethis screen or report.

Data Elements of Attributes Used in this Screen Report


Use Case Title

Version #

Use Case Sequence #

Date

Author

Contributors

Summary

Goals

AssumptionsConstraints

Actors

Related Use Cases

Outstanding Issues

Business Owner

Place Order

1.0


18 October 1999

Richard T. Dué

Name, telephone and e-mail addresses of the peoplewho provided the information in this use case.

• This use case begins when the customer selectsPlace Order from the Navigation menu.

• This use case does the process by which orders areentered into the order processing system by cus-tomers.

• This use case concludes (or ends) when the order isconfirmed and an order ID has been provided to thecustomer.

The customer wants to be able to enter orders into theorder processing system.

Customers.

This use case is preceded by the Logon use case.

This use case precedes the Update Account use case.

This use case uses the Give Product Information,Save Order, and Update Order use cases.

This use case is used by the Logon use case.

This use case is extended by the Incomplete ShippingAddress, Product No Longer Carried, Incorrect ProductCode, and other use cases.

Name and contact information of the person responsi-ble to maintain this use case.

Figure 8.3 Example of the template for an e-commerce application for placing an order.


User Responsibilities[User stimulus]

The customer selects PlaceOrder.

The customer enters his or hername and address.

The customer enters productcodes and quantity for eachproduct ordered.

The customer enters credit cardpayment information.

The customer selects SubmitOrder.

System Responsibilities[System response]

The systems displays the PlaceOrder screen.

The system accepts the cus-tomer information.

The system displays the priceof each item, the total price foreach product ordered, and thetotal order price.

The system confirms the order.

The system issues an order IDto the customer.

Figure 8.3 Example of the template for an e-commerce application for placing an order. (cont.)

Interface

Post-condition(s)

Use Case Title

Version #

Date

Confirmed order and order ID exist.

Place Order

1.0

The sequence of this use case from the activity diagram orworkflow diagram.

Screen and ReportMock-ups

Screen or ReportTitle

Interface Reference

The screens and reports used or produced by the userand the system for each numbered sentence of thetypical course of events. Use a separate page for eachdifferent screen or report.

Place Order screen.

Typical course-of-events line numbers that use thisscreen or report.

Lines 2 to 10 use this screen.

Use Case Title

Version #

Date

Precondition(s)Business Rules

Place Order

1.0


The customer is logged on: the Logon use case.

The customer can select Cancel at any time beforeselecting Submit. the order is not saved; the use caseends.

Typical Course of Events


Shipping Name

Shipping Address

City, Province, Postal Code

Product CodeDescriptionQuantityItem PriceTotal Price

Subtotal

Tax

Total

Credit Card Number

Expiration Date

Order ID

Figure 8.3 Example of the template for an e-commerce application for placing an order. (cont.)

Data Elements or Attributes Used in This Screen or Report

Shipping Name

Shipping Address

Use Case Migration Problems

I have worked with large groups of traditional software developers to intro-duce them to the use case technique for documenting system requirements. Ihave encountered some very strong and unexpected resistance to the use caseapproach from these developers as represented by the following comments:

1. Our users don’t know what they want, so our users cannot develop use cases.Unfortunately, many experienced developers have encounteredpotential information system users who do not seem to know whatthey want from an information system. These traditional developersstill believe that it is their job to try to understand the users’ businessand then to write the use cases for the users.

I believe what is really happening here is that the traditional devel-opers and their clients don’t really understand a user-centeredapproach to documentation. The use case is the externally visiblebehaviors (e.g., screens and reports) of the interactions the user canhave with a system. If the users truly have no concept of what theywant out of a system, it is unlikely that the successful implementa-tion of any system is possible, regardless of what techniques or tech-nology are used.I have found it effective to introduce the use case technique to theusers by showing them generic use cases for common businessprocesses, by showing them use cases from similar systems or evenfrom competitor’s systems, by starting the use case developmentprocess by mocking up screens and reports before trying to developthe use cases, and by using existing training manuals to create usecases of the users’ existing systems. If, after exhausting all of theseapproaches to introduce the users to the use case technique, theusers still say that they don’t know what they want from their newsystems, I recommend that the project be cancelled.

2. We need more details. Traditional developers become distressed whenthey read user-centered documentation. They see only externally vis-ible behavior. While they can create the “look and feel” of the reportsand screens that contain the inputs and outputs of the series of userstimuli and system responses described in a use case, they are upsetthat they do not have any information on the processes and algo-rithms necessary to code the system. This is another common misun-derstanding about the use case technique. Use cases will never be suf-ficient documentation from which to begin coding. After the use casesare written, there has to be the collection of the nonfunctional require-


ments of the system. These nonfunctional requirements include fea-tures like response time, availability, transaction volumes, integrationwith legacy systems, security, and persistence strategies. The non-functional requirements are the basis for establishing the system’sarchitecture. After the architecture has been established, the process ofidentifying and designing the components of the system begins. Thecomponents of the system will contain the processes and algorithmsnecessary to provide the functional and nonfunctional requirementsof the system. The analysis and design of these components is doneusing a systems development methodology. The use case approach isnot a complete development methodology; it is just a technique todocument the externally visible behavior of the system. The use casetells what the users want from the new system, it does not tell how todesign or construct the new system.

3. We want to be end-to-end developers, not specialists. Many traditionaldevelopers expect that they will be fully involved in all phases of anew system development. They will gather the requirements, plan thearchitecture, design the new system, do the coding, conduct the test-ing, train the users, and write the documentation. The full benefits ofthe use case technique, however, come from the specialization ofduties. One team of expert user interface designers will be workingwith the users to develop the look and feel of the system’s screens andreports. Another team of business systems analysts will be workingwith the users to develop the sequences of behavior of the new sys-tem. The third team, consisting of systems development specialists,will be involved in the design and implementation of the componentsnecessary to provide the functional and nonfunctional requirementsof the system. It is only this third team that may be involved in thewriting of any code. Hopefully, however, this third team will be usingCASE tools to generate the code, reusing existing code and design pat-terns, or even using software component factories to implement therequired system.

The expectation of end-to-end development may be leading to thedevelopers’ rush to details. The sooner they collect the algorithms,the sooner they can start to code. In the three-team approach thereis no inappropriate rush to code. The specification of algorithms isdeliberately postponed until after the user interfaces have beendesigned and approved, after the use cases have been written andaccepted, and after the system architecture has been created. Thebusiness systems analysts team is done with its part of the projectwhen it has assisted the users with the development of the use

US E CA S E MI G R AT I O N PRO B L E M S 169

cases. The user interface team is done with the project when it hasassisted the users in the development of the look and feel of thescreens and reports. The implementation team that will actuallydevelop, generate, or assemble and reuse the components of thesystem only becomes involved with the project after the architecturehas been established.

4. Iterative development will result in the project’s scope and budget going outof control. Traditional developers become upset that the interactivespecification of requirements by the users will result in the uncon-trolled increase scope of the system. The use cases are revisited at leastfour times over the course of the systems development life cycle. Forexample, the Rational Unified Process specifies that during the incep-tion phase, use cases are employed to set the scope of the project andto assist in the development of the business reasons for the develop-ment of the new system. During the elaboration phase, more detaileduse cases are created to help with the setting of the system architectureand to help develop the plans for constructing the system. During theconstruction phase, use cases become the starting point for design andfor the development of testing plans. Finally, during the transitionphase, use cases are used as the basis for the development of usermanuals and user training. One of the most difficult lessons for tradi-tional developers to learn is that the iterative process often actuallydecreases the number of components in the system. More use cases donot mean more code. Common behaviors may be abstracted frommultiple components and refactored into just a single component.Additional use cases may be just new sequences of services from theexisting components.

Major Lesson Learned

After recognizing and trying to deal with these traditional developers’ resist-ance to the use case approach, it occurred to me that what was really neces-sary was that the users of a system should begin all systems developmentand enhancement projects by creating use cases themselves. Instead of thetraditional system features wish list found in most of today’s requests forproposals, user-centered RFPs should consist of use cases. A user-centeredRFP would specify the externally visible behaviors of the required system.The job of the developers would now become proposing the design andimplementation of the system that performs according to these user-devel-oped use cases.


Task Scripts: An Alternative to the Use Case

Ian Graham describes an alternative to the use case that he calls the taskscript: “For each incoming message flow in the context model, it should beestablished what the role player or external agent would normally expect tohappen in the form of a stated goal and a script beginning with an event.”3

The task script (see Figure 8.4) is a description of the typical behavior of actorsand external entities that is necessary to meet the stated goals of a system. The

TA S K SC R I P T S: AN ALT E R N AT I V E TO T H E US E CA S E 171

Task NameTask Body

Supertasks

Component Tasks

Associated or Analogous Tasks

Task Attributes

Time Taken

Complexity

Exceptions Side-scripts

Rules

Figure 8.4Graham task card.

task script, like the use case, becomes the basis for system testing and accept-ance. Graham’s important observation is that the task script itself is an objectthat can be organized into composition, classification, and usage structures. Taskscripts can be decomposed down to the level of atomic tasks that refer directlyto system objects and their operations. The ideal task script is written in termsof SVDPI sentences. There may be subscripts. There may be side-scripts, whichdeal with exceptions. The text of the script can be analyzed (see “Abbott TextualAnalysis” in this chapter) to find objects and operations.

Benefits of the Use Case and Task Case Approaches

Chandra Vemulapalli, in an Internet posting, cited the following benefits forthe use case approach:

• Capturing requirements from user’s perspective.

• Users are involved.

• One way of estimating the percentage of requirements captured.

• Prioritizing use cases for “phased delivery” according to user’s imme-diate needs.

• A better way of estimating the percentage of requirements completedduring development.

• A good way to start identifying objects from scenarios.

• Test plan can be immediately generated based on use cases.

• Easier user validation.

• Helps technical writers in structuring the overall work on the usersmanuals at an early stage.

• Better traceability throughout the system development process.

• Quality of the software is improved by identifying the exception sce-narios earlier in the development process.

Play Script Models

The play script model (see Figure 8.5) is a very high-level picture of thedynamic processes of the organization. The play script model requires us tothink of the dynamic operation of the organization as scenes in a play. It ismeant to provide organization and coordination of the subsequently devel-


oped use cases. Initially, the play script is developed to show only the mostsignificant processes. In the case of very complex organizations, differentareas of the organization can be described in different plays.

The play script model flows in time from the top of the page to the bot-tom. Processes that occur in sequence are assigned to the acts of the play.Processes that occur in parallel to the other processes in the same act areassigned to scenes. Events and triggers signal changes in acts and scenes.

The purpose of each act and scene is described in narrative format. Thepurpose should include a statement of goals and objectives. The actors thattake part in the act and scene are described. The actors are then assigned toone or both of the context columns, depending on whether they will be mak-ing service requests or supplying services during the scene. It is possible thatduring the course of the scene, an actor might appear in both columns as hisor her role changes. The stage setting is described in narrative form. The set-ting includes a description of the geographical location of the scene, theprops (resources) required in the scene, and the setting of the stage (prelim-inary interface descriptions). Preliminary timing and volume requirementsof the scene are also recorded. Each request for a service from an actor willbe expanded into a use case.

PL AY SC R I P T MO D E L S 173

ContextActors Making ServiceRequest Acts and Scenes

Act 1, Scene 1

Purpose of this act

Actors on stage

Stage setting

Props on stage

Timing and Volume

Requirements

Event or trigger whichsignals change of act orscene

Subsequent acts andscenes

ContextActors Providing Services

Figure 8.5The play script model.

The play script model should be used to begin the business processreengineering process. After the model of the organization has been reengi-neered, work can begin on development of the use cases.

CRC Models

Ward Cunningham and Kent Beck developed the CRC technique.4 The tech-nique consists of using a small index card (see Figure 8.6) that contains thename of the class, the responsibilities of the class, and the names of otherclasses with which the class collaborates.


Class

Responsibilities Collaborators

Figure 8.6Beck-Cunningham CRC card.

A short description of the purpose of the class may be written on thereverse of the card. The technique was developed to allow the designers andusers of the system to quickly describe the classes in the system. The result-ing index cards can be placed on a table and arranged spatially to interac-tively develop a model of the system. A variation on the technique, which Ihave found to be very useful, is to assign the class cards to the people whoare involved in the design project. Each person “becomes the class” by play-ing that class’s role in a typical scenario. It is important that the designersthink in terms of the service responsibilities of the class instead of the dataresponsibilities of the class. As a rule of thumb, each class should have onlyabout two to three responsibilities. These responsibilities will be implement-ed in approximately 10 to 12 operations of each class. Each operation willeventually be programmed in approximately 4 to 30 lines of code.

The whole group can quickly verify communication paths, test the com-pleteness of the design, uncover hidden design assumptions, develop a glos-sary, and so on. I have found it useful to pass a ball or other object among theteam members that represents the system’s thread of control. The personpassing the ball attaches a message that requires a service from the recipientof the ball. The person who receives the message keeps the message and theneither sends requests for service from other objects (the object’s collabora-

tors) or returns the requested response back to the requester. At the end ofthe exercise, each person will have a collection of messages that will repre-sent the operations of the objects that they are responsible for developing.During the design phase of the project, the policies, rules, directives, andalgorithms that will be required to implement these operations will be iden-tified and eventually programmed.

The final step of the CRC role-playing exercise is for all of the players toarrange their CRC cards on a tabletop so that the name of their classes are asphysically close as possible to the where their class names appear in the col-laborator section of the other players’ CRC cards. This will produce, in 2 or3 minutes, a class diagram for the project.

David Taylor has modified the CRC approach (see Figure 8.7) by addingsuper class and component categories to the card. The super class is thename of the more general class of objects that this class is a member of. Forexample, the class Sales Order is a member of the more general class calledOrder. The components are the names of classes that are combined to form

CRC MO D E L S 175

Class

Responsibilities

Components

Super Class

Collaborators

Figure 8.7Taylor CRC card.

the class. For example, the class Sales Order is made up of the combinationof Products, Pricing, and Customer classes.

Ian Graham has modified the CRC card (see Figure 8.8) to include superclasses, parts, attributes and associations, operations, servers-messages, andrule sets. His super class and parts are similar to Taylor’s super class andcomponents. Attributes indicate if the class is a primitive data item or a user-defined class. They also indicate initial and default values, whether valuescan change over the class’s lifetime, security levels, ownership, the possibil-ity of null values, and valid range constraints. Associations show the cardi-nality of the relationships the class has with other classes. Operations are theprocedures that the class can perform. Servers-messages indicate the mes-sages that the class can receive. Rule sets show the constraints and business

rules that apply to this class. Changes in state of the class may be recordedon the backs of the cards during role-playing or walk-through exercises.

Ian Graham’s extensions to the use case and the CRC card techniques aredesigned to provide additional details to the people who will actually haveto implement the model. I agree with his additions, but I am very much infavor of including formal design contracts into the use case and the CRCcards. Graham’s extensions are intended to assist people who will still becreating code. My extensions are intended to assist people who will beassembling existing classes.

Design by Contract

Originally introduced by Bertrand Meyer in the Eiffel language, the designby contract technique is the specification of formal, written contracts forevery deliverable (use case, CRC card, code, interface, etc.) and process.These contracts can have five clauses:

1. Preconditions: The conditions that have to be true before this deliver-able can be used or before this step in the process can be performed.

2. Postconditions: The conditions that will be true after this deliverableis used or after this step in the process is performed.


Class Name

Super Classes

Parts

Attributes andAssociations

Operations

Rule Sets

Abstract/Concrete Domain/Application/Interface

Servers-Messages

Figure 8.8Graham class card.

3. Invariants: The rules and policies that govern the performance of thisdeliverable or step in the process.

4. Error: The behaviors of this hardware or software deliverable undervarious error conditions.

5. Exception: The exceptions to the rules and policies that govern theperformance of this deliverable or step in the process.

The design by contract technique is an invaluable aid to communicatingthe responsibilities of each deliverable and step in the systems developmentprocess; it is also useful as a formal test acceptance criteria and as a guide tothe reuse of deliverables and steps in the development process. Natural lan-guage is usually sufficient to specify the contract, although formal specifica-tion languages should be used in life-critical systems.

Abbott Textual Analysis

I have found that the Abbott5 Textual Analysis technique is a very good wayto show developers how to identify candidate classes from use cases,domain and problem descriptions, glossaries, legacy models, and even lega-cy code. Textual analysis shows that the developers are not trying to code aparticular scenario or use case. This can often result in “classes” that arenamed after the use case or scenario. Instead, the developers are trying todevelop or reuse classes or modules of code that underlie individual usecases. It is important that the textual analysis is performed on text created bythe users of the system instead of relying on text created by developers.Abbott Textual Analysis can be performed using Table 8.2 to identify candi-date system components.

The techniques presented in this chapter can be easily applied in nearlyany object-oriented development methodology. In fact, the problem state-ment, context diagram, use case 1-hour brainstorm, use case template,Abbott Textual Analysis, and design by contract all can be used within non-object-oriented methodologies. The techniques in this chapter form the basisof a fast, effective, just-enough approach to object technology developmentprojects.

AB B OT T TE X T UA L AN A LY S I S 177

Review Questions

1. What are the significant differences between the play script, use case,and CRC card versus the traditional modeling tools (data flow dia-grams, entity relationship, and state transition diagrams)?

Notes

1. Ivar Jacobson, Basic Use Case Modeling, Research on Object Analysis& Design, SIGS Publications, September–October 1994, p. 7.

2. Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Över-gaard, Object-Oriented Software Engineering: A Use Case DrivenApproach, Addison-Wesley, 1992, p. 129.


Table 8.2Identifying Candidate System Components Using Abbott Textual Analysis

Part of Speech Component Example

Proper noun Object Richard Dué

Common noun Class toy

Doing Verb Method buy

Being Verb Classification is an

Having Verb Composition has an

Stative Verb Invariance are owned

Modal Verb Data Semantics must be

Precondition

PostCondition

Adjective Attribute unsuitable

Transitive Verb Method enter

Intransitive Verb Exception Event depend

3. Ian Graham, Migrating to Object Technology, Addison-Wesley, 1995, pp.287–288.

4. Kent Beck and Ward Cunningham, A Laboratory for Teaching Object-Oriented Thinking, OOPSLA’89, SIGPLAN Notices, 24(10), pp. 1–6.

5. R. J. Abbott, Program Design by Informal English Descriptions,Communications of the ACM, 26(11), 1983, pp. 882—894.

NOT E S 179

Documents

Techniques - Pearson Higher Ed