Actors
Use case modeling begins with the identification and documentation of users, or actors. The main purpose of developing a software solution is to provide for the needs of these users. The actor also indicates how the system will be used (hence the term use cases). Actors provide the core starting point for the rest of modeling, design, and development in a software project.
An actor is a role played by a person or a thing that is external to the software system. An actor (user of a system) interacts with the system in order to achieve business goals. An actor is:
■A role played by a typical user of the system (note: the actor is the role and not the actual person who is playing that role)
■A role that initiates an interaction with the system (such as a patient, who may not always interact with the system but whose presence invokes actions and responses)
■Time is considered an actor because time-triggered events initiate an interaction or a process within a system
■A role that derives benefit (achieves goals) from the system
■An “external system” with which the system under development will interact (such as a publicly available database or service)
■An external device with which the system under development will interact (such as a printer or handheld phone)
■Anything that sends a message to the system (such as an external entity)
■Anything that receives a message from the system (such as another system)
■Essentially anything that is outside the system
In addition, it is also worth noting the following about an actor:
■An actor may participate in multiple use cases because each actor is capable of initiating multiple processes within the system and have multiple goals to achieve from the system. An actor may serve as a starting point for interface modeling because an actor represents the interface of the system (interface modeling is discussed in Chapter 16). Finally, an actor may serve as the basis for good classes (however, an actor, as a business user itself, is not a class—this is explained later in this chapter).
As with everything else in an iterative and incremental life cycle, the first cut of actors is created from those users who will initiate a transaction with the system or who will derive some benefit from the system. While users are invariably actors, not all actors are human users. External systems and devices are also represented as actors. Since actors interface with the system, they are not built. Actors are what the developers are responsible for “interfacing with,” whereas use cases, discussed later, represent that which is “implemented.”
In the UML, an actor is represented by a “stick figure.” Figure 5.1 shows this representation for ActorPatient for the hospital domain.
Figure 5.1Notation for an actor.
How to Find Actors?
Finding good actors is the first and most important activity during analysis in the problem space. Not paying enough attention to identifying, discussing, and documenting actors can lead to unacceptance of the solution by the users. Often a lack of understanding of actors causes rework, delays in delivery of the solution, and overall dissatisfaction among users. On the contrary involvement of users at this early stage of modeling requirements assures their participation right through to the user acceptance testing stage.
During the initial iteration of use case modeling, a list of actors is created. Do not try to complete this list at the first attempt. Identification and documentation of use cases, drawing of activity diagrams, and subsequent identification of classes will invariably lead to the refinement of this actor list. Iteratively adding to the list of actors or modifying some of the actors is in accordance with the iterative and incremental (Agile) process.
Identification of potential actors and use cases happens in a workshop environment. The following are some of the questions that can be asked in a use case modeling workshop in order to arrive at a preliminary list of actors:
■Who will be the main and secondary users of the system?
■Who will be the primary beneficiaries of the interactions with the system?
■Who will be the primary initiators of interactions with the system?
■What external systems and devices will the system under development need to interface with?
■Is there a time-based process in the system?
A potential list of actors for the hospital management system (HMS) is shown in Figure 5.2. Note that there are three categories of actors in this diagram. They are the roles played by human actors interacting with the system, external systems, and devices. These actor categories have been roughly separated in Figure 5.2 for better understanding.
Figure 5.2Potential list of actors for HMS.
Actor Variations
In addition to the three groups of actors shown in Figure 5.2, there are also a number of variations in the types of actors that can appear in a system. In most practical analysis work, where business processes and workflows are modeled in the problem space, these actor variations do not have a major impact on the solution. Being aware of actor variations is beneficial in order to prevent potential confusion during modeling. Some of these variations are discussed next.
Primary versus Secondary Actors
The primary actors are those for whom the system exists. These are the main actors who benefit from the system—for example, a patient, a doctor, or a nurse in a HMS. The secondary actors are roles of indirect relevance in the HMS. For example, if a medical assistant is involved in processing a blood sample, but is not involved in the actual execution of any of the use cases, then she is an indirect actor. This variation of primary versus secondary actors depends on the perspective of the system. For example, if the system has use cases that deal directly with input of blood samples and test results, then the lab assistant will become a primary actor. A common example from the banking domain is that of a customer and a teller. Even if the customer, standing across the counter to withdraw cash, does not use the computer screen, she is still a primary actor. This is because the system exists for the purpose of this actor, and of course it is this actor that initiates the interaction.
Direct versus Indirect Actors
Direct actors are those who actually use the system. For example, an administrator keying in the details of a patient is a direct actor, whereas the patient, standing across the counter and providing her details, is an indirect actor. This is because the patient never gets to use the system directly. In the earlier example from the banking domain, the customer is an indirect actor, whereas the teller is a direct actor. Both direct and indirect actors are important and appear in use cases.
The understanding of whether an actor is primary or secondary, direct or indirect, is entirely dependent on the context of the actor’s use of the system. For example, a patient that is indirect while standing across the counter would become a direct actor when accessing her details on the Internet. There is often no specific need to mention actors as primary/secondary or direct/indirect. This differentiation is for the understanding of the business modelers, but this differentiation may be mentioned in actor documentation when it helps clarify the modeling effort in the solution space.
Abstract versus Concrete Actors
The third variation among actors is abstract versus concrete actors. This actor variation is more important than the previous two and can be specifically shown in use case diagrams. The UML permits actors to be generalized. This means an actor can inherit the definition of another actor. For example, a “private patient” and a “public patient” may inherit all the characteristics of a patient. As a result, the actor patient will become abstract and the private and public patients will become concrete actors. Abstract actors are at a common or higher level (generalized) in the model, from which concrete (specialized) actors are derived.
Generalization/specialization provides opportunities to reduce the complexity in use case diagrams. Abstract actors can model the common behavior of a system, such as staff logging into the system. Concrete actors model the specific behavior of the system, such as a doctor checking a consultation schedule on the calendar. Since a doctor inherits from staff, there is no need to separately model the log-in procedure for doctors if it has already been modeled for staff. Thus, a generalization of actors results in an actor hierarchy that reduces clutter and complexity in the use case diagram.
Actor hierarchies can be shown in a separate diagram. Figure 5.3 shows two separate hierarchies of actors: the patient hierarchy and the staff hierarchy. Nonhuman actors may not be shown in an actor hierarchy diagram unless they are related by inheritance. The relationship between abstract and concrete actors is that of inheritance (note the use of a formal inheritance arrow in the UML; these relationships are discussed in Chapter 6). Abstract actors A10-Patient and A50-Staff are shown in italics—as required for abstract entities in the UML.
Figure 5.3Abstract versus concrete actors and a corresponding actor hierarchy in HMS.
Clarifying Actor-Class Confusion
Notice that the actor names have been prefixed with A10-, A20-, and so on. This numbering of actors, although not mandated by the UML, is a good way to group and document actors. Furthermore, prefixing actors with either the term “actor” or a simple numbering system helps avoid another potential confusion, that between an actor and a class.
Consider, for example, the actors Patient and Doctor. They appear to be straightforward roles played by users in a HMS. However, when the classes for the HMS are identified, the names for those classes tend to be the same as for actors.
Figure 5.4 shows the actor A10-Patient. This patient is the user of the system. The user will interact with the system and, as such, is outside the system. There are various attributes of the patient, such as his name, address, and medicare card number, that need to be stored in the system. The class that stores these details inside the system is likely to be called Patient as well. This Patient class is not the same as the actual user outside the system. In fact, the Patient class is designed and stored inside the system. It is important that this Patient class be differentiated from the Patient actor. A good way of creating this differentiation is by prefixing the actor names with the term “actor” or, as has been done here, with a simple numbering scheme. The prefix A10- for a patient refers to the actor, whereas a term without a prefix—such as Patient—refers to the class.
Figure 5.4Distinguishing actors from classes.
Actor Documentation
Having identified the list of actors, it is now important to document them. Although this documentation of actors is not mandatory, in practice it is always useful to document at least the main (or important) actors. This documentation improves understanding of the actors and is helpful in identifying use cases. Discussions with users and domain experts can also be stored in the actor documentation. Additionally, there are business rules and constraints specific to an actor that can be placed in actor documentation. Although modeling tools provide an opportunity to document actors, for some primary actors this can be done in a separate Word document and linked to the actor notation.
Documentation for an actor is not to be completed in a single attempt. First, the actor name and a brief description is provided. Then a few use cases corresponding to this actor are documented. As a result, more details of the actor are added to the actor documentation. The following template provides a starting point for actor documentation, followed by an example of actor documentation for the HMS.
Actor Thumbnail
<Name of the actor. Optionally, a number prefixes the name to facilitate grouping of actors. The prefix also differentiates the actor from a possible class with the same name.>
Actor Type and Stereotype
<Describes the type of actor. This can include whether it is a primary or secondary actor, person or external system or device, or if the actor is “abstract” or concrete. The type of actor may be described in general or it may be a formal stereotype.∗>
Actor Description
<Short description of the actor and what he/she/it does. Together with the actor thumbnail, this might be the only thing documented for the actors in the first iteration.>
Actor Relationships
<Thumbnails of other relevant actors or use cases in the system with whom this actor is interacting. If there is an inheritance hierarchy, thumbnails of generalized/specialized actors can also be noted here.>
Interface Specifications
<Since, by definition, the actor has to interact with the system, we note here the details of the interface through which the actor performs this interaction. This will be a list of the numbers and names of GUI specifications related to this actor—including specifications of Web interfaces. For external systems and devices, it may be a description of the interface that may not be graphic.>
Author and History
<Original author and modifiers of this actor description>
Reference Material
<Relevant references, as well as sources from where material is inserted/available for this actor.>
Actor Documentation for “A10-Patient”
Figure 5.2 showed a potential list of actors for the HMS. One of the actors, A10-Patient, is documented here based on the actor template discussed earlier.
Actor Thumbnail
Actor: A10-Patient
Actor Type and Stereotype
This is an abstract actor representing all types of patients in the HMS.
Actor Description
The actor patient is the primary role interacting with the HMS in order to carry out all functions related to the patient. This actor will primarily use the system to update her details, check for the availability of doctors, schedule consultations with doctors, and seek follow-up advice. In order to carry out these functions, this actor will have to register herself, and also identify herself every time the system is accessed. This actor can be a private patient or a patient belonging to the public health system (a public patient). This private versus public distinction is made only during the registration process by the patient providing either her private insurance details or her Medicare details.
Actor Relationships
Two different types of concrete actors are derived from this actor:
A20-PublicPatient
A30-PrivatePatient
The actor will interface with the following use case (examples):
UC01-LogsIn
UC10-RegistersPatientDetails
Interface Specifications
UI010-LogIn*
UI020-PatientDetails
I900-GovernmentHealthCareSystem
Author and History
Colleen Berish
Reference Material
Government rules regarding patient registration in the hospital can be found on the government health regulatory system website.
Actor Documentation for “A60-Doctor”
What follows is another example of actor documentation for actor A60-Doctor for the HMS.
Actor Thumbnail
Actor: A60-Doctor
Actor Type and Stereotype
This actor represents the doctors in the HMS.
Actor Description
The actor doctor interacts with the HMS in order to carry out most medical as well as some administrative functions. These functions include checking bookings made by patients, updating diagnoses for patients, writing prescriptions, booking vacations, and providing follow-up advice to patients. The doctor is registered as a staff member and hence requires a valid login and password to access the system. The doctor is further specialized as a surgeon or a physician.
Actor Relationships
This actor inherits from A50-Staff.
This actor is specialized into: A62-Surgeon and A64-Physician.
The actor will interface with the following use cases (as shown in Figure 6.3 in Chapter 6):
UC14-CreatesPatientsMedicalProfile; UC16-UpdatesPatientsMedicalProfile
UC32-ExaminesPatient (as shown in 6.5 Chapter 6).
Interface Specifications
UI10-PatientRegistrationForm; I900-GovernmentHealthCareSystem
Author and History
Colleen Berish
Reference Material
Staff levels for doctors are specified in the “HMS Business Policies” document.
Use Cases
What Is a Use Case?
A use case documents a series of interactions of an actor with a system. This interaction is meant to provide some concrete, measurable results of value to the actor. Use cases describe what a system does, but they do not specify how the system does it. Furthermore, use cases not only document the interactions of the actor-system through a series of steps, they also add details like pre- and postconditions for the use case, user interface references, and alternative flows. A use case is represented by an ellipse in the system, as shown in Figure 5.5.
Figure 5.5Notation for a use case.
Use Case Variations
Use cases, like actors, can be of different types. For example, use cases can be at the business level (as is most common) or they can be at the system level. Use cases can also be abstract or concrete (this variation is discussed in the use-case-to-use-case relationship in Chapter 6).
Finding Use Cases
The initial list of actors is a good starting point for the identification of use cases. Use cases are best discovered in the same workshops in which actors are discovered. Actor documentation also leads to use case discovery. This is because actor documentation provides information on actor-to-use-case relationships. Use cases are sourced as follows:
■Interviews and discussions with users and domain experts in a workshop session
■Play-acting of various scenarios or “stories” told by users in terms of how they would use the system
■Identifying and documenting actors, leading to an understanding of their goals or purpose in using the system
■Revisiting the output of requirements analysis
■Formal and informal problem statements (such as presented in Appendix A)
■Executing existing systems (especially legacy applications), if available
■Investigating existing user documentation, if available
■Investigating existing “help” for the system, if available
■Researching the problem domain, especially on the Internet for relevant analysis models
■Researching and using published literature, such as Analysis Patterns (Fowler)
Use Case Documentation
A tentative list of use cases is created as they are discovered. Use cases are then documented iteratively. Since there is no specific format for use case documentation mandated by the OMG, there are many different formats in practice. Cockburn (2000) suggests the need for two templates: the first a “casual” low-ceremony format, the second a “fully dressed” format for high-ceremony projects. The practical approach is to come up with a use case format that is agreeable to all project members. This then forms the basis for all use case documentation.
Use Case Documentation Template
Use Case Thumbnail:
<This is the number and name of the use case and, optionally, a version number. The numbering may take the form UC10-, UC20-, where UC stands for use case and the numbering provides a common grouping mechanism, similar to the actors.>
Use Case Description:
<This is a short description of the use case. This description ranges from a brief “one liner” to a paragraph describing its purpose and usage. Sometimes, for a small, single-iteration project, this might be the only description of the use case.>
Stereotype and Package:
<Description of the stereotype and the package to which this use case belongs. This is optional information and may not always be documented, although it will be easily entered in a modeling tool.>
Actors:
<A list of the actors involved in this use case is documented here. >
Preconditions:
<Preconditions are the conditions that need to be satisfied before the execution described by the use case can commence.>
Postconditions:
<Postconditions are conditions that must be met at the end of a use case.>
Use Case Relationships:
<Thumbnails of other use cases that are included, extended, or inherited. These three use-case-to-use-case relationships are discussed in Chapter 6.>
Use Case Text (Basic Flow):
1.0 <description of step>
2.0 <description of step> (A1, E1, E2)
3.0 <description of step> (A2, E3)
≪include≫ <Thumbnail of use case(s) included>
≪extends≫ <Thumbnail of use case(s) extended>
Alternative Flow:
<A1—The optional descriptions here are alternative flows under conditions specified in the steps in the basic flow.>
Exceptions:
<E1 The optional descriptions here specify actions taken under “exception” conditions encountered during the basic flow of the use case. Technically, this can represent actions to be taken in case of an error.>
Constraints:
<Here are the documented special constraints or limitations that are relevant to the use case.>
User Interface Specifications:
<Number/s and name/s of UI specifications related to the use case, including Web screen specifications, as and when available. Note that these are not user interface designs but simply references to the likely screens/forms that will be used by the actor in interfacing with the system.>
Metrics (Complexity):
<Anything that needs to be measured that is related to the use cases will be put here—for example, complexity of the use case: simple/medium/complex. This information can be helpful in highly mature organizations, typically CMM level 4 and 5, where artifacts are measured for the purpose of optimization. Complexity may be based on the number of actors, relationships with other use cases, and even technical issues for each use case. However, the actual discussion on metrics is beyond the scope of this book.>
Priority:
<The importance of the functionality described by this use case: high/medium/low. This could be based on analysis and understanding of risks and importance of the use cases.>
Status:
<The state of completeness of the documentation of this use case: initial/major/final. This will indicate the level of maturity of the use case.>
Author & History:
<Original author and modifiers of this use case.>
Reference Material:
<Relevant references, as well as sources from where the use case has been derived. Any large documentation and material that does not form part of the “flow” in a use case (such as mathematical formulas, legal documents, and policy materials).>
Alternatively, a low-ceremony use case format will be a subset of the preceding detailed version and may contain just the following:
Use Case Thumbnail
Actors:
Use Case Description
Example: Use Cases in the Hospital Management System
Based on the templates for use case documentation, a few example use cases from the HMS are now described. A practical project will require substantially more use cases than described here. Also, initially the use cases described are in a low-ceremony format followed by examples of expanded high-ceremony documentation.
Brief Use Case Documentation for HMS
Use Case Thumbnail: UC10-RegistersPatient (Figure 6.3 in Chapter 6)
Actors: A10-Patient, A80-Administrator, A90-GovernmentHealthRegulatorySystem, A95-PrivateInsuranceProvider
Use Case Description
This use case deals with the registration of new patients in the HMS. These registration details include name, address, date of birth, and related details of the patient, his Medicare card and status, such as private or public patient. A10-Patient provides all the details and A80-Administrator enters them in the system. A90-GovernmentHealthRegulatorySystem is an interface to an external system, which is provided by the state department of health, to verify the Medicare card details of public patients. A95-PrivateInsuranceProvider is an interface to an external system for individual private health insurance companies, to verify the insurance details of private patients.
Use Case Thumbnail: UC12-MaintainsPatientDetails (Figure 6.3 in Chapter 6)
Actors: A10-Patient
Use Case Description
This use case describes how A10-Patient maintains selected personal details (such as address, phone, and status) using the system. These details are updated directly by the patient.
Use Case Thumbnail: UC14-CreatesPatientMedicalProfile (Figure 6.3 in Chapter 6)
Actors: A60-Doctor, A10-Patient, A80-Administrator
Use Case Description
This use case describes the creation of a medical profile (record) for a patient. This record is created by A60-Doctor, with input from A10-Patient. This profile contains details such as blood group, past illnesses, blood pressure, and x-ray records. The medical profile is created following the registration process. A80-Administrator helps create and verify the patient’s details and is not required for profile maintenance.
Use Case Thumbnail: UC16-UpdatesPatientMedicalProfile (Figure 6.3 in Chapter 6)
Actors: A60-Doctor, A10-Patient
Use Case Description
This use case describes how the medical profile of a patient is updated. This modification is done by A60-Doctor with input from A10-Patient.
Use Case Thumbnail: UC22-MaintainsCalendar (Figure 6.4 in Chapter 6)
Actors: A50-Staff
Use Case Description
Any staff member of the hospital who has proper login authorization in the system can enter and change his/her calendar details. These calendar details include dates, vacation dates, days, times, and statuses (such as availability and booked for consultations and surgeries). Some cases, such as booking a vacation through the system, will require the authorization of the person’s supervisor.
Use Case Thumbnail: UC30-BooksConsultation (Figure 6.5 in Chapter 6)
Actors: A10-Patient
Use Case Description
This use case describes the process by which A10-Patient is able to book a consultation with a doctor. This process requires that A10-Patient search for information on availabilities of doctors, relevant for particular ailments, on a particular day and time. The system provides alternatives, and the patient selects from those alternatives.
Use Case Thumbnail: UC36-ManagesConsultationSchedule (Figure 6.5 in Chapter 6)
Actors: A60-Doctor
Use Case Description
This use case describes how a doctor can view and change her consultation schedule. This management and updating of the consultation schedule by the doctors enable all other actors in the system to be aware of the availability of the doctor. The doctor can add, cancel, or modify scheduled procedures as necessary.∗
Use Case Thumbnail: UC50-PaysBill (Figure 6.6 in Chapter 6)
Actors: A10-Patient
Use Case Description
This use case describes the process by which patients pay their medical bills. The basic procedure required to pay a bill is described here. This includes verification of the bill, corresponding procedure performed in the hospital, and the patient details. However, the actual method of payment is shown separately by other use cases that extend this use case.
Use Case Thumbnail: UC56-PaysBillOnInternet ≪extends≫ U50-PaysBill (Figure 6.6 in Chapter 6)
Actors: A10-Patient
Use Case Description
This use case extends use case UC50-PaysBill in that it describes the process of paying a bill online. Internet bill payment will require the patient to identify herself on the Internet, identify the bill that needs to be paid, and pay the bill using the Internet bill payment features such as “BPAY” (bill pay).
Use Case Thumbnail: UC57-CashChequePayment ≪extends≫ U50-PaysBill
Actors: A10-Patient, A00-Printer
Use Case Description
This use case extends use case UC50-PaysBill in that it describes the process of paying a bill by cash or cheque. This payment is expected to be across the counter at the hospital, although checks can also be posted by patients. A00-Printer will be used to print and post the receipts.
The following three use cases are additionally provided although they have not yet been modeled, i.e., they do not appear in any of the use case diagrams shown in Chapter 6. This practice is often encountered in the initial iterations because use case documentation leads to improvements in use case diagrams.
Use Case Thumbnail: UC52-IssuesBill
Actors: A50-Staff
Use Case Description
This use case describes the process of issuing a bill (or invoice) for hospital services. This bill is either posted to the patient or electronically sent to the patient or his health insurance company.
Use Case Thumbnail: UC62-ReordersMedicines
Actors: A75-LabAssistant, A50-Staff
Use Case Description
This use case describes the process for reordering medicines (drugs) in the laboratories and in the pharmaceutical section of the hospital. The actual ordering will require an authorized A50-Staff member together with help from A75-LabAssistant.
Use Case Thumbnail: UC60-ChecksInventory
Actors: A75-LabAssistant
Use Case Description
This use case describes the process for A75-LabAssistant to check the hospital’s inventory of drugs. The lab assistant obtains the inventory level from the system and can then check the physical inventory to verify that the system is up to date. If the system’s inventory does not match the physical inventory, then the lab assistant can adjust the system’s inventory amount (with appropriate authorization).”
