Due Date and Electronic Hand-In

The assignment is due by 10:30am on Monday, March 16. Your solution should be placed in a directory named ``a3'' in your team's class directory. Contents of this directory should include:

• a text file "RegistrationSystem.doc" indicating the names of your team members and the changes made to the original system.
• modified source to changed modules (following the above restrictions), source for any new modules, and a running system.

In addition, there will be a written commentary (due at the beginning of class on March 16) answering the following questions:

1.

Problem Frame: What problem frame(s) does this problem fit? Does it differ from the problem frame(s) of the Pipe and Filter Registration System and Object-Oriented Registration System? Why? Draw the frame(s). Briefly describe (designate) the domains in your frames. Note that your answer should contain enough information so that the reader will not have to refer to any other assignment write ups.

2.

Architectural Description: Describe the architecture of the modified system (both the provided parts and the parts you added), explaining how it is an example of an implicit invocation architecture. (Be sure to use architectural concepts and vocabulary, and provide a diagram for your modified architectures.) In what ways (if any) does the architecture deviate from the basic implicit invocation style? Explain how your system implements each of the new functionalities required.

3.

Critical Design Issues: Explain your design, justifying your design decisions. What were the key (make-or-break) design issues for your team's solution?

4.

Analysis Based on your experience so far, are implicit invocation systems easier or harder to modify than object-oriented architectures? Why? Describe one other modification (other than the ones you performed) that would be relatively easy to make in an implicit invocation system, and one modification that would be harder.

5.

Alternative Architecture: Could the given system and specified modifications for this assignment be implemented naturally using a dataflow architecture? If so, briefly explain how. If not, explain why not.

6.

Extensions: Suppose you had an implicit invocation system with a Registrar component that announces OverfullEvent when a registration is full (and does not register the student for the course in that case), and a SectionAdder component that listens for full sections and then creates new sections for overfull courses. Describe the race condition that this would cause, and how it might be resolved. Does your solution to this problem fit well within implicit invocation architectures? If not, what aspects of your solution would violate implicit invocation principles?

7.

Concurrency and Ordering The implicit invocation system provided in the Events package ensures that all events that are caused by a single announce, whether directly or indirectly, are complete, and that all methods are called before the announce call returns.

(a)

Would your solution still have worked if the system delivered events in an arbitrary order, and did not guarantee their delivery prior to returning from an announcement? Why?

(b)

Identify differences in your solution that would have been necessary if the system allowed concurrency (for example, by implementing each component as a separate thread).

(Hint for (a) and (b): Consider data integrity constraints such as whether or not all data has been written to the repository before a component tries to read it.)

The commentary should be your own work; i.e., individuals, not teams for commentary.