Ivar Jacobson博士的一篇介紹用例技術的起源、發展和演進過程的文章，并在該文中對大家在實踐中困惑較多的用例關系、用例數量、用例與UML等問題作了深刻的闡釋，同時提出了對擴展/包含用例的改進意見，最后還對用例未來的發展趨勢作出了有趣的預測。

An Introduction No other software engineering language construct with as much impact as use cases has been adopted so quickly and so widely as use cases have. I believe this is because use cases, although a simple idea, play a role in so many different aspects of software engineering. So many people have asked me how I came up with tuse case idea that I will briefly describe it here. I'll also sumwhat we have achieved so far with use cases, then suggest a fewimprovements for the future. he marize

Yesterday: In The Beginning

Use cases have now been around for more than 16 years. When I first used the term in 1986, they were the evolution of work ongoing since 1967.

Getting to Use Cases

It was 1986; I was troubled by how to model telephone calls. A modern switch at that time offered so many types of telephone calls: local calls, outgoing calls, incoming calls, and transit calls. There were many kinds of local calls; and many kinds of outgoing calls: calls to a neighbor switch, to a domestic switch, to an international switch. And, on top of this, each one of these calls could be carried out with different signaling systems.

We had discovered the problem of multiplicity and diversity many years ago. We didn't model each type of call—there were too many, and there was a lot of overlap between them—we just listed and named all of them: we called them traffic cases. Instead, we modeled the different “functions” we needed to carry out all of the calls. A function was some loosely defined piece of software. Functions had no interfaces. They had beginnings and endings, but they were not well defined. A function could interact with the outside world. The general feeling was that we didn't really know what functions were, but we could give examples of them, and some people could specify them.

However, we did know how to realize functions. I had learned a diagramming technique that described sequences of relay operations. In 1969 I translated this technique to software to describe component interactions—to what is today called sequence diagrams—the same term used when they were introduced. We described how functions were realized by using sequence diagrams (or collaboration diagrams for simpler interactions) in very much the same way that we describe use case realizations today.

Then, one day in spring of 1986, while working on traffic cases and trying to map them onto functions, I suddenly got it. A traffic case could be described in terms of functions by using an inheritance-like mechanism. I changed the terminology and made traffic cases and functions both use cases—the former became concrete or real use cases, the latter became abstract use cases.

I wrote a paper on this for OOPSLA'86; this paper is where I introduced use cases. The paper was not accepted (probably because I already had another paper for that conference, or because most people in the program committee were programming language experts). However, the paper was accepted for OOPSLA'87. This paper introduced many of the key ideas in use-case modeling.

What Was a Use Case in 1987?

According to the OOPSLA'87 paper “a use case is a special sequence of transactions, performed by a user and a system in a dialogue.” This is pretty similar to our current (informal) definition. I developed a separate model for describing an outside perspective of a system and I called it a use-case model. By outside, I meant a black-box view of the system—the internal structure of the system would be of no interest in this model. Some people have misunderstood the term “outside” and believed it to be a synonym for user interface—which it was not. Instead it represented a model of the functional requirements of the system.

At this time the use-case model also included entity (domain) objects, thus we could show how use cases could <> entities. Use cases and entities were class-like (with operations) and not data. The other relation in the use case model was <> which was described as “an extended form of inheritance relation. Multiple inheritances are common.” In fact, the built-on relation was a combination of the generalization relationship and the <> relation.

Use cases were not just specified, but also designed and tested. “You create as many processes [we would today say activities] as there are use cases. The conceptual model of the use cases is translated seamlessly into a new model showing how each use case is implemented by means of the identified blocks [a block would today be subsystem, class, or component].” This sounds pretty much like collaborations. “Each use case is tested separately to safeguard that the system meets the requirements of the user. Please, note that the use cases constitute the key aspect through the entire development activities.”

Sequence diagrams were used to show the interactions among the blocks/components. This is no surprise since sequence diagrams had shown their value in practice for almost twenty years by then.

What Was a Use Case by 1992?

In 1992 the OOSE book, Object-Oriented Software Engineering—a Use Case Driven Approach,1 was published. During 1987 and 1992 the Objectory process had been in practical use by about twenty customers for important new product development. These customers were involved in many different kinds of systems: management information systems, defense systems (pilot, counter measure, C3I), and telecom systems (POTS, mobile). What was presented at OOPSLA′87 was theory, now we had a lot of practical experience behind the idea. Over these five years use cases had matured.

Thus, use cases took much of their current shape (syntax and semantics) before 1992. At that time we had use cases, actors, use-case models, the relationships “inheritance” (now replaced by “generalization”) and <>. I didn't like what we today call the <> dependency since I thought it would damage modeling by inviting functional decomposition.

To increase clarity we made it an important issue to distinguish between a use case (as a class-like thing), an instance of a use case, and a description of a use case.

The depth of the use-case model was in its use cases. Each use-case description contained the following:

·a brief description

·a flow of control

·base flows and alternative flows

·subflows (reusable at many places within the same use-case description)

·preconditions and postconditions

However, use cases were more than a requirements technique. Use cases were like the hub of a wheel2:

Figure 1. Use Cases Were Like the Hub of a Wheel

Use cases were traceable to analysis, to design, and to implementation and test. For each use case in the use-case model we created a collaboration (a view of participating classes) in analysis and design. Each use case resulted in a set of test cases. Use cases were important to design user interfaces and to structure the user manual. Use cases also moved into the space of business modeling, since they perfectly matched the definition of business processes.

We coined the term use-case driven development for our approach of software development—first identifying all use cases and specifying each one of them in requirements, analyzing and designing each one of them in analysis and design respectively, and finally testing each and every one of them in test.

We had all this before<