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:
- A system to allow users to execute SQL queries against
Microsoft Excel files (using a JDBC driver for Excel and an SQL
client).
- A specialized code search client embedded in
Eclipse.
- A Google Maps based Network Management System
(where different nodes on the network are displayed on a map).
- An application that "tracks" buses and animates them on a
Google map by extrapolating from the published schedule.
- A
desktop client for weather data.
- A code refactoring engine
(that uses the output of a source code analysis tool to
recommend refactorings).
- A speech interface for a game.
- A sequence diagram generator based on profiling data.
- A
code history analysis tool that can compute high-level
differences between two consecutive versions of a Java project
(e.g., move method).
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:
- Create you team.
- Choose the type of application you will implement.
- 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:
- Write drivers for all your components, i.e., code to
programmatically access the components and exercise the desired
functionalities. Ensure that you can use them as desired. Study their
behavior. Carefully document any assumption they make about their
running environment.
- Make a list of the basic functional and
non-functional requirements that must be met for your application to
meet its goals.
- Design the overall architecture for your
system. What styles and patterns are most appropriate? What
connectors will be useful?
DELIVERABLE:
A five-page report, in the format described below, that
includes the following sections:
- 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.
- 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.
- 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.
- 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:
- Identify the main architectural concerns relevant to your project.
- Capture (model) the decisions related to these concerns through a
set of views. Choose the most appropriate modeling notation and
viewpoints.
- Think about the different ways that your architecture could be
analyzed.
- Continue the architecture-centric development of your project by
focusing on the implementation of most of the interactions between
components. By the submission date you should have a working prototype
of your application that exercises most of the component interactions.
- As you progress, be sure to document any changes to your
architecture (set of principal design decisions).
- Write the report.
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:
- 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.
- 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.
- 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.
- 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).
- 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.
- 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:
- Finish your application.
- Write the report.
- Prepare a talk.
- Prepare a demo of your application and sign up for an
appointment.
- Complete the group contribution report.
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:
- 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.
- 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.
- 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.
- 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.
- 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:
- 11-point fonts
- Single-spacing
- Single-column
- No sub-section numbering beyond 2 level (e.g., 2.1).
- No deeply-nested bullet lists.
- 1 inch margins
- Submitted in PDF
- No cover page: only include a header, taking a maximum of 1/4 of
the page, including: title, milestone number, course number, author
names, and group number (provided by the TA).
- All sections should be numbered, with Title capitalization.
- References should be listed in alphabetical order of first author,
and referred to with numbered citations (e.g., "According to Smith
[1]").
- All figures and tables should have a caption (below figures and
above tables).
- All material (figures, tables, text) that you have not authored
should be referenced to the original source.
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).