FIGURE 1. Actor Representation

Actors do not have to be limited to human beings. Actors are anyone or anything that externally causes an impact on the system. The actor is the one that initiates the action. One word of caution you shouldn't confuse a tool for an actor. Using the internet, a person uses a browser to interface to a server. The person is the actor, not the browser. You may think this is obvious, but think about a back-up system that nightly archives the work you've done and copied it to an off-site storage facility. What initiates the action? Is it the back-up system itself that interacts with my computer to back up the data? Or is there a human operator that instructs the back-up system to work? The software design process is not going to answer those questions for you but will lead you to asking those questions.

In the gradebook problem, there are three human actors: the student, a teaching assistant, and an instructor. That sounds easy. But there are hidden implications that are lurking.

As we will continue to take a bottom-up approach to our design system, I am going to say we need to identify the real people behind the roles of student, teaching assistant, and instructor.

Let's start with Horatio. Horatio is a undergraduate junior in the computer science department. He is taking the following courses:
English 202, Introduction to Poetry
CompSci 445, Information Systems
CompSci 1520, Programming Languages
CompSci 1541, Introduction to Operating Systems

Horatio will be our prototypical full-time undergraduate student.

What other kinds of students are there at the university. There are graduate students, part-time students, a few people who are casual students only taking one or two classes and are not enrolled in a degree program. Anyone else? The first thing you will begin to notice is that we are going to have to come up with answers that did not show up in the problem statement. The problem statement only mentions students and what a student is able to do.

Our list of prototypical students:
Horatio, full-time undergraduate student
Joan, full-time graduate student
Tom, part-time undergraduate student
Freda, part-time graduate student
Don, a casual student

I worked with many non-technical clients in the past. They are really good at their domain but are not detail oriented (anal retentive) enough to be able to specify enough information that allows us to create a good piece of software.

The other reason we do a bottom-up approach is that we are also at the same time as we are coming up with names and details about our prototypical actors, we are constructing test data. For instance, we could have added a few more courses to Horatio and our client may inform us that a full-time undergraduate student can only take a maximum of ten classes. Most of the information we come up with at the bottom level may not be used, but it gives our software some life. We are, after all, constructing something real.

FIGURE 2. Horatio Representation

Moving on to the other prototypical students, we wil then have a graduate student. Her name is Joan. She is a graduate student in computer engineering. The courses she is taking:
CompEng 1600, Architecture
CompEng 1754, Blah
CompEng 9000, Thesis

And here we may start to discover our first issue. Is Joan also a teaching assistant? Can Joan also be a teaching assistant?

Now you can see why we start at the bottom and create actual instances for everything. It is very easy to look at the problem statement and pull out the actors that are obvious. But there are implications to the problem that are often not expressed easily in a problem statement.

Now what do we do? Go talk to the client. Can a student also be a teaching assistant?

Your client could tell you that every teaching assistant is a student but not all students are teaching assistants. A teaching assistant may be a specialization of a student. The person can do everything he/she can do as a student and also everything he/she can do as a teaching assistant. The role of the teaching assistant is therefore an extension of being a student.

FIGURE 3. Teaching Assistant as Student Specialization

Or your client may say that a student and a teaching assistant for the purposes of this software are different. When a person uses the system he/she may sit down and access it as a student and then in a very different engagement, sit down and access the system as a teaching assistant. So when a person who could be both a student and a teaching assistant sits down he/she has to explicitly state what role he/she is taking.

FIGURE 4. No Specialization Between Student and Teaching Assistant

We cannot just arbitrarily pick one. We need to be able to take the issue back to the client for a decision to be made. Most likely the client will ask about the implications for option 1 vs option 2. How will it effect the software product? The most obvious implication is that the person sitting down will either have to explicitly state how they are engaging the system or the system itself will have to adjust itself for students who are and students who are not teaching assistants.

We need to identify the students that are teaching assistants and those that are not. In our college, only full-time graduate students may be teaching assistants. This is not always the case so we checked with our client to know. We already have Joan who is not only a full-time graduate student, but she is also a teaching assistant. We only need to add one more person, Carol, to be our prototypical full-time graduate student that is not a teaching assistant. Now our list of students include: Horatio, Joan, Don, Freda, Tom, and Carol.

FIGURE 5. List of All Students

Through this book we will see that we want to eliminate unimportant information from our design. We want to eliminate it but not from the start. To start we want to "freewrite" all of the possible prototypical actors in the system and then finall pare it down to only the most useful ones. Freewriting is a writing technique where you just write everything down as it comes to you and you never edit it until the end. If we started off at the beginning saying that characteristics such as undergraduate vs. graduate student is not a useful characteristics, we may never have noticed that a teaching assistant may be a specialization of a student.

Remember it is the process that we go through in the design of the system that is just as important as the end result. The process helps us to uncover the issues that we didn't realize just from reading the problem statement.

Next let's look at the last category we identified for students and that is full-time vs. part-time vs. casual (no degree program) students. What is the difference between full-time and part-time? There may be an attribute associated with it that will limit the number of courses each type of student may take. And with a casual student, he/she may only be able to take classes for a maximum of so many semesters.

We are not designing a full registration system, only a gradebook program. Our system will not restrict or allow students taking classes. We will keep track of their grades in the classes they do take. We would also not keep track of who could be a teaching assistant or not so we have no use for the full-time student status. All we need is Joan and Carol -- a student that is also a teaching assistant and a student that is not. We can eliminate Horatio, Don, Freda, and Tom.

We have already looked a little bit at the teaching assistant. Are there any other characteristics? A TA can be in charge of a lab, a recitation, a lecture, or he/she may just grade assignments. We'll continue to use our current teaching assistant Joan and make her in charge of a lab session. We will add a few other teaching assistants:
Pedro is in charge of a recitation.
Phil is in charge of a recitation.
Deepti is in charge of a lecture.
Priya grades assignments.

FIGURE 6. All Teaching Assistants

Again, it is important to dialog with your client to determine if the differences in classes would fundamentally change how the teaching assistant would grade assignments.

Your client may point out that they all do grading and enter grades for students based on the type of class they are assigned to. A grader using the gradebook system wouldn't do more or less than a teaching assistant in charge of a recitation section. Since there is no difference between them, we won't need them and will stick to just Joan as our prototypical teaching assistant.

The last type of human actor we have identified has been the instructor. There are many different kinds of instructors at the college including a lecturer, assistant professor, associate professor, and full professor. These are all titles and are really all the same. We will still need a prototypical instructor, so we will use Aaron, an associate professor in the computer science department.

FIGURE 7. Prototypical Instructor

The one thing that is often brought up when the subject of the instructor actor is considered is how many instructors do we allow? Is this a single gradebook that only one instructor will permit to be used by his/her class? Is this one that is used by a single department with many instructors, or is it a college-wide system.

The implication is how does data get into the system. If it is a single instructor, there is a good chance that the instructor is the one person who enters all student information including name and password. If it is a college system, then the data is mixed with the registration system. If it is a department system, then the data is retrieved from the registration system but the grade data resides seperately.

The problem statement says that it is an instructor, which implies that this is a system that will be deployed by a single instructor. When in doubt check with the client. In this case, while a single instructor was implied, it should be available to many instructors but will not be a college-wide system. In that case we know that the instructor does not have to also administer the system as he/she would do if it was a single instructor system. But if the single instructor doesn't then who does? Does anyone? Are all instructors able to modify data from other instructor's classes? That might sound silly but when a problem arises who do you turn to for help?

At this point I am sure you are tired of my typical answer of ask the client. But that is what you should do. It may not be the client exactly but a client representative who interacts with the client to understand the parameters of the system to be designed. Many times the client hadn't thought about all the implications of choices and how it will effect the system.

We have basically three choices. Let all instructors modify any class data. Provide for a new actor, the administrator. Designate the administrator as a teaching assistant for every class.

The last solution, an administrative teaching assistant, is the easiest way to shove an administrator into an already designed system. Many times that is what we do if after we have spent a considerable amount of effort in designing the system and do not want to go back and fix the design to account for something we hadn't thought of. If we are going to import the data from the registration system then we will also have to "fix it up" before using it because it does not provide for an adminstrative teaching assistant. This approach certainly sounds like a hack solution that is best avoided.

The first solution, all instructors access all data, is another way to allow for others to help administer the system. It seems like a reasonable approach. After talking to the client this turns out to be not an option.

Our last option is to add an additional administrator to our list of actors. The original problem statement didn't even mention an administrator. Just as we did with the other actors, we need to determine the kinds of administrators we will have. Our administrator will have full control to the entire system. Is there another kind of administrator that has limited access? Probably not. So Kathy will be our only administrator.

The human actors are:
Carol, a student
Joan, teaching assistant
Aaron, an instructor
Kathy, an administrator

FIGURE 8. All Human Actors

Once we have finished with the human actors, we need to identify the non-human actors that interact with our system. Remember to be sure not to mix up a tool used by a human actor as a non-human actor. A web browser isn't a non-human actor but is instead just a tool used by a human.

A backup system is a common non-human actor. In our system the database that contains our grade information is not one we explicitly backup but is backed up without our knowledge. This isn't always the case. Asking the client, the gradebook system would be shut down nightly in order for a good backup to be made. If our system is turned off when the backup system runs then we certainly do not interact with it and will not include it as a non-human actor in our design.

When discussing the difference between a full-time, part-time, and casual student we made the following statement: We are not designing a full registration system, only a gradebook program. Our system will not restrict or allow students taking classes. Even though we are not building a full registration system, we still need to know what classes are being offered, who is teaching them, and who is taking them. Are we building a small registration system such that our administrator or each instructor would provide that information into the gradebook, or are we able to access the actual registration system to get that information.

The client has the ability to interface to the registration system to retrieve the information to be used in our gradebook system. The registration system would be our only non-human actor, which we will call the ACME5000. Even non-human actors are represented with the same stick-figure person symbol.

FIGURE 9. All Actors

What the client told us after the problem statement:
A full-time graduate student can be a teaching assistant.
The type of course a teaching assistant is assigned to is not important.
The gradebook program is available per department.
There should be a seperate individual that is the administrator.
The gradebook program will interface to the registration system.

This information was not available in the problem statement and it probably was not anything that the client thought about when asking us to design the system. Remember, a big part of the software design process is being able to come up with the issues that have to be addressed early rather than after the project has been completed and is wrong.