9.2. Actors
Actors represent anybody or anything that will interact with the system after it's built; actors' needs are the basis for use cases. Actors generally fall into two broad categories:
Human users
Other computer systems
When actors interact with the system, they generally want to achieve some result, but actors can also simply provide/contribute information to the system and/or receive/consume information from the system.
By providing information, we mean whether or not the actor inputs substantive information that adds to the residual data stored by the system; for example, a department chairperson defining a new course offering or a student registering his or her plan of study. This doesn't include the relatively trivial information that users have to provide to look things up; for example, typing in a student ID to request their transcript.
By consuming information, we mean whether or not the actor uses the system to obtain information; for example, a faculty user printing out a student roster for a course that he or she will be teaching, or a student viewing his or her course schedule online.
9.2.1. Identifying Actors and Determining Their Roles
We must create an actor for every different role that will be assumed by various categories of user relative to the system. To identify such roles, we typically turn first to the narrative requirements specification, if one exists, which is a statement of the functional requirements, such as the SRS specification. The only category of user explicitly mentioned by that specification is a student user. So, we would definitely consider a student to be one of the actor types for the SRS.
If we think beyond the specification, however, it isn't difficult to come up with other potential categories of user who might also benefit from using the SRS:
Faculty might want to get a head count of how many students are registered for one of the upcoming classes that they will be teaching or might use the system to post final grades, which in turn are reflected by a student's transcript.
Department chairs might want to see how popular various courses are or conversely, whether or not a course ought to be cancelled due to lack of interest on the part of the student body.
Personnel in the Registrar's Office might want to use the SRS to verify that a particular student is projected to have met the requirements to graduate in a given semester.
Alumni might want to use the SRS to request copies of their transcripts.
Prospective students—those who are thinking about applying for admission but who haven't yet done so—might want to browse the courses that are going to be offered in an upcoming semester to help them determine whether or not the university has a curriculum that meets their interests.
Similarly, because we said that other computer systems can be actors, we might have to build interfaces between the SRS and other existing automated systems at the university, such as the following:
The Billing System, so that students can be billed accurately based on their current course load
The Classroom Scheduling System, to ensure that classes to be taught are assigned to rooms of adequate capacity based on the student head count
The Admissions System, so that the SRS can be notified when a new student has been admitted and is eligible to register for courses
Of course, we have to make a decision early on as to what the scope of the system we're going to build should be, to avoid "requirements inflation" or "mission creep." To try and accommodate all the actors hypothesized earlier would result in a massive undertaking that might simply be too costly for the sponsors of the system. For example, does it make sense to provide for potential students to use the SRS to preview what the university offers in the way of courses, or is there a different system—say, an online course catalog of some sort—that is better suited to this purpose? Through in-depth interviews with representatives of all the intended user groups, the scope of the system can be appropriately bounded, and some of the actors that we conceived of might be eliminated as a result.
In our particular case, we'll assume that the sponsors of the SRS have decided that we needn't accommodate the needs of alumni or prospective students in building the system; that is, that we needn't recognize alumni or prospective students as actors. A key point here is that the sponsors decide such things, not the programmers! One responsibility of a software engineer is indeed to identify requirements, and certainly part of that responsibility might include suggesting functional enhancements that the software engineer feels will be of benefit to the user. But, the sponsors of the system rightfully have the final say in what actually gets built.
|
Note that the same user might interact with the system on different occasions in different roles. That is, a professor who chairs a department might assume the role of a Department Chair actor when he or she is trying to determine whether a course should be cancelled. Alternatively, the same professor might assume the role of a Faculty user when he or she wants to query the SRS for the student head count for a particular course that he or she is teaching.
9.2.2. Diagramming a System and Its Actors
After we settle on the actors for our system, we might want to diagram them. Unified Modeling Language (UML) notation calls for representing all actors—whether a human user or a computer system—as stick figures and then connecting them via straight lines to a rectangle representing the system, as shown in Figure 9-2.
Figure 9.2. A "proper" UML use case diagram
This figure appears rather simplistic, yet it is a legitimate diagram that might be produced for a project such as the SRS development effort.
We prefer to use a slightly modified version of the UML notation, as follows:
We'll use rectangles to represent not only the core system but also all actors that are external systems instead of representing the latter as human stick figures.
We find that using arrowheads to reflect a directional flow of information—whether an actor provides or consumes information—is a bit more communicative. For example, in our amended version of the notation we represent a Student as both providing and consuming information, whereas a Registrar only consumes information.
NOTE
The Registrar does indeed provide information, but not to the SRS directly. He or she provides information to the Admissions System about which Students are registered at the university; this information then gets fed into the SRS by the Admissions System. So the Admissions System is shown as providing information as an actor to the SRS, but from the standpoint of the SRS, the Registrar is but a consumer.
With these slight changes in notation, as reflected in Figure 9-3, the UML diagram becomes a more communicative instrument.
Figure 9.3. Our customized version of use case notation
Of course, if you do decide to deviate from a widely understood notational standard such as UML, you need to follow these steps:
Reach consensus among your fellow software developers, to ensure that the team as a whole is speaking the same language.
Document and communicate such deviations (along with the notation as a whole) to your customers/users, so that they, too, understand your particular "dialect."
Make sure that such documentation is incorporated into the full documentation set for the project, so that future reviewers of the documentation will immediately understand your notational "embellishments."
If you make these enhancements intuitive enough, however, they might just speak for themselves! Of course, as we pointed out in Chapter 8, you'll also need to consider whether the Computer-Aided Software Engineering (CASE) tool you're using, if any, will support such alterations.
Time and again throughout Part Two of this book, we'll remind you that it's perfectly acceptable to adapt or extend any process, notation, or tool that you care to adopt to best suit your company's or project's purposes; none of these methodology components is sacred.