Software Design Specifications with UML

Activity Diagrams Part 2

Combined Activity

We are not producing an activity diagram for each scenario seperately as we did that already with our use cases, but one complete activity diagram for the entire system. Now our task is to try to combine the seperate activity diagrams into a whole system activity diagram. To combine Carol's two possible activities, we simply identify that after she is presented with a menu option, we must determine which selection she choose.

To provide for two menu options we use the decision node. The decision is rather cumbersome when it comes to menus. The nice part of diagrams is that you'll start to recognize patterns. The menu pattern is one that when you need to use it you will apply it as a template without having to try to figure out how to express such things each time. There is no difference between which action is picked as the first or second activity.

FIGURE 1. Combined Student Activities

We next want to combine into our larger activity diagram the activities from the TA, Instructor, or Administrator.

The goals available to Carol were limited to A2 and F1. It is the case that if we look back, A2 and F1 were not available to anyone else. When we move on to Joan, our prototypical teaching assistant, that her goals are I1, J1, and K1. These are all goals that Aaron, our prototypical instructor, and Kathy, our prototypical administrator, have. For that, we should convert I1, J1, and K1 into subactivities so that we can reuse them. It isn't necessary, but it sure is convenient.

FIGURE 2. Assign Scores Subactivity

FIGURE 3. Change Score Subactivity

FIGURE 4. View Class Scores Subactivity

The next step is to combine the activities together into one activity for the teaching assistant. Knowing that we will probably have to make use of our teaching assistant activities, we can make it as a subactivity itself. Sure we didn't do that with the student activities yet, but we can get back to that one later when we need to use it.

FIGURE 5. Teaching Assistant Subactivity

The instructor, Aaron, goals included those of the Joan, our teaching assistant. Specifically I1, J1, and K1 overlap between Aaron and Joan. The other two goals, M1 and N1, will overlap with Kathy, our administrator. We can make M1 and N1 into subactivities.

FIGURE 6. Assign Grade Subactivity

FIGURE 7. Change Grade Subactivity

This allows us to create a subactivity for Aaron, our prototypical instructor.

FIGURE 8. Instructor Subactivity

Did you notice something about the combined activities of the teaching assistant and the combined activities of the instructor? They are very similar. Actually the teaching assistant seems to be able to do a complete subset of what the instructor can do. In the beginning it seemed as if there was a strong relationship between a student and a teaching assistant, but from a functional point of view, there is no relationship between the student and teaching assistant, but the strong relationship is between the teaching assistant and instructor. The advantage to a bottom-up approach is that relationship appear out of the act of putting everything together and is not made because we force it into our design.

The only one left is Kathy, our prototypical administrator. She has one goal, G2, that is special to only her. We could create a subactivity out of it just to remain consistant, but it isn't necessary.

FIGURE 9. Administrator Subactivity

One other thing we need to do now is to convert our student activities into a subactivity.

FIGURE 10. Student Subactivity

The Big Picture of Activity

While the display of a login prompt and logging in by the actor showed up in each scenario, we actually knew that the login was really exactly the same for each scenario. That is not always the case. The next thing that shows up in all of the scenarios is that a menu of options is presented. We used the exact same words in each of our scenarios "System presents a menu of options", but they are not the exact same activities. Is the menu presented to Carol, our student, the same one that will be presented to Aaron, our instructor?

There are many ways to do this. I will only present two alternatives, but there can be many more. The first is that depending on who you are (student, teaching assistant, instructor, or administrator) you will be presented with a customized menu of choices to select. The second alternative is that everyone receives the same menu but if you select something you are not authorized to do (e.g. a student selecting "change grade") you will be given an error message and are returned to the menu.

Since we are still looking at the system from the outside, we should still interface to our client to find out which option to select. Depending on how computer savvy your client is you may want to create a design for both situations so that he/she can make an informed decision.

For us, we will pursue only one of the alternatives, specifically the first alternative where each actor gets a specialized menu with only his/her specific menu selections. After login, depending on the person logging in, a different menu will be presented.

We have gone over who all the actors are and the roles they all play already. We discussed at length how to distinguish a student from a teaching assistant since every teaching assistant is also a student. When we talked about the actors we specified that we could make a teaching assistant to be a specialization of student. That would have meant that a teaching assistant should be able to do everything a student could do as well as all the extra things that a teaching assistant can do. When laying out the actors we said that Joan would have to explicitly state which role she would take when using our system. Joan would have to have one login when she is a student and another login when she is a teaching assistant.

Right now is the time that decision will impact us. If Joan were able to be both a student and a teaching assistant at the same time then all of the options available to both student and teaching assistant would be available on the teaching assistant menu screen. However, since Joan is only logging in as a teaching assistant and not as a student, only the teaching assistant options will be available.

Our client may like this separation of roles or our client may view it as cumbersome. After all, the decision to split the roles came at a time when it wasn't clear what the implication would be. If our client now believes it is cumbersome, we should adjust our use cases accordingly. This may seem as if we wasted time, but it is much better to uncover issues during design than in the middle of the implementation.

FIGURE 11. Sign-on Decision Based Menus

Multiple Access

As a distributed web application, we know that people can be logged in as a student at the same time someone is also logged in as an instructor. For each person that is logged in, he/she is presented with his/her own menu based on who they are. Because of the parallel activities that can happen in our system, we will use the fork to show that multiple activities are happening simultaneously.