Part III Application- Domain Analysis / | Purpose + To determine a system’s usage requirements. Concepts * Application domain: An organization that adminis- trates, monitors, or controls a problem domain. * Requirements: A system's externally observable behav- ior. Principles * Determine the application domain with use cases. * Collaborate with users. Result + A complete list of the system's overall usage require- ments. Application-domain analysis focuses on a question: How will the target sys- tem be used? The purpose in asking it is to define requirements for the sys- “tem’s fanctions and interfaces. Application-domain analysis interacts with problem-domain analysis, which we discussed in Part II. There, the ques- tion was: What is the target system about? The purpose of problem-domain analysis was to define requirements for the system’s model, which provides our vocabulary for defining the function and interface requirements. In most projects, deciding the order of these two main activities is a strategic question. If you begin by analyzing the application domain, your focus is on the users’ work, and you might specify many detailed require- ments. From this, you can abstract the underlying concepts, which you can’ then model as classes, events, and structures in the problem-domain model. If you begin by analyzing the problem domain, your focus will be on what the business is really about, rather than on interfaces and functions. 117118 Stable properties Transient properties —_—_—_—_ Model Functions Interfaces Figure IIL1: The relative stability of different system properties Later, you can dig into system usage and define user requirements based on a fundamental understanding of the business concepts. Although starting with application-domain analysis is easier, starting with problem-domain analysis can yield a better object-oriented descrip- tion. Many traditional methods and use-case-driven object-oriented meth- ods recommend the first approach; we recommend that you let your situa- tion determine whether to start your analysis with the application or prob- lem domain. On some projects, you can even combine them, pursuing both activities in parallel. An even more fundamental question is why we distinguish between ap- plication and problem domains at all. Why not just model the target system straight away? The answer lies in the difference in stability of the target system’s properties. As Figure III.1 illustrates, a system’s model is more stable; its functions and interfaces, more transient. When you change the model, you must change the functions and interfaces. However, you can change functions without changing the model (though you must change the interfaces) and you can change the interface, such as switching from text to graphics, without changing the functions or the model. In short, function and interface requirements change more often, while the system model rarely changes. Focusing on the different domains lets you design a more robust and flexible architecture. Requirements determination is based on two fundamental principles. The first principle is: Principle: Determine the application domain with use cases. Use cases offer an elegant solution to the classic problem in application-do- main analysis: focusing on users’ work yields too much information in too much detail. Use cases help concentrate the analysis on the interaction be- tween users and the target system. Sane The second principle is: Principle: Collaborate with users. Specifying requirements is not a one-way street. Users may not understand the technical options well enough to simply write down the optimal require-119 \ a Nic Intectacsie a ee \ Functions ~~ = Figure III.2: Application-domain analysis ments. Cooperation between developers and users is needed. The require- ments for usage, functions, and interfaces must be evaluated. You also need to reduce the uncertainty inherent in requirements definition. Because re- quirement formulations are abstract, it is difficult to know whether every- thing has been considered. To validate requirements, you should conduct experiments in cooperation with users. — Activity Content Concepts Usage How does the system in- _ Use case and actor teract with people and systems in the context? Functions What are the system's Function information processing capabilities? Interfaces What are the target sys- Interface, user inter- tem’s interface require- face, and system inter- ments? face Figure IIL3: Activities in application-domain analysis —_ Defining requirements is an iterative activity alternating between usage, functions, and interfaces. However, for pedagogical reasons, in require- ments analysis we focus on each activity in turn, as Figure III.2 shows. Our120 goal is to create a coherent and consistent result. Figure ITI.3 gives an over- view of the activities in application-domain analysis. In Chapter 6 (Usage), we discuss how you can determine target-system use in the application domain by identifying and structuring actors and use cases. In Chapter 7 (Functions), we discuss how to formulate system func- tionality requirements. We use a complete list of functions to offer a func- tionality overview, and specify complex functions in more detail. In Chapter 8 (Interfaces), we discuss how to sketch system interface requirements. The user interface is defined by choosing dialogue styles, presentation forms, and interface elements. We also discuss how to define interface require- ments in more detail.Chapter 6 Usage Purpose * To determine how actors interact with a system. Concepts * Actor: An abstraction of users or other systems that in- teract with the target system. Use case: A pattern for interaction between the system and actors in the application domain. Principles * Determine the application domain with use cases. * Evaluate use cases in collaboration with users. * Assess social changes in the application domain. Result © Descriptions of all use cases and actors. To be usable, a system must fit the application domain. In this chapter we look at how we can determine this fit. We do this by describing actors and use cases based on an understanding of application-domain activities. The use cases provide an overview of the system requirements from the users’ perspective and provide a foundation for defining and evaluating the more basic function and interface requirements. 6.1 Use Cases Analyzing an existing application domain can create a huge amount of de- tailed information that has little value to the development process. For effi- ciency, you must maintain a relevant level of abstraction and focus on the interaction between users and the system. Use cases can help you achieve a relevant focus and abstraction level. In this activity the key concepts are: Actor: An abstraction of users or other systems that interact with the target system. i” 121122 Usage Use case: A pattern for interaction between the system and actors in the application domain. 7 al Actors are an abstraction of people and other systems that activate a target system’s functions. Of course, in a use-case description, we should indicate whether the actor is mechanical or human. A specific person or system can appear in different roles. A use case is an abstraction of an interaction with the target system. It determines a delimited use of a part of the system. A use case can be initiat- ed by an actor or by the target system. The complete set of use cases deter- mines all uses of the target system within the application domain. The main principle in determining system usage is: Principle: Determine the application domain with use cases. Determining use cases is a multi-faceted activity. First, it demands cooper- ation between users and developers: users formulate needs and contribute application-domain insights, and developers formulate use cases and con- tribute technical knowledge. ‘System definition [—) Use cases — — and actors Evaluate systematically Figure 6.1: Subactivities of usage Second, determining use cases is an analytical as well as a creative ac- tivity. Use cases originate from needs and conditions in the application do- main, but a use case is itself an expression of a solution. Third, determining use cases is both a descriptive and experimental ac- tivity. You cannot fully evaluate the target system’s use by sitting at a desk studying use cases. A truly critical evaluation must include the user. Some users can be both critical and constructive with a description of the use cas- es. However, in order to really involve the user, you must present use cases through prototypes. This is a central principle: Principle: Evaluate use cases in collaboration with users.Example: An Automated Payment System 123 Fourth, use cases define both the target system and its application domain. Changes to a company’s computerized systems affect the company’s organi- zation and way of working. It is important to evaluate these changes in or- der to avoid negative side effects. OOA&D does not include guidelines for organizational change; you should supplement it with such organization-fo- cused methods as needed. At a minimum, you should evaluate the target system’s effect on the organizational context, as expressed in the following principle: Principle: Assess social changes in the application domain. Figure 6.1 offers a summary of usage analysis activities: Actors and use cases are defined, often using patterns as inspiration. The activity results in a description of all use cases and actors. These descriptions should be systematically evaluated. Actors Account owner Creditor Administrator Liquidity Use cases . monitor Payment v Cash withdrawal Money transfer R446 4 % Account information Credit information v Registration & 4 4 4 4 Monitoring Error correction v Figure 6.2: Actor table for the automatic payment system 6.2 Example: An Automated Payment System A basic automated payment system has four actors: account owners, who use the sys- tem for payment and cash withdrawals; creditors, who have customers that pay via the system; administrators, who work with the system; and liquidity monitors, who use the system to monitor the bank’s liquidity. An actor table, as shown in Figure 6.2, provides an overview of the in- teraction. Figure 6.3 shows the same information graphically in a use-case diagram. You can illustrate the relation between actors and use cases using124 Usage «actor> «actor» Account Laity owner mentor wactor» Creditor «actor» Administrator Figure 6.3: Use-case diagram for the automatic payment system either an actor table or a use-case diagram. We prefer the actor table, as it consumes less space; UML recommends the use-case diagram. The account owner is involved in four use cases: payment, cash with- drawal, money transfer, and account information. Credit card payments al- ways occur through the creditor—an interactive process involving both ac- tors. Cash withdrawals occur at publicly accessible ATM machines, which are robust and easy to use. Transfers of money to the account can occur ei- ther electronically or by check. Although account information is sent by mail to the account owner on a monthly basis, the owner can also call the administrator to receive special account information. The creditor participates in three use cases: payment, money transfer, and credit information. The payments should occur without trouble so that it does not distract the customer and delay the service. The system there- fore offers different technical possibilities. The credit card can be read di- rectly by a cash register. Alternatively, the cash register can be fitted with a removable, portable card reader with a keyboard. This card reader is es-Example: An Automated Payment System Actors and Classes, Use Cases, and Events An actor table looks similar to the event table discussed in Chapter 3. This raises the question: Is there any difference between actors with use cases and classes with events? The answer is yes. The main differ- ence is that the phenomena occur in different domains. A class describes something that the target system should man- age, such as a customer. An actor describes someone or something that interacts physically with the system, such as a clerk. An event describes an incident the system must be aware of, such as when a customer orders certain goods. A use case describes the interaction between an actor and the system, such as a clerk entering an order. An event is something we want the system to remember. A use case is a way of using the system, such as to enter information. The event can occur at a different time and place than the related use case. For example, the ordering 125 could happen in a stare and the re- lated use case could be performed later on in a back office. Of course, there are similarities between actor tables and event ta- bles. They both view their do- mains—the application domain and problem domain, respective- ly—in static and dynamic aspects. Actors and classes describe static aspects, while use cases and events describe dynamic aspects. Events are structured into behavioral pat- terns. Similarly, use cases can be viewed as another type of behav- ioral pattern, albeit in another do- main. We can imagine cases in which the application domain and the problem domain overlap. If a cus- tomer enters an order over the Web, then “Customer” is both a class and an actor, and “ordering” is both a use_case and the event that occurs when the order is ac- cepted. Thus, the denotation of the concepts can overlap, but the de- scriptions of actors and classes, and use cases and events, will dif- fer. pecially used by creditors in places such as restaurants, where the payment does not necessarily occur at a cash register. Transferring money from the system to the creditor occurs electronically or by check. Credit information is given with variable speed and frequency. The creditor can therefore choose between an advanced cash register, which is directly linked to the system; indirect transfer of credit information in electronic form; or sending account balances through conventional mail. Administrators participate in six use cases: registration, monitoring, error correction, money transfer, account information, and credit informa- tion. The account owner and the creditor should be able to contact an ad- ministrator with all types of needs, and in principle, the individual admin-126 Usage istrator should perform all tasks related to the payment system. It is im- portant that an administrator has a system overview and is able to switch quickly and efficiently between the system’s different functions. Liquidity monitors participate in only one use case: account informa- tion. A liquidity monitor compares information about all the accounts to see if the liquidity rules are being followed. A liquidity monitor activates the system to obtain information about the accounts in the payment system; in our example, the monitor is another computerized system with access to ac- counts. The payment system illustrates the important differences and varia- tions in actors and use cases. Account owners, creditors, administrators, and liquidity monitors all use the system in different ways and situations. The requirements as to what should be accessible and in what form this ac- cess should take place vary widely and must be thoroughly analyzed and defined. You may not notice great differences or variations in some sys- tems, but they are there nonetheless. You must understand these differenc- es to design a system that is well adapted to the technical and organization- al context. 6.3 Find Actors and Use Cases The central questions about the target system’s usage are: Who will use the system? How will it be used? You can answer these questions in terms of ac- tors and uses cases. a i Identify Actors To identify actors, you must determine the division of labor and the task-re- lated roles in the target system's context. In the payment system, the four actors are easy to identify because their reasons for using the system are very different. The account owner, the creditor, and the administrator reflect three different organizational roles. It might be possible to further specialize these roles. For example, can the account owners be divided into different types? The answer depends on the business policy. In this case, a simple system is preferred. We separate the liquidity monitor from the administrator, because the liquidity monitor can be another system, whereas the administrator is always a person. The criterion for determining different actors is the dissimilarity of roles, as expressed by the use cases in which actors are involved. This corre- sponds to the criterion for having two different classes in the problem do- main: their objects’ behavioral patterns differ. If several roles appear the same to the system, you should consider con- solidating them into one actor. The Hair Salon System (Chapter 20) in-Find Actors and Use Cases Analyze Work Tasks Traditional system development methods, such as structured analy- sis, focused on analyzing the appli- cation domain. In such methods, the first activity was to analyze the current physical system. In this ac- tivity, the existing, often manual, routines were described in detail. In the ensuing activities, function- al requirements for the new system were derived by abstracting and transforming the model of the ex- isting system. In some projects, too much effort. was spent describing the existing system, and progress was slow. Such a situation was called the “Current Physical Tarpit.” Newer versions of structured analysis fol- lowed a “blitzing” strategy in which developers made a brief sur- vey of the current situation and then jumped directly into specify- ing functional requirements. Gen- erally, this proved to be a more effi- cient approach. Focusing on use-case modeling is the object-oriented version of blitzing. We advise against making other, more extensive application- domain models, as it’s generally not worth the effort. 127 However, if use cases are hard to identify or survey, you might re- sort to modeling the work tasks in the application domain. To this end, there are many techniques, including observation, self regis- tering, participation in the actors’ work, video recording, thinking- out-loud experiments, cultural analysis, role games, rich picture drawings, and mapping. You can describe the work tasks using wall charts, or use context diagrams and data-flow diagrams borrowed from structured analysis methods. You can also study application-do- main descriptions in existing docu- mentation of rules and procedures. A primary result of task-analy- sis work is a complete list of appli- cation-domain tasks. This should provide the necessary overview. You can also describe individual tasks, emphasizing the work proce- dures. From this, you should be able to identify the use cases. Finally, it is important that you keep the purpose of the task analy- sis in mind. The purpose is not to perform a work analysis, but rath- er to create a basis for identifying actors and use cases. Given this, you would not typically include task descriptions in your final doc- umentation. cludes a task that involves taking calls from people wishing to make ap- pointments for a hair cut. This task is typically performed by the reception- ist, but when the receptionist is busy, one of the hair stylists must answer the phone. In this case, the receptionist and the hair stylists use the system with the same goal, and it is therefore obvious that they can be considered128 Usage as having the same role in this use of the system. That is, there is only one actor: the “Receptionist.” When the hair stylists answer the phone, they step into the receptionist's role. Describe Actors We describe the target system’s actors in actor specifications, as shown in Figure 6.4. An actor specification consists of three parts: goal, characteris- Account owner Goal: A person who owns an account. The account owner's basic need is to make payments with their plastic card. Characteristics: The system's users include many account owners, with different levels of experience and sophistication. Examples: Account Owner A feels insecure about using a plas- tic card as a form of payment. Owner A originally got a card be- cause it was the only way he could get an ID card for his checks. Owner A only withdraws money from the ATM in emergency situations. Account Owner B is technologically curious and she uses the system often, optimally, and to the limit of its abilities. B has never had major problems in understanding the system's possi- bilities, and also examines possibilities that are not obviously accessible. “Figure 6.4: Actor specifications for ‘Account owner” ties, and examples. The goal describes—as precisely as possible—the actor’s role in relation to the target system. The characteristics describe important aspects of actors’ use of the system. When the actor is another system, the characteristics could include the technical interface. The general character- istics can be supplemented with concrete examples. Describe Use Cases The use cases are abstractions of the interactions between the system and the actors. Here, it is vital that you choose suitable abstractions. In the pay- ment system’s actor table and use-case diagrams, we named a total of eight use cases: payment, cash withdrawal, money transfer, registration, moni- toring, error correction, account information, and credit information. Each of these use cases defines a limited interaction between one or more actors in the target system. We delimit a use case based on the specific ac actors’ viewpoint and application-domain tasks. The goal is to collect the manyFind Actors and Use Cases 129 omstatt > couied prompt for oF enter code roject payment amount not approved Figure 6,5; chart diagram for “cash withdrawal” possible ways of using the target system in a few well-chosen use cases. Taken together, your use cases should give an overview; individually they should be abstractions that are both logical and meaningful to the involved actors, You can produce a list of possible use cases by examining the applica- tion domain’s tasks. To determine whether or not the use cases are actually distinct, you must describe them in greater detail. Because use cases are dynamic phenomena, you can describe them using statechart diagrams or text specifications. A statechart diagram defines the different states of the interaction and the different ways the system or actor can change that state. Figure 6.5 shows an example of a statechart diagram, and Figure 6.6 shows a specifi- cation of the same use case. In a use-case specification, the use case itself is briefly but precisely described in a structured text that focuses on the ac- tors. As a supplement, you can also describe the relevant system objects and functions. You can describe a use case with either a statechart diagram, a use- case specification, or both. A statechart diagram provides a good overview of the dynamic process and the logic of a use case, but omits many details. A use- case specification conveys an overview of usage details, but makes it difficult to simply and sufficiently describe its logic.130 Usage Cash withdrawal Use Case: Cash withdrawal is initiated by the account owner, when he uses his credit card to withdraw cash from an ATM. The account owner inserts his card into the ATM, and is then asked, via the screen, to type in his PIN code. The screen will ei- ther show a polite denial, in which case the card will be ejected from the ATM, and the process will be canceled; or the screen will show a menu asking the account owner to choose an amount of money by typing on the ATM’s keyboard. A new sereen picture asks the account owner to approve the transac- tion. If the transaction is not approved, the account owner is again asked to type in an amount. Otherwise, the use case ends by the ejection of the card, and the desired amount of money is paid. Objects: (to be added) Functions: (to be added) Figure 6.6: Use-case specification for “cash withdrawals” In cach use-case description, you should identify individual actors and interactions. You can postpone further detailing (such as how the interac- tions are precisely performed). The purpose of use cases is to provide an overview of the application domain’s interaction with the system. The use cases should be sufficiently detailed to enable developers to identify all functional and interface elements and requirements. You can elaborate on how individual actions are actually performed when you design the detailed user interface. Account information Use case: Account information is started by the administrator, account owner, or liquidity monitor. In order for an account owner to obtain access to information about an account, he should identify himself using a card. The actor states the ac- count number, as well as what information is desired. The sys- tem then responds with the desired information or with a mes- sage stating that the information cannot be disclosed. Objects: Customer, Account. Functions: (to be added) Figure 6.7: Use-case specification for “account information”Find Actors and Use Cases 131 Deposit ) = information te ssa Loan Bank employee RISA Customer Cn) Figure 6.8: Groups of use cases Although a use-case specification is more detailed than a statechart di- agram, it shouldn’t contain unnecessary details. For example, in the “Ac- count Information” use case, it does not matter whether the actor is a per- son or another system; what matters is that the definition be relevant for all the involved actors. Figure 6.7 shows how you might describe this use case at a more general level, independent of the type of actor. Use-Case and Actor Structures The fundamental relation between actors and use cases expresses which ac- tors can be involved in which use cases. Actors can also be related to each other, as can use cases, which can overlap or use each other. Just as we or- ganized the problem domain by describing abstract structures between the classes and relating the classes by common events, we organize the applica- tion domain by structuring actors and use cases. Although all these rela- tions can be described using extensive use-case diagrams, in our experience this is seldom worth while. Use-case diagrams can show use-case groupings. In Figure 6.8, for ex- ample, use-case groups show that customers participate in all use cases concerning deposits, but only in “payments” under “Loan.” The bank em- ployees participate in all loans, but only “obtain customer information” and “deposit” under “Deposits.”132 Usage 6.4 Explore Patterns Patterns are a source of inspiration that can help you identify and describe use cases. Here we present two fundamental use-case patterns. MEL IAS action 1 action 2 action net } Figure 6.9: General procedural use case pattern The Procedural Pattern In some use cases, you must ensure that business rules are observed. In cash withdrawal, for example, the actor’s access right must be established first, and there must be an extra confirmation of the withdrawal amount. This allows little variation in the actual dialogue. The use case must follow a strict procedure, as exemplified in the cash withdrawal in Figure 6.5. The procedural use-case pattern is the general solution to ensuring that many rules are observed. As Figure 6.9 shows, the pattern’s basic structure is a sequence with minor variations in terms of selections or iterations. The selections and iterations can be described as nested inside the upper level states. The Material Pattern Consider a simple text editing system. The general use case might look like the one shown in Figure 6.10: it is characterized by very little sequence and the actor can do almost anything in any order. The only restriction comes from the two modes—“Cursor positioned” and “Text selected”—which the actor must be in to perform certain actions. The material use case is good for situations in which there are no busi- ness rules governing the usage. The pattern is a use case with few general states, in which most actions can be performed. We call this the “material” use case as it resembles an artisan’s material process: Any tool may be used in any order.Explore Patterns 133 ‘open document Toma Irsor po: 'select Figure 6.10: Statechart diagram for simple text editor Figure 6.11 shows an example of a general statechart diagram for the material use case. As the figure shows, some processes consist of a single action, while others involve action sequences that cannot be interrupted. Such action sequences could be described as procedural use cases embedded in the process states. All processes eventually return the use case to the same general state. start action > action 1 [> action 2 General state ee final acton Figure 6.11: General material use case pattern134 Usage A material use case often demands a supplementary description. In this case, you could describe the usage in several scenarios that describe select- ed and typical usage processes. The description of a word processing system might include the following scenarios: write standard documents, design new documents, reuse earlier documents, and cooperate in writing docu- ments. Each scenario is described in normal text combined with drafts of screen pictures. In addition, you can describe the detailed use of each of the facilities as use cases, such as “edit text,” “find text,” and “create table of contents.” 6.5 Evaluate Systematically It is relatively simple to find actors, use cases, and the structures between them. However, for the final result to be a good one, you should thoroughly evaluate the relevance of your candidates. There are three ways to evaluate use cases. First, you should carefully review the descriptions to find mis- takes and inconsistencies. Second, test your use cases to see if they work in practice. Finally, evaluate the social changes in the application domain. The Mechanistic Extreme The Romantic Extreme Work Specialized job Varied job ene Polarized division of labor __No division of labor Many procedures and rules No procedures and rules Regulated by rules Regulated by consequences ‘Autonomy and Monitoring Self regulation Coney Stressful load No performance quotas Little influence on own job Great influence on own job Low general influence High general influence Social No security Security nerghioe No self-realization Self-realization Little social interaction Great social interaction Alienated Integrated Education and No education requirements —_Extensive education require- development ments Stagnation Development Figure 6.12: important issues in use-case evaluationPrinciples ——Ee Systematic Review You should evaluate your descriptions to ensure that they are well formu- lated and provide a good description of the actors’ use of the target system. For this activity, we recommend the following criteria. * Each use case should be simple and constitute a coherent whole. * Descriptions of actors and use cases should provide understanding and overview. * Use cases should be described in enough detail to enable identification of functions and interface elements. Prototypes Experimenting with prototypes is an important approach for evaluating use cases, their contents, and relevance. A basic principle of this activity is that a use case is best evaluated through planned prototype experiments. In these experiments, you should test the use cases with the future users in as realistic environment as possible. We explain prototype experiments in greater detail in Chapter 2. Social Changes in the Application Domain OOA&D focuses on developing the system and not on changing the organi- zational context, though this is an important part of many projects. To per- form this activity, you must supplement OOA&D with other methods focus- ing on design of the work processes and organizations. Figure 6.12 summarizes several important parameters and choices that you can use to evaluate use cases and their social implications. The figure relates to the fundamental use-case patterns: Procedural use cases favor the mechanistic extreme, whereas material use cases favor the romantic extreme. 6.6 Principles In this chapter, we analyze actors and use cases in the application domain. The guidelines we provide for defining the system’s interaction are based on the following principles. Determine the application domain with use cases. Use cases help to focus your analysis on relevant parts of the application domain and pro- vide descriptions at a relevant and homogeneous abstraction level. The use-case activity is an important step toward identifying re- quirements for the system’s functions and interfaces.136 Usage Evaluate use cases in collaboration with users. Experiments with proto- types are well suited to use-case evaluation and can provide inspira- tion for new use cases. Assess social changes in the application domain. Developing a new sys- tem is an opportunity to critically rethink the work organization in the application domain. The goal is to avoid work-related problems and unnecessary human adjustments. Because we do not provide an exhaustive account of issues related to orga- nizational change and work-related design, we recommend that you explore other approaches and local traditions in this area. 6.7 Exercises Review Questions PLP SP OF we What is an actor in relation to a computerized system? What is a use case? What are actor tables used for? How are actor tables and use-case diagrams related? How are actors described? How are use cases described? What are the key features of the procedural pattern? What are the key features of the material pattern? Why is it important to evaluate use cases? How are use cases evaluated? Problems 11. 12. 13. 14, Consider classes and behavioral patterns on the one hand, and actors and use cases on the other. What are the similarities between the two sets of concepts? What are the important differences? Consider the computerized systems you use. Identify examples of use cases that can be described using the procedural pattern and the ma- terial pattern. Choose one from each group of use cases and provide a detailed description of these two use cases in a statechart diagram. Discuss how actors, system functions, and model objects interact in a use case. Start from an example and identify the actor actions, func- tions, and objects involved in the use case. Video rental store, Continue your considerations of the system for managing customers and their rentals in a video rental store (see Ex-Literature 00 BT ercise 3,13). Analyze the system’s usage. Develop the actor table and specify selected use cases. 15. Mobile phone. Continue your considerations of the system for a simple mobile phone (see Exercise 3.14). Analyze the system’s usage. Develop the actor table and specify selected use cases. 16. Teaching administration. Continue your considerations of the system for monitoring student activities in a university department (see Exer- cise 3.15). Analyze the system’s usage. Develop the actor table and specify selected use cases. 17. Elevator control. Continue your considerations of the system to control elevator movement in a building (see Exercise 3.16). Analyze the sys- tem’s usage. Develop the actor table and specify selected use cases. 6.8 Literature Use cases were originally introduced by Jacobson et al. (1992). They play a central role in Jacobson et al. (1999) and most other modern object-oriented methods. It should be noted that UML defines a use case as only the sys- tem’s actions (see, for example, Rumbaugh et al. (1999)). Taken literally, this yields rather awkward, one-sided descriptions of interactions. Most au- thors, including Larman (1998) and Jacobson et al. (1992), prefer the defini- tion we use here, where a use case is an interaction that includes both actor and system actions. Birkle et al. (1995) and Budde et al. (1992) describe an object-oriented approach that fits this description of use cases. With this approach, both the existing execution and the new work organization are described. In OOA&D, we emphasize the users’ perspective. But there are at least two important limitations to our method's support of work processes and or- ganizations. First, OOA&D is a method for analyzing and designing sys- tems. If need be, the method should be supplemented with theories or meth- ods that deal with the design of organizations and work processes. Arnberg & Bjorn-Andersen (1984) provide a simple and practical introduction to the most important parameters and options for work design, especially in con- nection to the application of computerized systems. Figure 6.13 is based on this account. “Business process reengineering” is one recent effort aimed at creating a methodic basis for improving efficiency and quality in a compa- ny’s fundamental business processes as they relate to information technolo- gy use. Davenport (1993) describes one method in this area, and Jacobson et al. (1995) connects the fundamental process analysis with use cases. Dahlbom & Mathiassen (1993) discuss the relationship between the mecha- nistic and the romantic perspectives of system development and use. Second, OOAKD is an object-oriented method. If necessary, the method should be supplemented with other system development methods that sup-