Be Careful With "Use Cases"
by Edward V. Berard
Recently, I have had conversations with a number of people who were attempting their first object-oriented project. Most of these people claimed to be using "use cases" in their object-oriented analysis and design approaches. However, listening to them describe their projects, it became quite apparent to me that there is a great deal of confusion regarding the definition, context, and use of use cases. This confusion can (and often does) lead to poorly-designed systems.
In June of 1979, the Ada programming language became a reality ([SIGPLAN, 1979a], [SIGPLAN, 1979b]). The U.S. Department of Defense set up Ada training classes at West Point, the Naval Post Graduate School, Georgia Institute of Technology, the National Physical Laboratory (U.K.), and the U.S. Air Force Academy in Colorado Springs, Colorado.
At the Air Force Academy, the task of designing a week-long Ada training course fell to Major Dick Bolz and Captain Grady Booch. It was impressed upon Booch and Bolz that any Ada training course must emphasize software engineering, not merely the syntax and semantics of the language. (This point was further reinforced at an ACM symposium on Ada in late 1980 ([ACM, 1980].) Booch realized that it would be difficult merely to teach an Ada "syntax course" in a week's time. So, he sought out some simple mechanism for incorporating software engineering into the training course.
Booch found the work of Russell J. Abbott ([Abbott, 1980]) to be particularly appealing. (Abbott's work was later revised and published as [Abbott, 1983].) Abbott's approach was first to write a paragraph describing a solution to the given problem. Once the paragraph was written, it could then be examined, and the nouns, noun phrases, and pronouns would suggest candidate Ada packages, and the verbs in the paragraph would suggest candidate functions and procedures to be contained within the Ada packages.
Booch liked Abbott's approach, and combined it, along with influences from Smalltalk (e.g., [Kay, 1993]), object-oriented computer hardware (e.g., [Intel, 1980], [Intel, 1981], and [Organick, 1983]), rigor in the software development process (e.g., [Robinson and Leavitt, 1977]), and a reverence for software engineering in general (e.g., [Ross et al., 1975]), into a process he called "object-oriented design." The first versions of Booch's object-oriented design process and notations can be found in [Bolz and Booch, 1981], [Booch, 1981], [Booch, 1982a], and [Booch, 1982b].
[The object-oriented landscape in 1980-1981 had a number of things in common with the landscape as we know it today. Graphical user interfaces, and other object-oriented concepts had been introduced by Sutherland ([Sutherland, 1963]). Simula, what many consider to be the first object-oriented programming language, had been around for years (e.g., [Dahl and Nygaard, 1966]). Alan Kay (e.g., [Kay, 1993]) had coined the terms "object-oriented" and "object-oriented programming" around 1970. Smalltalk had already gone through several revisions (e.g., [Goldberg and Kay, 1976], [Ingalls, 1978], and [Borning and Ingalls, 1982]). There were the beginnings of (mostly academic) discussions on object-oriented databases (e.g., [Baroody and DeWitt, 1981] and [Goldstein, 1980]). Still, it was very difficult to find someone who had even heard of the term "object-oriented."]
Booch's early efforts were important because of his attempt to view object-orientation not merely in terms of a relatively informal coding practice, but rather as a (at least partial) life-cycle process. Object-oriented programming, ordinarily, was viewed as similar to structured programming (e.g., [Dijkstra, 1969]), i.e., a process that focused primarily on coding discipline. To be sure, object-oriented programming required an informal, almost entirely intuitive, means of conceptualizing the problem, but there was little in the way of formal guidance provided. Booch, through his descriptions of the object-oriented design process and his diagramming techniques, was striving for something that was closer in form to structured design (e.g., [Yourdon and Constantine, 1979]) than to a largely informal coding strategy.
Booch's 1980-1981 concept of object-oriented design involved the beginnings of his now famous/infamous "Booch Diagrams," and a simply-defined process ([Booch, 1981]), i.e.:
It is the second step in Booch's process (i.e., the development of an informal strategy) that involves what some today would call a "use case." The "informal strategy," as Booch originally described it, was in the form of a paragraph describing a solution to the defined problem. Of course, compared with what Jacobson was to describe years later, there was little in the way of a well-defined process for creating a set of well-defined use cases. ([Berard, 1985]) was one attempt to define a systematic and repeatable process for the creation of (both individual and sets of) "informal strategies.")
The purpose of the "informal strategy" was twofold:
In the early 1980s, there was much resistance to Booch's object-oriented design approach. Software practitioners -- never known for their writing skills -- complained about the informality of the paragraph format. Many suggested that more rigor (and, hence, better solutions) could be accomplished through the use of graphics (e.g., data flow diagrams and state transition diagrams a la [Ward and Mellor, 1985]), or formal (mathematical) techniques (e.g., VDM, described in [Jones, 1980] and [Jones, 1986]). Booch, himself, more than once, considered ways of integrating graphical techniques into the strategy defining process, e.g., the use of data-flow diagrams in [Booch, 1986].
Today, there are increasing numbers of fairly formal techniques for expressing object-oriented designs (e.g., "object-oriented Z" ([Stepney et al., 1992])). However, there is also a decided shift towards relatively simple ways of expressing object-oriented analysis and design. It is the very (seeming) informality of use cases that makes them attractive to many object-oriented technology users. We see use cases being incorporated several object-oriented methodologies, e.g., Fusion ([Coleman et al., 1994]). If use cases become part of the so-called Unified Method ([Booch and Rumbaugh, 1995]), in a very real sense, Booch will have come full circle.
By 1986, there were already quite a few object-oriented design approaches from which to choose. At the 1986 Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) conference ([ACM, 1986]), Ivar Jacobson presented his ideas on the design of large, real-time systems ([Jacobson, 1986]). In this presentation, Jacobson discussed such things as "blocks," "services," "objects," "signals," and "messages," along with references to a formal specification language, i.e., FDL.
It was not until the 1987 OOPSLA conference ([ACM, 1987]), however, that many in the object-oriented community were introduced to both "ObjectOry" and "use cases." In his 1987 presentation ([Jacobson, 1987]), Jacobson described ObjectOry as a technique, and use cases as a tool used within that technique. The "use" in use cases was clearly intended to be from the view of a "user of the system," e.g.:
"The basis of ObjectOry is that it shall be designed for its users. We want to build the system for them. In order to safeguard that the users really get the system they want and need, we want to structure the system's total behaviour in aspects, where each aspect corresponds to what we can call a use case."
Usually, those methodologists who advocate the creation of use cases, or similar items, suggest three primary motivations for use case creation:
Jacobson goes further than this. He points to the use of use cases in the testing process, e.g., from [Jacobson et al., 1992]:
I would like you to take note of two interesting points:
In 1990, Elizabeth Gibson (then working for ParcPlace) first publicly described an object-oriented design process called "object behavior analysis" or OBA (e.g., [Gibson, 1990] and [Gibson, 1991]). In OBA, a developer would write a number of "scripts" describing how a user would interact with (use) the planned system. The scripts could then be used to gain a better understanding of the intended system, and to identify candidate objects. I also note that the scripts generated in OBA are strikingly similar to Jacobson's use cases.
I should also add that approaches such as Rebecca Wirfs-Brock's Responsibility-Driven Design (e.g., [Wirfs-Brock et al., 1990]) advocate the examination of "system requirements" with the intention of both identifying candidate objects, and establishing interactions and interrelationships among the objects. In the context of such approaches, we could use use cases as a means of describing (creating) the requirements.
In [Jacobson et al., 1995], use cases are defined as follows:
To better understand this definition, we note that:
[Jacobson et al., 1992] notes that: "the set of all use case descriptions specifies the complete functionality of the system."
[Jacobson et al., 1995] provides the following advice for use case creation, and an accompanying use case example:
"Basic flow of events:
"A. The user case begins when the actor Guest enters the restaurant.
"B. The actor Guest has the possibility of leaving his/her coat in the cloakroom, after which he/she is shown to a table and given a menu.
"C. When the actor Guest has had sufficient time to make up his/her mind, he/she is asked to state his/her order. Alternatively, Guest can attract the waiter's attention so that the order can be placed.
"D. When the Guest has ordered, the kitchen is informed what food and beverages the order contains.
"E. In the kitchen, certain basic ingredients, such as sauces, rice, and potatoes, have already been prepared. Cooking therefore involves collecting together these basic ingredients, adding spices and so on and sorting out what needs to be done just before the dish is served. Also, the required beverages are fetched from the refrigerator.
"F. When the dish is ready, it is served to the actor Guest. When it has been eaten, the actor is expected to attract the waiter's attention in order to pay.
"G. Once payment has been made, Guest can fetch his/her coat from the cloakroom and leave the restaurant. The use case is then complete."
[Jacobson et al., 1995] goes on to say that, as with any use case, the above use case may be augmented with (stated) alternative courses of events. (The "structured writing approach" should not be overly complex, e.g., it should have much of the flavor of "structured English" (e.g., [DeMarco, 1979]).)
Most, if not all, references to Objectory stress that use cases should be used throughout the development part of the software life-cycle, e.g., during analysis, design, and testing. [Jacobson et al., 1995] and [Christerson and Jonsson, 1995], among others, even point out that use cases can be an important tool in business process modelling and business process reengineering as well.
Given a particular abstraction scheme, we can gauge the quality of the localization within a design:
Problems often arise in software development efforts when differing localization strategies are used during the same development effort. For example, suppose we are presented with a set of functional requirements, and we are told to product an object-oriented solution. This means that there will be a fundamental shift in localization strategies somewhere between the requirements and the creation of the final product. This shift often results in the introduction of significant errors.
Use cases, as they are most commonly described and used, are almost, if not entirely, functional in nature. This, by itself, is not a problem. However, we must be careful when using use cases within the context of object-oriented development.
Many software practitioners have a good deal of experience in functional decomposition approaches to system development. Use cases present them with an opportunity to continue their functional view of software development. I recently talked with one organization that described their "object-oriented" approach to software development as follows:
This (almost logical sounding) approach is a recipe for disaster. The key point is to remember that objects are not functions, and functions are not objects. In the mid-1980s, I worked with more than one organization that suffered the consequences of a functional decomposition "front end," and an object-oriented "back end." Here is what happened:
My advice is simple. It is perfectly proper and appropriate to use use cases to describe an external (user-oriented) view of the system. However, avoid the temptation to use this functional view of the system as a basis for the creation of an object-oriented architecture for that same system. As many of my clients will tell you, objects and functions do not map to each other on a one-to-one basis, and the architecture of an object-oriented system is significantly different from the architecture of a functionally decomposed system.
(Yes, I know that pathological combinations of functional architectures and object-oriented architectures are often encouraged by some of today's most popular methodologies, e.g., Objectory's so-called "control objects," Booch's so-called "manager objects" (e.g., see chapter 8 of [Booch, 1994]), Bertrand Meyer's so-called "command objects" ([Meyer, 1988]), and the countless examples of "classes" that encapsulate functions only, i.e., so-called "stateless classes." It seems that functional decomposition is still deeply entrenched in the software psyche.)
Another potential problem with use cases is the temptation to violate information hiding. Information hiding is the process of making certain pieces of information inaccessible. We often speak of the information as being hidden within a "black box." D.L. Parnas (e.g., [Parnas, 1972]), the man who coined the term "information hiding," advocated that the details of difficult and likely-to-change design decisions be hidden from the rest of the system. Further, the rest of the system will have access to these design decisions only through well-defined, and (to a large degree) unchanging interfaces.
Information hiding is one of the most important aspects of object-orientation. For example, "looking inside" (viewing the underlying implementation of) an object is an activity that is reserved strictly for the creator or owner of that object. Users of an object interact with that object only through the interfaces provided by the creator or owner of the object. If a user of an object insists that he or she must have access to, or knowledge of, the underlying implementation of an object, then one of two situations is true, i.e., either:
When developing use cases, we must know not only the item for which we developing the use case, but also the defined/intended public interface for that item. (By "item," we mean a cohesive, well-defined system, or system component.) Developers of use cases should avoid the temptation to go beyond the public interface of an item, and attempt to describe the internal structure (design, architecture) of the item.
When we violate information hiding, we pay the consequences. For example:
Again, the advice is simple. When constructing a use case for an item, do not describe any details of the underlying implementation of that item. For example, when describing an Automated Teller Machine, it is perfectly proper to construct a use case that describes the sequences of activities, and the necessary input and output information, associated with, say making a deposit. It would not be proper within the same use case, for example, to provide any information on the details of the algorithm used to credit the deposit to the user's account.
As was mentioned earlier, [Jacobson et al., 1992] notes that: "the set of all use case descriptions specifies the complete functionality of the system." This means that software developers who make use of use cases, will often find themselves dealing with sets of use cases. Further, since many approaches recommend the use of use cases throughout the development and testing processes, each level of abstraction (detail) will have its own (hopefully complete and accurate) set of use cases.
Creating, partitioning, maintaining, and otherwise using many different use cases, must be done with care:
In dealing with individual use cases, software engineers should keep the following in mind:
It is the very simplicity of use cases that makes them so powerful. Yet, this simplicity can lead to problems if the creation, integration, and maintenance of use cases is not carefully controlled. The larger and/or more critical the end product, the greater will be the need for rigor in the creation and handling of use cases.
Lastly, in using use cases, object-oriented software engineers should be on guard for problems of conflicts in localization strategies, violations of information hiding, and sloppiness in the creation and configuration management of use cases.
[Abbott, 1983]. R. J. Abbott, "Program Design by Informal English Descriptions," Communications of the ACM, Vol. 26, No. 11, November 1983, pp. 882 - 894.
[ACM, 1980]. Association for Computing Machinery, Proceedings of the ACM SIGPLAN Symposium on the Ada Programming Language, Boston, Massachusetts, December 9-11, 1980, Association for Computing Machinery, New York, New York, ISBN 0-89791-030-3, 242 pages, 1980.
[ACM, 1986]. Association for Computing Machinery, OOPSLA '86 Conference Proceedings, special issue of SIGPLAN Notices, Vol. 21, No. 11, November 1986.
[ACM, 1987]. Association for Computing Machinery, OOPSLA '87 Conference Proceedings, special issue of SIGPLAN Notices, Vol. 22, No. 12, December 1987.
[Ambriola and Bendix, 1989]. V. Ambriola and L. Bendix, "Object-Oriented Configuration Control," Proceedings of the 2nd International Workshop on Software Configuration Management, special issue of Software Engineering Notes, Vol. 17, No. 7, November 1989, pp. 133 - 136.
[Baroody and DeWitt, 1981]. A.J. Baroody and D.J. DeWit, "An Object-Oriented Approach to Database System Implementation," ACM Transactions on Database Systems, Vol. 6, No. 4, December 1981, pp. 576 - 601.
[Berard, 1985]. E.V. Berard, An Object-Oriented Design Handbook for Ada Software, EVB Software Engineering, Inc., Frederick, Maryland, 1985.
[Berard, 1993]. E.V. Berard, Essays on Object-Oriented Software Engineering, Volume 1, Prentice Hall, Englewood Cliffs, New Jersey, 1993.
[Bolz and Booch, 1981]. D. Bolz and G. Booch, Software Engineering With Ada, Department of Astronautics and Computer Science, United States Air Force Academy, Colorado Springs, Colorado, 1981.
[Borning and Ingalls, 1982]. A.H. Borning and D.H.H. Ingalls, "Multiple Inheritance in Smalltalk-80," Proceedings of the National Conference on Artificial Intelligence, August 1982, pp. 234 - 237.
[Booch, 1981]. G. Booch, "Describing Software Design in Ada," SIGPLAN Notices, Vol. 16, No. 9, September 1981, pp. 42 - 47.
[Booch, 1982a]. G. Booch, "Object Oriented Design," Ada Letters, Vol. I, No. 3, March- April 1982, pp. 64 - 76.
[Booch, 1982b]. G. Booch, "Solve Process-Control Problems With Ada's Special Capabilities," EDN, June 23, 1982, pp. 143 - 152.
[Booch, 1983a]. G. Booch, Software Engineering with Ada, Benjamin/Cummings, Menlo Park, California, 1983.
[Booch, 1983b]. G. Booch, "Object Oriented Design," IEEE Tutorial on Software Design Techniques, Fourth Edition, P. Freeman and A.I. Wasserman, Editors, IEEE Computer Society Press, IEEE Catalog No. EHO205-5, IEEE-CS Order No. 514, pp. 420 - 436.
[Booch, 1986]. G. Booch, "Object Oriented Development," IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 211 - 221.
[Booch, 1994]. G. Booch, Object-Oriented Analysis and Design With Applications, Second Edition, Benjamin/Cummings, Menlo Park, California, 1991.
[Booch and Rumbaugh, 1995]. G. Booch and J. Rumbaugh, Unified Method: User Guide, Version 0.8, Rational Software Corporation, Santa Clara, California, 1995.
[Christerson and Jonsson, 1995]. M. Christerson and P. Jonsson, Tutorial 1: Object-Oriented Software Engineering, Tutorial Notes, Presented at OOPSLA '95, October 15-19, 1995, Austin, Texas, Association for Computing Machinery, New York, New York, 1995.
[Coleman et al., 1994]. D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes, Object-Oriented Development: The Fusion Method, Prentice Hall, Englewood Cliffs, New Jersey, 1994.
[Dahl and Nygaard, 1966]. O.J. Dahl and K. Nygaard, "SIMULA -- an ALGOL-Based Simulation Language," Communications of the ACM, Vol. 9, No. 9, September 1966, pp. 671 - 678.
[DeMarco, 1979]. T. DeMarco, Structured Analysis and System Specification, Yourdon Press, New York, New York, 1979.
[Dijkstra, 1965]. E. Dijkstra, "Programming Considered as a Human Activity," Proceedings of the 1965 IFIP Congress, Amsterdam, The Netherlands, North Holland Publishing Company, 1965, pp. 213 - 217, Reprinted in Classics in Software Engineering, E.N. Yourdon, Editor, Yourdon Press, New York, New York, 1979, pp. 3 - 9.
[Dijkstra, 1969]. E.W. Dijkstra, "Structured Programming," originally appeared in a report on a conference sponsored by the NATO Science Committee, Rome, Italy, October 1969, reprinted in Classics in Software Engineering, Edited by Edward N. Yourdon, Yourdon Press, New York, New York, 1979, pp. 43 - 48.
[Gibson, 1990]. E. Gibson, "Objects -- Born and Bred," Byte, Vol. 15, No. 10, October 1990, pp. 245 - 246, 248, 250, 252, 254.
[Gibson, 1991]. E. Gibson, "Flattening the Learning Curve: Educating Object-Oriented Developers," Journal of Object-Oriented Programming, Vol. 3, No. 6, February 1991, pp. 24 - 29.
[Goldberg and Kay, 1976]. A. Goldberg and A. Kay, Editors, Smalltalk-72 Instructional Manual, Technical Report SSL-76-6, Xerox PARC, Palo Alto, California, March 1976.
[Goldstein, 1980]. I. Goldstein, "Integrating a Network-Structured Database Into an Object-Oriented Programming Language," Proceedings of the Workshop on Data Abstraction Database and Conceptual Modelling, M.L. Brodie and S.N. Zilles, Editors, Pingree Park, Colorado, June 23-26, 1980, pp. 124-125.
[IEEE, 1987]. Institute for Electrical and Electronics Engineers, An American National Standard: IEEE Guide to Software Configuration Management, ANSI/IEEE Std 1042-1987, The Institute of Electrical and Electronics Engineers, Inc., New York, New York, 1987.
[Ingalls, 1978]. D.H.H. Ingalls, "The Smalltalk-76 Programming System Design and Implementation," Fifth Annual ACM Symposium on the Principles of Programming Languages, January 1978, pp. 9 - 15.
[Intel, 1980]. Intel Corporation, iAPX 432 Object Primer, Manual 171858-001, Revision B, Intel Corporation, Aloha, Oregon, 1980.
[Intel, 1981]. Intel Corporation, Engineering Specifications of the iAPX Extensions to Ada, Manual 171871-001, Intel Corporation, Aloha, Oregon, January 1981.
[Jacobson, 1986]. I. Jacobson, "Language Support for Changeable Large Real Time Systems," OOPSLA '86 Conference Proceedings, special issue of SIGPLAN Notices, Vol. 21, No. 11, November 1986, pp. 377 - 384.
[Jacobson, 1987]. I. Jacobson, "Object-Oriented Development In an Industrial Environment," OOPSLA '87 Conference Proceedings, special issue of SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 183 - 191.
[Jacobson et al., 1992]. I. Jacobson, M. Christerson, P. Jonsson, and G. Övergaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, Reading, Massachusetts, 1992.
[Jacobson et al., 1995]. I. Jacobson, M. Ericsson, and A. Jacobson, The Object Advantage: Business Process Reengineering With Object Technologyt, Addison-Wesley, Reading, Massachusetts, 1995.
[Jones, 1980]. C.B. Jones, Software Development: A Rigorous Approach, Prentice Hall, Englewood Cliffs, New Jersey, 1980.
[Jones, 1986]. C.B. Jones, Systematic Software Development Using VDM, Prentice Hall, Englewood Cliffs, New Jersey, 1986.
[Kay, 1993]. A.C. Kay, "The Early History of Smalltalk," SIGPLAN Notices, Vol. 28, No. 3, March 1993, pp. 69 - 95.
[Meyer, 1988]. B. Meyer, Object-Oriented Software Construction, Prentice Hall, Englewood Cliffs, New Jersey, 1988.
[Organick, 1983]. E. Organick, A Programmer's View of the Intel 432 System, McGraw-Hill, New York, New York,1983.
[Parnas, 1972]. D.L. Parnas, "On the Criteria To Be Used in Decomposing Systems Into Modules," Communications of the ACM, Vol. 5, No. 12, December 1972, pp. 1053-1058.
[Robinson and Leavitt, 1977]. L. Robinson and K. Leavitt, "Proof Techniques for Hierarchically Structured Programs," in Current Trends in Programming Methodologies, Volume 2, Raymond T. Yeh, Editor, Prentice Hall, Englewood Cliffs, New Jersey, 1977.
[Ross et al., 1975]. D.T. Ross, J.B. Goodenough, C.A. Irvine, "Software Engineering: Process, Principles, and Goals," IEEE Computer, Vol. 8, No. 5, May 1975, pp. 17 - 27.
[Rumbaugh et al., 1991]. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs, New Jersey, 1991.
[SIGPLAN, 1979a]. Anonymous, "Preliminary Ada Reference Manual," SIGPLAN Notices, Vol. 14, No. 6A, June 1979.
[SIGPLAN, 1979b]. Anonymous, "Rational for the Design of the Ada Programming Language," SIGPLAN Notices, Vol. 14, No. 6B, June 1979.
[Stepney et al., 1992]. S. Stepney, R. Barden, and D. Cooper, Editors, Object-Orientation in Z, Springer-Verlag, London, United Kingdom, 1992.
[STSC, 1994]. Software Technology Support Center, Software Configuration Management Technology Report, September 1994, Software Technology Support Center, Hill Air Force Base, Utah, 1994.
[Sutherland, 1963]. I. Sutherland, Sketchpad, A Man-Machine Graphical Communication System, Ph. D. Thesis, Massachusetts Institute of Technology, January 1963.
[Ward and Mellor, 1985]. P.T. Ward and S.J. Mellor, Structured Development for Real-Time Systems, Volumes 1-3, Yourdon Press, New York, New York, 1985.
[Wirfs-Brock et al., 1990]. R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs, New Jersey, 1990.
[Yourdon and Constantine, 1979]. E. Yourdon and L.L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Prentice Hall, Englewood Cliffs, New Jersey, 1979.