1. ASU Course Registration System System Analysis Communication Diagram Use Case: Select Courses to Teach

2. ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH (CREATE A SCHEDULE)
We create the communication diagram by considering the flow of events for the Create a schedule scenario of the Select courses to teach use case while keeping in mind the best practices for representing interactions.
The use case is started by the professor selecting the option Select courses to teach through the ProfessorUI role (Line 1 of the Select courses to teach use case).
The ProfessorUI role (Message 1) then displays the interface for selecting courses (Message 2) (Line 2 Select courses to teach use case).
After the professor enters the semester and year (Message 3) (Line 3 Select courses to teach use case), the course information for selection needs to be retrieved (Message 4).
However, before retrieving the course information, we first need to check if the deadline for making changes for the current semester has passed (Line 1 of the Create a schedule subflow).

3. ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH (CREATE A SCHEDULE)
The question now arises, where do we check the semester deadline information? According to the current design of the domain model (see System Requirements Capture notes), the semester information is kept in the CourseOffering class. Therefore, we need to check an object of this class for the current semester.
However, at this point we realize that it is probably not appropriate to keep this information in the CourseOffering class since this means that every CourseOffering object instance will need to hold this information, which
introduces a lot of data redundancy!
Accordingly, we identify a new class, Semester, into which we place the semester information including the deadline information. (Note that this will cause an update to the domain model for the ASU System as shown on the following slide.)

4. ASU: DOMAIN MODEL (REVIISION 1)

5. ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH (CREATE A SCHEDULE)
Having made the deadline check (Message 4.1), we now retrieve the course
information (Messages 4.2, 4.3 and 4.4) and display it to the professor
(Message 5) (Line 2 of the Create a schedule subflow). In the process, we
have identified another new class that is needed, Section, since a course
offering can have several sections and it is a section that is the unit for teaching assignments. (This also will cause an update to the domain model.)
The professor makes his selection (Message 6) and confirms it (Message 7)
(Lines 3 and 4 of the Create a schedule subflow).
The system creates the teaching schedule (Message 8), which requires that the objects playing both Section (Message 8.1) and Professor (Message 8.2) rolesbe updated since the relationship is bi-directional in the domain model (i.e., a Section object needs to have a reference to the Professor object and a Professor object needs to have a reference to the Section object(s)) (Line 5 of the Create a schedule subflow).
Finally, the status of the request is displayed to the professor (Message 9) (Line6 of the Create a schedule subflow) and the use case ends.

6. ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH (CREATE A SCHEDULE)

7. ASU: DOMAIN MODEL (REVIISION 2)

8. ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH (CREATE A SCHEDULE)
Further analysis
The preceding communication diagram is incorrect in at least one aspect.
If we consider the (revised) domain model class diagram, we notice that the course offerings are semester specific, that is, they can be related to only one semester.
Thus, before actually retrieving the course information from the objects playing the CourseOffering, Course and Section roles, we first have to establish which are the course offerings for the current semester.
From the revised domain model class diagram, we see that a Semester object knows about the CourseOffering objects to which it is related.
Thus, we need to add one more interaction to the communication diagram (Message 4.2: Get semester offerings) before actually retrieving the course information.
Consequently, we obtain the following revised communication diagram.
Note that this communication diagram is still not completely correct, but we will fix it later.

9. ASU COMMUNICATION DIAGRAM: SELECT COURSES TO TEACH (CREATE A SCHEDULE)

10. ASU FLOW OF ANALYSIS: SELECT COURSES TO TEACH
Scenario of creating a teaching schedule in a given semester
1. The Professor role asks the ProfessorUI role to let the professor maintain his teaching schedule (1).
2. Since the default mode is “Create”, the ProfessorUI role displays the schedule creation form for the professor to select courses to teach (2).
3. The professor specifies the semester and year for which the teaching schedule is to be maintained through the ProfessorUI role (3).
4. The ProfessorUI role asks the SelectCoursesToTeachMgr role to retrieve the available teaching section choices for the professor to choose (4).
5. After checking that the deadline for modification has not passed (4.1), the SelectCoursesToTeachMgr role gets the available teaching section choices from the Semester, Course, CourseOffering and Section roles (4.2, 4.3, 4.4, 4.5).
6. The ProfessorUI role displays the available offering sections (5).
7. The professor selects sections of courses to teach through the ProfessorUI role(6).
8. The professor confirms the schedule through the ProfessorUI role (7).
9. The ProfessorUI role informs the SelectCoursesToTeachMgr role to make corresponding updates (8) on the Section and Professor roles (8.1, 8.2).
10. The ProfessorUI role informs the professor of the status of his request (9).