Ch04 System Purpose.docx

Chapter 4 – Conceptual Design: System Purpose, Actors, Features and UML Use Cases CHAPTER OBJECTIVES (YOU SHOULD BE ABLE TO): 1. Define and give examples of the purpose of an information system. 2. Describe and give examples of actors. 3. Describe and give examples of features in an information system. 4. Define the UML Use Case notation and be able to draw a use case diagram. Getting started! For many people, these two words represent an enormous hurdle or mountain to climb over. That term paper! That big test to study for! The whole apartment needs cleaning! Writing all those "thank you" letters! Many projects seem overwhelming as we think about just getting started. Getting started with the technical/engineering aspects an information systems development project can also be difficult because there are so many ways in which one could actually begin a project—for this discussion we are omitting the project management aspects associated with starting and keeping track of an information systems project status. You may recall that a few "ways to get started on an information systems development project" was discussed in Chapter 2 as part of the requirements determination discussion. In that chapter three dominant problem-solving strategies were identified—function, data, and object. To review briefly, the functional problem-solving strategy approaches a problem by first identifying the actions the system must accomplish, such as "register for a course", "drop a course", "check out a movie video", and so on. The data problem-solving strategy approaches a problem by first identifying the data that the system is responsible for, such as "student information", "course information", "schedule information", "movie video information", and so on. Finally, the object problem-solving strategy approaches a problem by simultaneously focusing on objects, such as people, places, things and concepts and the object's attributes (data) and operations (services). For obvious reasons an object-oriented problemsolving strategy best fits with an objectoriented systems analysis and design methodology. Because of this, we will begin by identifying the information systems purpose or mission. Then we will identify the most important features to be performed by the information system that will naturally lead us into the creation of Use Cases that are object-oriented. INFORMATION SYSTEM PURPOSE The overriding purpose of any information system is to support the mission of the enterprise. For example, Microsoft is ultimately in the software business to provide a good return on investment for its stockholders. To do this Microsoft makes and sells software (along with other services). One could then say that, "The overriding purpose of Microsoft's Windows 2000 Operating System software is to contribute to the revenue stream at Microsoft." In another example, Amazon.com is similarly in business to do the same thing—provide a good return on investment for its stockholders. Amazon.com's web-based storefront software's purpose is to facilitate customers purchasing products from Amazon.com thus contributing to its revenue stream. Every information system has a purpose or mission that it is intended to fulfill regardless of whether the information system is, 1) in the form of a shrink-wrapped box of software (and other goodies) for sale, 2) embedded within another type of device or appliance such as a cell phone or pager, or 3) used to support the internal operations of an enterprise such as a web-based product order fulfillment system. As stated at the start of the preceding paragraph, an information system is intended via its purpose to support the overall mission of the enterprise in some way. Sometimes this support is obvious and significant—such as each of the above examples—and other times its support is not obvious and perhaps not terribly significant. Identifying the purpose of an information system is sometimes easy and almost seemingly trivial to do; other times it is evasive and difficult to do. No matter how simplistic the task of identifying the purpose seems, do not skip it or ignore it as the purpose sets the framework and provides a written "anchor" guide for all development work that will follow. For example, one of the early activities in the object-oriented systems development life cycle is to identify actors and system features. Both actors and features can often be justified by reflecting back to the purpose of the information system. The actors and features that do not appear to support the system's purpose should be challenged, questioned, evaluated, reconsidered, and possibly omitted from the information system. In his book Object Models: Strategies, Patterns, and Applications, Peter Coad gives several examples of information system purposes as follows: For Connie's Convenience Store (similar to a 7-11 or Circle-K no doubt): The purpose of the information system is "To help each cashier work more effectively during checkout, to keep good records of each sale, and to support more efficient store operations." (Page 3) For Wally's Warehouse (any warehouse application): The purpose of the information system is "To improve warehouse profitability by helping team members put away and pick items more efficiently…by keeping more accurate inventory counts, and by increasing fill rate." (Page 100) For Ollie's Order Center (any order-entry [fulfillment] application): The purpose of the information system is "To improve the efficiency and accuracy of taking orders, shipping orders, and billing for orders." (Page 154) For Dani's Diverters (any real-time conveyor application): The purpose of the information system is "To control the conveyor and route each tote to the loading dock we assign to its order." (Page 198) For Andi's Autopilot (any real-time control application): The purpose of the information system is "To maintain aircraft altitude, direction, and attitude during the en-route segment of a flight." (Page 244) As you read the above purpose statements, several common attributes surface: Each statement is 25 words or less—25 words is not a rule that cannot be violated, however the spirit of a purpose statement for an information system is to keep it as specific and as brief as possible. Each statement is proactive—hence it uses words such as, "to help", "to improve", "to control", "to maintain", "to support", and "to facilitate". Again, not a rule but a good guideline to follow. Each statement supports the overall mission of the enterprise. This may not appear obvious when reading the purpose statements; however, if you were the systems analyst participating in the dialog with the managers and users when these purpose statements were created, you would know that these statements support the overriding organizational mission. Each statement is broad in scope, yet specific to the problem domain. You will note that I added "(similar to…)" or "(any … application)" to the above five examples. Many information systems are common across specific business industries, hence their purpose statements can be broad in scope on the one hand, but they must also be specific enough to be meaningful to the people in the specific problem domain environment that you are working on. Each statement is void of technology jargon. Purpose statements usually have no need to mention computer or other technology buzzwords as they attempt to help define "what the information system will do" rather than "how the information system will do it." The purpose statement for an information system does not "just appear" out of nowhere. It takes work to create a meaningful one! A good amount of discussion between the systems analyst and the managers and users of the problem domain preceded the discovery of the above purpose statements. Keep in mind also that it is a bad idea for the systems analyst to create the purpose statement without the assistance and concurrence of the managers and users in question. Now that you have an idea of what a purpose statement for an information system looks like, how does the systems analyst and the users discover one for their information system? The answer is that in almost all cases the systems analyst and the users must discuss and dialog about the boundaries of the information system—namely, actors and features. Two simple questions—simple to ask, often challenging to answer—to do this are: "Who interacts with the information system?" (Actors) and "What must the information system do?" (Features). So, the first activity, which is to identify the information system purpose, is most likely done in conjunction with or parallel with activity two which is to identify actors and features. Or at a minimum, the systems analyst should have a general overview discussion of actors and features with the users prior to identifying specific actors and features in activity two. In other words, it is difficult to create a purpose statement until one knows something about the proposed information system. ACTORS AND FEATURES Which came first—the chicken or the egg? Such is the case with actors and features! Sometimes the identification of actors can precede the identification of features, other times the reverse is true. Most often both are discovered at the same time. Once again, subject matter expertise of a problem domain is mandatory for identifying the necessary actors and features. The less subject matter expertise the systems analyst has, the more she will rely on the users to help identify the necessary actors and features. The more expertise the systems analyst has in the problem domain, the more likely there will be a healthy dialog between the analyst and the users as they together discover the actors and features. What are actors? The Unified Modeling Language Reference Manual defines an actor as "An abstraction for entities outside a system, subsystem, or class that interact directly with the system. An actor participates in a use case or coherent set of use cases to accomplish an overall purpose" (Page 144). Booch, Rumbaugh and Jacobson define actor as "A coherent set of roles that users of use cases play when interacting with the use cases" (Page 457). Simply stated, actors are roles people or other information systems play when interacting through a use case with this information system. In her book Visual Modeling with Rational Rose and UML, Terry Quatrani suggests the following regarding actors (Page 21): Actors are not part of the system—they represent anyone or anything [another system] that must interact with the system Actors input to and/or receive output from the information system Actors are often identified via conversations with subject domain [matter] experts Quatrani also suggests a number of questions that the systems analyst could ask the domain experts to help identify the necessary actors (Page 21-22, with some adaptation made by me): Who is interested in a certain requirement? Where in the organization is the system used? Who will benefit from the use of the system? Who will supply the system with this information? Who will use this information? Who will remove this information? Who will support and maintain the system? Does the system use any external resources? Does one person play several different roles? Do several people play the same role? Does the system interact with a legacy (older) system? What are some examples of actors for an information system? Referring back to the Video Store information system example at the end of Chapter 3, the following actors would most likely be identified [synonyms in brackets]: Customer(s) [member, guest, patron, client] Video store manager(s) [supervisor, assistant manager, store owner] Video store worker(s) [sales clerk, receiver, customer service representative, stock clerk, accounting clerk] Supplier(s) [vendor, merchant, distributor, wholesaler] Delivery person(s)/company(s) In the UML actors interact with use cases. Use cases will be discussed in more detail later in this chapter. For now a use case represents a significant feature of an information system which could be interpreted to mean that use case and feature are synonyms for each other. The domain experts are more likely to immediately relate to a discussion about features of their system rather than trying to indoctrinate on the notion of a UML use case approach at this point in the development process. Eventually they will be reviewing use cases, but for now let's talk about features. A feature is a prominent or significant functional, behavioral or descriptive part of an information system. Features can be broad or general in scope—in other words, descriptive—such as: The system will be user-friendly The system will respond to user requests within 3 seconds The system will have appropriate security The system will support 500 simultaneous users Etc… The above descriptive features are important and need to be identified sometime during the requirements determination and/or conceptual design activities for a real system. However, we need to focus our attention in this section of the chapter on more specific features—those that describe the functionality and/or behavior of the information system. So, a feature in the context of system functionality or behavior can be thought of as an end-to-end (start-to-finish) significant process of the information system. This definition often evokes the following question, "How 'big' is a feature?" or correspondingly, "How 'small' is a feature?" Both of these questions deal with the issue that software developers refer to as granularity—how broad or how narrow (big or small). The answer to the 'big' and 'small' questions is, "It depends!" (Sorry to be vague!) Once again, the problem domain requirements drive the answer to these questions. But, the key point to keep in mind is the "end-to-end" or "start-to-finish" aspect of the feature definition stated above. What do I mean by this? Well, a feature should represent an important function of the system that, when performed by the system, produces some meaningful result(s) for the actor(s) requesting or interacting with the function. Here are some candidate features for a variety of problem domain information systems: Register for a course Drop a course Request a print-out of your current semester's course schedule Purchase supermarket items at the check-out counter Rent an automobile Return a rented automobile Make a monthly automobile lease payment Purchase a book via a web-store Verify your bank account balances (multiple types of accounts) via the web Verify your bank account balances (multiple types of accounts) via your telephone Fill bottle (can) with liquid Move an elevator from floor "x" to floor "y" Even with the above examples, it is still more of an art than a science to determine features. For example, is "guide a space shuttle flight" a feature or many features? Is "make a lunar landing" a feature or many features? Is "play a video game" a feature or many features? My answer would be that these are examples of features that also have sub-features within them that should be identified, discussed and documented. Features, thus use cases, interact with actors as they fulfill a role for the system. Remember, that actors can be both human and other systems. We should be able to associate a feature with a specific actor(s), and a specific actor may interact with one or more features. Peter Coad (Pages 3-5) suggests classifying features into one of four classifications: log important information, conduct business, analyze business results, and interact with other systems. These classifications can help us to identify the significant features of a system. As such, use them if they help you. Here is a brief definition of each classification along with an example or two for clarification: Log important information. Most information systems need reference (master, foundational) data to be stored in databases in order to commence being used. For example, students could not use a course registration system to register for courses prior to a course schedule database being available as part of the information system. As I write this chapter, our campus staff is in the midst of creating next semester's course schedule database in anticipation of students starting to register for courses for next semester in about 30 days. People could not make an airline reservation for the upcoming holidays until the airlines create their future flight schedules. The maintenance of this reference data becomes a very important and necessary feature of an information system. The word maintenance (or maintain) implies adding, changing, deleting and viewing data in the database by authorized individuals. Adding means to add new objects—such as new students, new courses, and new professors—to the database. Changing means to revise facts pertaining to existing objects in the database—such as changing a phone number of an existing student, changing the course title of an existing course, and changing the office hours of an existing professor. Deleting means the removal or deletion of an object from the database—such as removing students who no longer attend the university from the database, removing courses which are no longer being taught from the database, and removing professors who no longer work at the university from the database. Viewing means the ability to print a report or display a list of the data in the database—such as a report (display) of student names and addresses, a report (display) of course numbers and names, and a report (display) of professor names and other known facts about them. Conduct business. If the reference data are foundational to an information system, then conducting business can be viewed as "its reason for existence." This classification includes features of the information system that have a transaction-like quality to them or represent important processing that the system needs to perform. Some examples could be: "checking-out a book from the library", "returning the book to the library", "buying products at the department store", "receiving inventory from suppliers", "moving an elevator from floor 'x' to floor 'y'", and "processing the weekly payroll". Analyzing business results. This classification represents what all users mainly want from a system—output. The most obvious examples of these types of features are reports and displays of information. Some examples of both reports and displays of information are: "print (display) the daily sales report", "print (display) the overdue books report", and "print (display) inventory availability". Each of these examples represents "analyzing the business" and gives one the opportunity to monitor the results of the activities performed and managed by the system. Interact with other systems. Most systems have a need to exchange data with other systems. Either our system sends data to another system or their system sends data to ours, or both. For example, a pharmacy information system's purpose is to assist the pharmacist in filling prescriptions for her customers. When the information system detects that the pharmacy is running low on a particular prescription drug—say Rogaine (helps to grow hair!) for example—a feature of the information system may actually interact via the internet with a pharmaceutical company's order fulfillment system to place a reorder for a certain quantity of that prescription drug. This type of feature where an information system of one company interacts with an information system of another company is referred to as B2B—business-to-business. UML USE CASE The UML's use case is an excellent dynamic visual modeling tool that combines actors and features together. Certainly a systems analyst could simply create a word processing document combining actors and features as shown in figure 4.1 below. For simple systems this may be all that is required, but for industrial-strength information systems this document is just the starting point. Creating a visual use case model diagram (blueprint) by hand or with the help of an automated IDE tool is the next step. Figure 4.2 illustrates a simple and incomplete use case diagram that could have been drawn by hand, and Figure 4.3 illustrates another simple and incomplete use case diagram that was created using the Rational Rose IDE tool. The Unified Modeling Language Reference Manual defines Use Case as, "The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors." Quatrani suggest the following definition for a use case: "A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor [or vice versa]" (Quatrani, p. 26). For purposes of this text I prefer to use Quatrani's simplified definition stated above with the additon of "[or vice versa]" that I added since an actor may simply be required to provide a use case with something of value and not necessarily receive anything of value from it. As was mentioned in the prior section of this chapter a use case can be considered a synonym for features. As such, use cases can also be discovered in a similar fashion, as are features. Quatrani suggests the following questions to help a systems analyst discover use cases (Quatrani, p. 25). These are also good questions for discovering features: What are the tasks of each actor? Will any actor create, store, change, remove, or read information in the system? What use cases will create, store, change, remove, or read this information? Will any actor need to inform the system about sudden, external changes? Does any actor need to be informed about certain occurrences in the system? What use cases will support and maintain the system? Can all functional requirements be performed by the use cases? center000 center000 center000 A use case diagram combines several use cases and their associated actors together as one model. How many use cases should be in a use case diagram? Should all use cases be in just one diagram? The answer to both of these questions is once again "It depends!" Smaller industrial-strength systems could show all use cases in one diagram whereas larger systems could be partitioned into several use case diagrams each showing a portion of the system—the use cases in each diagram would more than likely be related in some meaningful way. center000 As you look at the above use case figures you might have the tendency to think, "These sure look simple, almost trivial to construct." Well, you are correct in your thinking—a use case (and its diagram) is quite easy to construct since there are only seven (7) notation symbols available to use for constructing one. However, you might be incorrect in your thinking also! "How is that?" you say. Well, the real work is identifying and discovering the actors and features for the information system—the requirements determination activity. Putting these actors and features into a use case diagram is the conceptual design culmination activity that naturally follows this discovery and identification activity. The seven (7) notation symbols used in a use case diagram are shown in Figure 4.4 below. An initial use case or set of use cases does not need to include all of the notations. More than likely, these initial use cases would just include actor, use case, association and boundary notations. Later on, as more is discussed and discovered about each use case, additional notations and additional use cases could be added to the diagram. Figure 4.5 illustrates the inclusion of the generalization, extend and include notations. center000 SUMMARY This chapter presented the following topics: 1. The purpose of an information system. The purpose is foundational and should support the mission and goals of the organization intending to implement the information system. No matter how trivial it seems to identify the purpose, it should be done. Short purpose statements—for example, 25 words or less—are usually sufficient. Purpose statements should be proactive, broad in scope, yet specific enough to relate to the problem domain, and be as free of technology jargon as possible. 2. Actors for an information system. Actors are people or other systems that are separate from the information system being developed who play a role when interacting through a use case with this information system. Actors usually input data to and/or receive data from the information system. 3. Features of an information system. A feature is a prominent or significant functional, behavioral or descriptive part of an information system. Features are broad or narrow in scope. Broad features relate to the information system as a whole, such as "The information system will have appropriate security." Narrow features usually target specific end-to-end (start-to-finish) user-involved functionality of a system, such as "Make a deposit at the Automatic Teller Machine." Features are synonymous with use cases. Each narrow-type of feature can often be classified in one of four ways to help improve communication between project team members—log important information, conduct business, analyze business results, or interact with other systems. 4. Discussion of the UML Use Case and its notation. The UML's Use Case is a dynamic visual modeling tool that combines actors with features. A use case typically represents a major piece of "start-to-finish" functionality and must provide something of value to an actor or vice versa. Use cases are drawn with up to seven (7) notation symbols depicting: actor, use case, association, generalization, extend and include. A number of use cases may be combined in one use case diagram.