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: 7 April 2008
Title: Assignment 5: Modeling Processes
This group assignment gives you practice at analyzing processes and creating modeling artifacts like sequence diagrams, blueprints, and process worksheets.

This asssignment is due Tuesday April 15, and you'll be presenting it on Tuesday afternoon as your first progress report for your course project. By the end of the day on Tuesday turn in your work by email to the instructor and the TA.

We'll begin with an overview and then follow with specific instructions. You will probably need to iterate through the activities rather than perform them in the order they're listed here (that's the value of the modeling worksheets because they help you document your model as you figure it out).

You should analyze the domain of your course project and identify the important actors in it. These actors can be human actors or computational ones (i.e., services or information resources used by other actors). You should have at least four actors, and you might have more than that.

You should model the interactions among the actors as transactions and one goal of this assignment is to make you realize that you have choices about how the granularity of the transactions to define. However, you should probably have at least 8 transactions among the 4 actors and if you have more than 20 you might be modeling with too much detail at this point.

You should organize sets of related transactions into collaborations when they have "meaningful and necessary overlap with each other" (see section 9.7 in Document Engineering). As with modeling transactions, part of the assignment is for you to determine how many collaborations to represent in your model. But you need at least two or there isn't any point, and if you have nearly as many collaborations as transactions then the collaboration level isn't providing an additional abstraction level.

What your model means is represented in your specifications for each transaction, and you will define these using transaction worksheets like those in section 9.4 of Document Engineering.

Write a paragraph or two that explains the purpose and scope of your process model. You may have already figured this out when you wrote your project proposal, but if you've changed your project in any significant way, you need to explain it here.

Create a diagram that depicts the relationships between the actors that are stated or implied in the previous section. You can use either an activity diagram (see Figure 9-15), a sequence diagram (Figure 9-6a or 9-14), a service blueprint (Bitner et al paper), or any other notation that lets you represent the sequence and interdependencies of the transactions in your model. (So you need to label both the transactions and the collaborations in your diagram). The blueprint examples you've seen didn't show collaborations, so you'll need to invent some notation for representing them if you choose to use blueprints.

You can use a UML tool or even Visio, SmartDraw, Powerpoint, or any other tool you like because it's the model that matters, not the notation (but any tool that understands process modeling notations will make it go a lot faster).

Your model should include exception or failure states where the transactions do not achieve the desired outcome(s). These are easier to depict in the traditional Activity Diagram but can be represented as annotations on Sequence Diagrams or Blueprints.

For each transaction in your model, identify its transaction pattern (section 9.6) and annotate your diagram from Activity 2 with this information.

Identify as many Rosettanet PIPs as possible that can be used as patterns for the transactions in your model. In many cases PIPs exist that fit the transaction semantics very well, and in other cases the fit will be less exact. Annotate your diagram with the PIPs.

Create Transaction Worksheets (Figure 9-6b) for at least three of the transaction in your model from at least two different collaborations. You don't need to turn in worksheets for every transaction in your model because that would encourage you to create models with a minimal number of transactions.