Due date and electronic hand-in

The assignment is due by 10:30 am on Monday, February 9. Place the completed files into an ``a1'' subdirectory of your team's directory in the dogbert/Architecture directory. In addition to your program, this directory should contain 3 text or Microsoft Word97 files (or earlier): ``solution1",``solution2", and ``solution3". These files should describe the solutions to the three objectives of the assignment, and each should contain:

• the names of all team members

• a list of the files you use for the solution, with an indication which file is changed or new. All your changes should be well documented within the files.

The directory should also contain the source files for the entire system - .class files are not necessary (it will be recompiled), but it would be a good idea for you to test them anyway. The system will be graded and tested exclusively from this directory; however, a different repository will be used for testing than you used in your development. All changes to code and scripts must be clearly commented in the code.

Before class on the due date, permissions to the directories will be disabled and you will not be able to modify the files. In addition, there will be individual written commentary (due at the beginning of class on Monday, February 9) answering the following questions:

1.

What is/are the problem frame(s) for this assignment? Draw problem frame diagrams with domains and principal parts. The diagram on page 183 of Michael Jackson's Software Requirements & Specifications is an appropriate guide for expected content. Precisely designate (describe) the domains shown on your diagram(s). Justify your choice of frame(s). Discuss any issues with fitting the problem to the frame(s) and how you resolved them. The diagrams and designations should reflect the consensus of your team's discussions but should be individually drafted.

2.

What is/are the primary make or break issue(s) for your architecture? Be sure to describe what driving criteria were used in developing this architecture, and address what design choices were affected by your choice of a make or break issue.

3.

Describe the architecture of the original system, explaining how it is an example of a pipe-filter architecture, and in what ways (if any) it deviates from a pure pipe-filter. (Hints: Consider these questions and issues: What components accesses which portions of the data in the repository? Are they reading or writing data, or both? What are the strengths and weaknesses of this approach? How does ignoring the repository change the architecture? Is it okay to ignore the repository when trying to figure out the architecture? Why or why not? If this is not a pure pipe-filter architecture, then is it possible to make it a pure pipe-filter architecture? If not, why not? If so, what would be gained and/or lost in the process? These questions are to help you get started and to analyze the architecture you were given - you do not need to answer each of these, but you should consider them in the process of answering this question.) You may use ACME for your architectural descriptions and diagrams; documentation is at:

http://www.cs.cmu.edu/afs/cs/project/able/www/AcmeStudio/index.html

4.

Describe the architecture of your revised system (both the provided part and the parts you added), explaining how it is an example of a pipe-filter architecture, and in what ways (if any) it deviates from the basic pipe-filter style. Describe how your system implements each of the new functionalities required. Justify your design decisions. Be certain to use architectural concepts and vocabulary (not programming language constructs). You should provide architectural diagrams for both provided and modified systems. You should develop the provided system diagrams as a team and include copies in this section. The modified architectural diagrams should be individually developed. You may use ACME for your architectural descriptions and diagrams; documentation is at:

http://www.cs.cmu.edu/afs/cs/project/able/www/AcmeStudio/index.html

5.

How would your architecture change if you were to register students for available sections of full or conflicting requests, rather than just reporting conflicts and full sections? Describe the possible alternative architectures and consider under what circumstances or cases each solution might be preferred. Include diagrams of your alternative architectures.

The commentary should be your own work: i.e., individuals, not teams for commentary except for items specifically noted for team development.