COMP 529 Fall 2007
Project 2 Description
For project 2, you will perform a case study of the
architecture of an actual software system, and report on your
findings. This project will be done individually.
The goals of project 2 are to:
- Provide you with a deep understanding of the practical challenges
and benefits of a specific architectural style.
- Allow you to learn about a specific component infrastructure.
- Allow you to understand how general tradeoffs in architectural
design are managed in practice.
- Learn patterns and solutions developed by other software
- Practice thinking critically about software architecture.
- Develop and apply synthesis skills and judgment in distinguishing
between the essential and accidental aspects of a software
- Acquire experience in documenting a real software architecture.
- Practice technical writing.
In the context of this project, a case study is a high-quality,
narrative description of a software architecture, with an interpretive
perspective on a specific aspect of the architecture. The best way to
understand what this means is too look at a specific example.
The book Software
Architecture in Practice provides 7 case studies for you to
examine. In particular:
As you see, all of the above address a specific aspect (e.g.,
product line architecture) of a specific system (e.g.,
CelsiusTech). Your task for project 2 will be to produce something
similar to one of the above. A mandatory requirement for the
project is to read at least one of the above chapters. Reading more is
- Chapter 3 explores the impact of the modular decomposition
of a system on its architectural qualities through an analysis of the
A-7E Avionics System.
- Chapter 6 analyzes how systems can be designed for high
availability though a study of an air traffic control system.
- Chapter 8 is a case study of the integrability offered by a
flight simulation system.
- Chapter 13 is a case study of how interoperability is
supported by the World Wide Web.
- Chapter 15 is a case study of the development of a
software product line for battleship control systems called CelsiusTech.
- Chapter 16 is a case study of the development of J2EE as an
industry-standard computing infrastructure.
- Chapter 17 studies how a mobile application is supported by
the J2EE infrastructure.
Completing this project will involve the following activities:
- Choosing a target system. The system should be large and
architecturally interesting. Note that larger does not necessarily
mean more work as you only need to focus on a given aspect of the
system. The system does not need to be open-source but you must have
access to it and be able to report on it freely. You can choose a
system that you have contributed to if you did not design its
architecture, and if the system is big enough. You are strongly
encouraged to discuss your choice of system with the TA and
- Choosing a focus aspect. You should determine what
specific aspect of the system you will describe. Again, it is
important to note that the purpose of this project is not
simply to reverse-engineer a system, but to analyze and discuss a
specific aspect of the system. This aspect should be interesting to
you and valuable to report on.
- Analyzing the target system. You will need to analyze the
system, possibly using software tools, to understand how it works and
collect material that will contribute to your case study.
- Write a report. The deliverable for this project is a
single report. You should plan plenty of time to write and illustrate
your report, as the quality expectations will be high.
The only deliverable for this project will be an 10-page case-study
report. The report should be in 11pt font, letter-size paper, with
1in margins, and be in pdf format. You are free to choose any
organization you wish for the structure of your report. The report
should be in polished, grammatically-correct English, and be in the
general style of technical writing for computer science. Your best
examples of this are the case studies listed above, and the textbook.
The following is a list of points you may want to consider and
report on as part of your case study. This list is a starting point:
you can add to it, or
omit some if you feel that they are not relevant to your case (except
for points 1-3, which are mandatory):
- A brief summary of the application/architecture: what it does, why?
- A summary of the component model and the main components and interactions.
- A very brief summary of the technological aspects of the
application/architecture (programming language(s), kLOCs, number of
components, communication technology used (method call, RMI, socket,
etc.), relevant standards).
- Strengths and relevant weaknesses of the architecture (e.g., it's easy to add a new command, but adding a new view is not supported and
requires extreme hacking skills...).
- Component model violations: is there a component or a part in the
application that violates some characteristics of the component model
(e.g., in one case Component A uses socket communication with Component B
instead of the standard communication scheme because...)?
- An architecture usually favors some qualities (testability,
performance, extensibility) over other qualities. Identify those
qualities. Identify violations of these qualities (e.g., the framework
is designed for testability, but in this particular component,
performance was more important as illustrated by ...).
- Evolution (e.g., did the architecture pass the test of time?; How
did the architecture evolve?; What were the motivations?; Did the
component model stay backward compatible?; What was the impact on the
components (and potentially client programs)?; Was there any
In evaluating your project, we will assess the following:
Warning: There is no intermediary deliverable for this project
to allow you to organize it as you wish, and because it is likely to
involve a number of iterations between steps 2 and 3. However, do
not be deceived by the fact that "only" a ten-page report needs to
be delivered. We will expect the report to reflect a significant
amount of work. You should start as early as possible to benefit
from the feedback of the instructor and TA, and to ensure the success
of your project. Starting too late (e.g., a week or two before the
deadline) is not likely to give you enough time to produce a report
that would earn a passing grade.
- Clarity of the architectural description (do we understand how the
- Depth of the analysis (does your report reflect a detailed
understanding or general trivialities?)
- Value of the insights (did you produce a creative and innovative
interpretation of the aspect under study or are you just describing
- Completeness (have you looked at all the main aspects of the
question or is there something obvious missing?)
- Quality of the report (sloppy mess or publication-quality?)
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).
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.