Document Engineering and Information Architecture (INFO 243)

Assignment 5: Modeling Processes

Author(s):
Bob Glushko
glushko@ischool.berkeley.edu

Course: Document Engineering and Information Architecture (INFO 243)
Date: 19 March 2007
Title: Assignment 5: Modeling Processes
This assignment gives you practice at using DSM, the ebXML process metamodels, and the RosettaNet PIPs for analyzing and improving models of processes.

This asssignment is due by midnight on Friday 30 March. Turn in your work (with your name in both the filename and in the content) by uploading a file on the course syllabus page.

The process of registering for courses each semester is familiar to all of you (except perhaps for Roy) and so I might have asked you to create a model that describes it. But the assignment can be made more interesting and enable you to learn from each other if I describe the registration process in an informal narrative form the way you might learn about it if you interviewed me, and then have you formalize it rather than have you each start from the possibly idiosyncratic details of your own experience. Some of what I'll provide here are essential "true facts" that accurately describe the registration process. Other process "facts" here might not always be true, but are plausible and invented to give you more to think about for this assignment (for example, I've ignored the strange processes that stagger the start times for students wanting to register). Try to work with what I'm presenting here so that your models all start from the same context.

There are four actors in the scenario I will describe:

STUDENTS, who can be assumed to be admitted to the UNIVERSITY and enrolled in some SCHOOL, so they have the necessary credentials or authorization to participate in the registration process

The University registrar, facilities, accounting, and other administrative functions, which can be treated as a single actor called the UNIVERSITY

The SCHOOL, which defines degree requirements and determines schedule of courses offered each semester

INSTRUCTORS (professors and other academic employees) who decide which courses to teach each semester and who actually teach them.

THE REGISTRATION PROCESS

The SCHOOL specifies degree requirements, which we will assume are fairly static and are limited to some number of required courses and some total number of required units. The SCHOOL publishes a course catalog that lists the set of required and allowable elective courses, but some courses have pre-requisite courses and not every course is offered each semester. Each INSTRUCTOR decides what courses to teach in a given semester, often with some guidance or suggestions from the SCHOOL, and the schedule of classes – the subset of the catalog courses that will actually be taught -- thereby emerges from negotiations between the SCHOOL and its INSTRUCTORS. Often for a new course, or for a course that hasn’t been taught in a while, the SCHOOL negotiates with the UNIVERSITY to find a classroom large enough to handle the expected enrollment, and classroom availability can lead to changes in when courses are scheduled. At some point the SCHOOL submits a final schedule of classes to the UNIVERSITY so that the latter can load this information into the registration system.

STUDENTS study the course catalog to learn about courses and especially to select from the electives which courses they would like to take. They also study the final schedule of classes to learn whether the courses they want are being offered so they can design one or more possible ses of classes in which to try to enroll. But before they try to enroll, they should consult the degree requirements and make sure they’ve taken any pre-requisite courses or they might be trying to enroll in courses that aren’t right for their situation. Sometimes a STUDENT will ask an INSTRUCTOR to waive a course pre-requisite, and sometimes the INSTRUCTOR will allow this and give the STUDENT permission to register in the INSTRUCTOR’s course.

STUDENTS then sign into the the registration system operated by the UNIVERSITY to attempt to enroll in their chosen courses. Unfortunately, sometimes the courses selected by the STUDENT are already full, and the STUDENT needs to select alternative courses or ask the INSTRUCTOR to admit him. And sometimes a student is able to enroll in a course, but the course is subsequently cancelled because of low enrollment. And sometimes a STUDENT discovers that his work schedule for his part-time job conflicts with courses he wants to enroll in, or already has enrolled in, and this causes problems.

Analyze my narrative description of the overall Registration process and make a list of the activities/tasks/steps implied in it in the order that the narrative introduces them. Give each of these an identifier and a short description of a few words.

Create a DSM "Before" matrix whose rows and colums are headed by the identifiers from Part 1, and whose cells indicate the presence and direction of information flow between the activities. Analyze the patterns of information flows and rearrange the rows if you can to create a DSM "After" matrix that eliminates any feedback from later to earlier activities that isn't absolutely essential and unavoidable. Put a box around any set of activities where the feedback and iteration is desirable and planned so that the set should be treated as a higher-order construct.

For each row that you rearrange, write a one-sentence explanation/justification. For each planned iteration, write a one-sentence explanation/justification.

After you have "rationalized" the narrative description of the process, you can model the interactions among the actors as transactions. There is unlikely to be a 1-1 mapping of the activities you identified in Parts 1 and 2 to transactions. One goal of this assignment is to have you realize that you must make some choices about how many transactions to define from a process description. If you have fewer than 8 transactions you have too few and if you have more than 25 you have too many.

You should organize sets of related transactions that have "meaningful and necessary overlap with each other" as collaborations. As with modeling the transactions, part of the assignment is for you to determine the number of collaborations, but you need at least two or there isn't any point, and if you have too many there isn't sufficient abstraction between the transaction level and the highest level where we simply call this process "Registration."

Create a sequence diagram like that in Figure 9-14 in the Document Engineering book that shows the transactions and collaborations in your process model.

Complete a worksheet for at least TWO collaborations in your model (see Figure 9-4c in DE book). The worksheet notes do not need to be any more extensive than those in Figure 9-4c. Your goal is not to describe every possibly relevant fact or context, only to clarify the scope and purpose of your model.

Complete a worksheet for ONE of the transactions that involves STUDENTS and SCHOOL in your model (see Figure 9-6b in DE book).

For each transaction in your model, identify its transaction pattern (Section 9.6 of the DE text). Annotate your sequence diagram from Activity 3 with the transaction patterns.

For at least FOUR of the transactions in your model, identify RosettaNet PIPs that could serve as reference models. In some cases you can find a PIP that fits the transaction semantics very well, and in other cases the fit will be less exact. Annotate your sequence diagram from Activity 3 with the selected PIPs.

Tell me what you think of this assignment. What new skills or insights did it provide about modeling processes... or if it didn't do that, how can this assignment be changed so that it would do a better job of that?