COMP 529 Winter 2010

Project Description


Overview

The goal of project is to give you hands-on experience with architectural design, component and connector technology, architectural reasoning, and technical communication.

The term project will consist of the architecture-centric development (see Chapter 2) of a software application that integrates at least two large-scale components. The allowable components should be large (e.g., more than 10,000LOC) and provide a sophisticated set of services. Examples include CCFinder, the Mylyn Monitor plug-in, a complex GUI widget, CheckStyle, Google Maps, Firefox, Excel, etc. The application can be anything you like that builds on existing components. You should discuss the project with the TA and instructor prior to committing to your chosen components.

Example of past project include:

Components and integration infrastructure will be discussed in detail in class, and many concrete examples will be provided.

Teams

The project will be done in teams of 1 to 3 students. Team members will be jointly responsible for the entire project, and for reaching the learning objectives of the project. Students will be responsible for forming their own team. 20% of the project grade will be individually adjusted based on anonymous individual reports of teammate contributions. For example, in a team of two where teammates determine that student A did 60% of the work and student B 40%, for a project grade of 80%, A would receive 83.2% and student B, 76.8%.

Organization

The project will be organized in 5 deliverables. Deadlines are posted on the main course webpage and in the assignments page on WebCT.

Submission Policy: All deadlines are firm. This is to ensure fairness, a speedy feedback, and consistency with the course schedule. Please plan ahead. If you are not done by the deadline, submit your partial solution. The WebCT submission site allows you to submit early and to resubmit. To avoid the usual issues with last-minute submissions, you are encouraged to submit early. After a small grace period the webCT system will block submissions. Milestones not submitted on time are subject to a significant penalty (Immediate penalty of 20% of total possible mark, with an additional penalty of 4% of total possible mark per hour (e.g., a submission 2hrs late on work marked out of 100 receives -28 marks).


Milestone 1: Project Overview

This first part will involve the following activities:
  1. Create you team.
  2. Choose the type of application you will implement.
  3. Choose the components you will use.
The deliverable for this part of the project will be a text-only submission to WebCT containing: - The names of all team members - A 1 paragraph description of the type of application you wish to build. - The name of the components you will use, with a short description an a (single) URL to the best reference document or portal. This part will be worth 5% of the total project mark. The mark will be based on timely submission and clarity of the description.

Milestone 2: Inception

For this deliverable you will study and test your components and draft an architectural design for your application. This deliverable will be worth 15% of the total project mark.

TODO:

DELIVERABLE:

A five-page report, in the format described below, that includes the following sections:
  1. Overview of the application. What you will build, from a user's perspective. Include a succinct list (or a table) containing the major functional and non-functional requirements (table can be in 10pt-font). Do not assume any specialized domain knowledge from readers.
  2. Overview of reused technology. Describe the components you will use: the services they provide, the major architectural decisions they embody, and the assumptions they make. State why you have chosen each component. Describe how you have tested your components. Make sure to include a reference to the components.
  3. Overview of the architecture. Describe the architecture for your system along at least two different architectural perspectives. For modeling and visualizing the architecture, follow UML or a close variant, as described in Chapters 6 & 7. Carefully document the major design decisions. Clearly identify the components and connectors. Describe the types of connectors and the applicable dimensions. Describe any architectural style or pattern you have considered.
  4. Discussion: Describe the rationale for your architectural decisions; Describe the main technical challenges, risks, and open questions you envision encountering. Include any additional pertinent insights or interesting discoveries,
If you feel the need for concluding thoughts, please include them in the discussion.

Milestone 3: Initial Prototype

For this deliverable you will produce a working prototype and a report that includes a refined description of the architecture and a discussion of the main architectural issues encountered. This deliverable will be worth 30% of the total project mark.

TODO:

DELIVERABLE:

A seven-page report, in the updated format described below. This report should be a refinement of your initial report that takes into account our feedback for M2 and includes the following sections:
  1. Overview of the application. A summary of the main purpose of your application, its primary usage scenarios, and the reused components. Basically a compact abstract of what your project is about. This section should distill and merge sections 1 and 2 from the M2 report and be fairly short.
  2. Architectural concerns. What are the main architecturally-relevant concerns for your system? (see Section 6.1.1; We have also discussed important concerns during the case studies). Why do these concerns matter in your project? Identify at least three.
  3. Architectural models. Model your architecture, focusing your effort on the concerns described in the previous section. Model at least one view per concern, but ensure that all the major components and connectors are represented in your model(s). Choose the modeling notation and visualization that is most appropriate for each view. Briefly justify your choice of views, modeling notation, and visualizations. Make sure to include any important constraints (such as style or implementation constraints) that your architecture must respect. Also include the rationale for your decisions. This should be the main section for your report.
  4. Architectural analysis. Review Chapter 8 in the book and discuss how your architecture could be analyzed and the concrete benefits that would be gained through architectural analysis in the specific case of your project. Consider the various goals (which ones are the most applicable to you? why?); the scope of the analysis; the types and techniques, etc. [Optional] research an architecture analysis technique in more depth than covered in the book and sketch how it could be applied to your project. Talk to the instructor if you would like to consider this option (for more space in the report).
  5. Implementation. Comment on the current status of your project. Refer to the specific architectural elements and describe their implementation status. Present one or two code snippets (10 pt. monospace font, max 3/4 page) showing how the main connectors are implemented in your application. For each snippet, indicate which connector is represented and ensure that the code is commented or explained in a small paragraph. Describe the remaining risks and open questions.
  6. Architectural degradation: Describe all the changes in your architecture (including the addition of new decisions). Discuss the causes and consequences of these changes and whether they are symptoms of architectural drift or erosion.

Milestone 4: Completed Application

For this deliverable you will produce a working application and a report that includes a refined description of the architecture, a refined description of the architectural issues encountered, and summary of the lessons learned. You will present your project and your findings in class.

TODO:

DELIVERABLE 1:

All the source code and resource files you have authored, with a plain-text README file that describes the structure of the code and list the libraries needed to build it. Submitted as a zip file.

DELIVERABLE 2: (25%)

A six-page report, in the format described below. This report will focus on architectural decisions and should take into account our feedback for M3 and includes the following sections:
  1. Overview of the application. A summary of the main purpose of your application, its primary usage scenarios, and the reused components. Basically a compact abstract of what your project is about. This section can be taken from M3 and be fairly short.
  2. Overview of the architectural model. An architectural model representing all the application (all components and connectors) using the most appropriate notation and visualization. A textual explanation of the architecture that describes the roles of the components and their interactions. The purpose of this model is to help us understand your entire system at a glance.
  3. Architectural decisions. What were the main architectural decisions for your application? For each decision, include: a) the decision; b) the quality attributes it supports; c) the techniques, patterns, or 3-rd party resources you used to realize it; d) how it maps to your overall architecture. Discuss at least 3 decisions. You are free to discuss more decisions in less detail or only 3 decisions in more detail, as appropriate.
  4. Architectural evolution: Describe how your architecture evolved throughout your project. For example, what decisions did you need to revise as you learned more about your system and your 3-rd party components? Be sure to link this discussion to specific model elements and architectural decisions.
  5. Lessons learned: What are the thee main lessons you learned about the architecture-centric software development of your project! (You don't need to tell us that it's hard to get along with teammates or that leaving things to the last minute leads to panic...). For example, what activities were particularly helpful/unhelpful? What concerns was more worthy of your attention? Your lessons should be specific to your project and concrete. Avoid speculation and generalization.

DELIVERABLE 3: (10%)

Prepare a 20min talk about your project (one talk per project). Your talk should address the main points of the report. Talks will be randomly assigned to the last three lectures. All team members must present.

DELIVERABLE 4: (15%)

Schedule a 20min demo with the TA. The available time slots will be posted on WebCT. Send three potential dates/times to the TA by email. During this demo you will demonstrate your working application and answer questions about its implementation and architecture so your must prepare in advance a sample scenario to demonstrate and a tour of the implementation. All team members must be present.

DELIVERABLE 5:

Only for groups of two or more. Fill in the (very simple) M4-Group Report assignment on WebCT to indicate your best estimate of the respective contributions of each member to the project. 20% of the total project grade will be based on this report (see top of the page for example). Mark calculation will be based on the average of all submitted reports for a given team.

Format

All reports should follow these formatting guidelines:

Important writing tip: Use the space carefully. Avoid boilerplate, content-free text. Do not use "waypointing" text or any sort of similar fillers (e.g., "we presented our architecture, the element catalog, the list of interactions, and some UML diagrams"). Describing complex systems clearly is hard, and every sentence should directly contribute to that goal.

Resources

The project is an essential part of the course. It should be assumed that completing the project will require readings (e.g., manuals, web resources, etc.) that go beyond the class readings listed in the schedule. The Instructor and TAs will remain available throughout the term to answer questions and provide suggestions about the project. Some important topics related to the project will also be covered in class.

Academic Integrity

Except for the component reused and explicitly documented as such in the project reports, each team must author the entire code of their project.

McGill University values academic integrity. Therefore all students must understand the meaning and consequences of cheating, plagiarism and other academic offenses under the Code of Student Conduct and Disciplinary Procedures (see http://www.mcgill.ca/integrity for more information).