In Lesson 9 we will slow down the pace and volume of material to examine use case modeling as a technique for documenting spatial system requirements. This is an extremely important lesson because no other part of the spatial system design is as difficult as establishing the detailed technical requirements. This lesson is also important because of the growing application of use case modeling, a tool that aids the communication between analysts and users in documenting requirements. We will discuss use-case modeling and the somewhat abstract definitions of actors, associations, and extends, uses, depends on, and inheritance relationships. It is also the first lesson on modeling which serves as a bridge from the earlier lesson on the techniques of systems analysis.
If you have any questions now or at any point during this lesson, please feel free to post them to the Threaded Discussion Forum. (That forum can be accessed at any time by clicking on the Communicate tab, above, and then scrolling down to the Discussion Forum section.)
To finish this lesson, you must complete the activities listed below. You may find it useful to print this page out first so that you can follow along with the directions.
Step | Activity | Access/Directions |
---|---|---|
1 | Read the lesson Overview and Checklist. | You are in the Lesson 9 online content now. The Overview page is previous to this page, and you are on the Checklist page right now. |
2 | There are three different styles of reading that are referred to in the lessons:
|
|
3 | View the Lesson Overview. | You are in the Lesson 9 online content now. Click on the "Next Page" link to access the Lecture/Discussion. PowerPoint [1]. |
4 | Geospatial Think-Piece (Template) [2] |
Using Word (or a word processing program compatible with Microsoft® Word), identify and briefly discuss (<200 words): what benefit the concept of use cases brings to your team's design project. Name your file Lsn9_YourName.doc. Please turn-in your document the Lesson 9 Dropbox in ANGEL. What is a “Think Piece”? A “think piece” is a form of writing that is less polished than a formal paper or presentation but more fully developed than an entry in a personal journal. Think pieces are written to discover what an individual is thinking about a particular topic. Within this course, the writing of think pieces is a way of helping learners connect with the subject matter. Within this context, think pieces reduce the grading risk associated with an “all or nothing” term paper and allow the instructor to communicate with learners throughout the semester, to see the evolution of thinking, and to suggest resources that can further the learners’ understanding. What does a Think Piece look like? The starting point for a think piece for this course lie in the author’s immediate past experience. Because think pieces are as much a reflection of one’s ideas, there is no standard or uniform format for a think piece. In other words, each of us is writing from personal experience. We are not claiming to be objective not are we offering prescriptive, how-to, formulas or guidelines. |
5 | Read lesson Summary. | You are in the Lesson 9 online content now. |
Use case development begins in the early inception phase of a project. Initially, you only gather their names (e.g., "Draw map of poles") and a sentence or two for a description and put them in a list. These are used to determine the system scope. You revisit each use case and add just a bit more detail to it - a paragraph or two of text sufficient to get a high level understanding of the use case (these are called High-level use cases, and each is a separate document). At the end of inception, you choose a group of related use cases for development in the elaboration phase. Use cases go through several iterations of development in elaboration.
Use cases are analyzed and designed in meetings with the design team (at least one other person) and a subject matter expert. They will be developed in several phases, each of which will require a separate meeting. The users participate in developing use cases - they understand what they do, and you don't. For a given use case or group of related use cases, identify the people that perform that particular job or task and invite one or two to participate in a meeting between you and one or two other members of the design team.
An actor is a role adopted by someone or something that interacts with the system. It can be a person or another software system. Actors are always external to the system; that is, an actor is something that interacts with your system but that you have no control over. Actors typically initiate some interaction with your system. However, external systems may be an exception. For example, you might have a use case that asks the tax billing system for a list of owners for a parcel. A given user may play the role of several actors. Use cases are a series of interactions between an actor and the system to accomplish some task. As such, they are the fundamental element of your design effort. Full analysis of a use case will lead to a definition of the data the actor needs to do the task, the interface the actor works with and the process followed to accomplish the task. Here are some questions that can help you identify potential actors:
As you define an actor, consider the types of tasks she would perform with the GIS. These become candidate use cases. Also, some of your project requirements may become use cases. You document actors and use cases in several ways. Your initial meetings with management will identify many of them, and you'll probably start with simple lists. For a complex project, you should put them in database tables because project details are easier to manage with a database.
This UML artifact is a system diagram that shows the relationships between the use cases and the actors that use them. Use case diagrams are important tools that help you to visualize the overall system architecture, to specify and document the behavior of system elements (actors and use cases) and to organize and model the behavior of your system.
Use cases are considered part of the UML, but there is no standard for use case structure or content. You are free to develop any format you like. The key point is to clearly capture the business process in a textual, narrative form. The primary goal from a data modeling perspective is to ensure that all the important concepts (potential classes in the geodatabase) required by the use case get mentioned.
The basic structure of all levels of use case is the same - you include "header" information that names the use case, states its level, summarizes it, identifies the actors and the pre- and post-conditions. The major structural difference is in how the description is written. For business and design level use cases, you replace the description with more detailed "scenarios" that describe the typical path through the use case (the primary scenario), any alternate paths (the secondary scenarios) and how errors are handled (the exception scenarios).
Use cases are written at several levels of details. Each level is a refinement of the one before, until you have captured the essential actor I system interactions. A use case normally goes through several iterations before it is finalized. The levels are:
Business level and design level use cases generally have scenarios. The types of scenarios are:
A use case diagram captures the business processes carried out in the system. Normally, domain experts and business analysts should be involved in writing use cases. Use cases are created when the requirements of a system need to be captured. A use case diagram is quite simple in nature and depicts two types of elements: one representing the business roles and the other representing the business processes. Let us take a closer look at use at what elements constitute a use case diagram.
To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system.
The above figure shows two uses cases: "Make appointment" and "Perform medical tests" in the use case diagram of a clinic system. As another example, consider that a business process such as "manage patient records" can in turn have sub-processes like "manage patient's personal information" and "manage patient's medical information." Discovering such implicit use cases is possible only with a thorough understanding of all the business processes of the system through discussions with potential users of the system and relevant domain knowledge.
The figure shows the system boundary of the clinic application. The use cases of this system are enclosed in a rectangle. Note that the actors in the system are outside the system boundary.
The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case. For large and complex systems, each of the modules may be the system boundary. For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions. The entire system can span all of these modules depicting the overall system boundary.
Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. Defining a relationship between two use cases is the decision of the modeler of the use case diagram. This reuse of an existing use case using different types of relationships reduces the overall effort required in defining use cases in a system. A similar reuse established using relationships, will be apparent in the other UML diagrams as well. Use case relationships can be one of the following:
For example, you can see that the functionality defined by the "Validate patient records" use case is contained within the "Make appointment" use case. Hence, whenever the "Make appointment" use case executes, the business steps defined in the "Validate patient records" use case are also executed.
On the face of it, both generalizations and extends appear to be more or less similar. But there is a subtle difference between a generalization relationship and an extend relationship. When you establish a generalization relationship between use cases, this implies that the parent use case can be replaced by the child use case without breaking the business flow. On the other hand, an extend relationship between use cases implies that the child use case enhances the functionality of the parent use case into a specialized functionality. The parent use case in an extend relationship cannot be replaced by the child use case.
Let us see if we understand things better with an example. From the diagram of a generalization relationship, you can see that "Store patient records (paper file)" (parent) use case is depicted as a generalized version of the "Store patient records (computerized file)" (child) use case. Defining a generalization relationship between the two implies that you can replace any occurrence of the "Store patient records (paper file)" use case in the business flow of your system with the "Store patient records (computerized file)" use case without impacting any business flow. This would mean that in future you might choose to store patient records in a computerized file instead of as paper documents without impacting other business actions.
Now, if we had defined this as an extend relationship between the two use cases, this would imply that the "Store patient records (computerized file)" use case is a specialized version of the "Store patient records (paper file)" use case. Hence, you would not be able to seamlessly replace the occurrence of the "Store patient records (paper file)" use case with the "Store patient records (computerized file)" use case.
If you have questions at any time during this lesson, please feel free to post them to the Discussion Forum. (Click on the Communicate tab to access our course discussion forums.)
In this lesson you learned about use cases. A use case diagram shows which actors interact with each use case. In more detail, the basic elements of a use case diagram are:
If you were analyzing a sentence in English, the subject in the sentence could be identified as a potential actor and the verb part of the sentence could be a potential use case. Remember, this may or may not apply to the problem at hand, but is a good starting point for use case modeling.
This lesson is a bridge from the discussion of general techniques of systems analysis to modeling a system. It was an extremely important lesson because of the growing application of use case modeling. The next lesson will be much faster in pace and focus on the skill of data and object modeling. The next lesson will also address feasibility analysis of alternative systems solutions.