|
A1.1 |
Mon |
Sep 17 |
2012 |
Team (for Concrete Architecture) |
|
A1.2 |
Mon |
Sep 17 |
2012 |
Choose 2 systems (book chapters). You will present 1 or 2 systems |
|
A1.3 |
Mon |
Sep 17 |
2012 |
First half of survey of Target System (by individual) |
|
A1.4 |
Mon |
Sep 24 |
2012 |
Entire survey of Target System (by individual) |
|
A2.1 |
Mon |
Oct 01 |
2012 |
Landscape (by team) |
|
A2.2 |
Wed |
Oct 10 |
2012 |
Clustered Landscape (by team) |
|
A2.3 |
Mon |
Oct 15 |
2012 |
Concrete Architecture Report (by team) |
|
Part 1 |
Mon |
Oct 22 |
2012 |
Proposal |
|
Part 2 |
Mon |
Last day of classes Dec 3 |
2012 |
Final Report |
Email a list of team members (size about 3 people) to instructor (for Assignment 2 and for Project).
Choose 2 systems (book chapters). During the term, you will present create and present surveys of 1 or 2 systems, ideally from the 2 you choose (but perhaps not). Email your choices to the instructor.
Complete the first half (through “basic metrics”) of the Survey for the Target Software. Do not communicate with author of the Brown/Wilson book chapter or other people related to the system. Study the book chapter. Search the web. Find the downloadable software. Email a PDF version the half completed survey to instructor.
Submit your complete survey of the Target Software. Do not communicate with author of the Brown/Wilson book chapter or other people related to the system. Email a PDF version to instructor.
Produce the concrete architecture of the Target Software.
Using LSEDIT produce a software landscape of the Target Software, using TA extracted from the Target System. You do not need to group files into subsystems. Mail a screen shot of the landscape to the instructor. Do not email the TA file.
Group the top-level entities of your landscape from A2.1 into subsystems (and those subsystems into subsystems if necessary) by modifying the TA. Mail a screen shot of the new landscape along with the modified TA to the instructor.
Submit your concrete architecture of the Target Software. Give a clear description of each subsystem or module within you top-level subsystem. Describe the architecture of one of the (interesting) top-level subsystems. Use LSEdit to produce diagrams of the concrete architecture.
Make sure the high level (architectural) structure is clear. Avoid giving too much low level information. Make sure the reader gets a good feel for how the system works (how it carries out its operations).
Limit your paper to at most 10 pages. Bring a hardcopy to class and email a PDF version to instructor.
Carry out a project and write it up in the format requried by WICSA. Turn in a hardcopy and mail a PDF copy to the instructor. Note that 10 pages is the maximum for WICSA. See http://www.wicsa.net/ See also WICSA’s “topics of interest”. Submissions must be formatted according to the IEEE CS proceedings format (8.5" x 11" two-column format). Templates and instructions can
be downloaded from the IEEE Computer Society Press
[http://www.computer.org/portal/pages/cscps/cps/cps_forms.html].
Projects are due the last day of class.
Some Suggested Topics
Following are some suggested topics for the course project. You are encouraged to propose new interesting topics relevant to this course.
Description
Refactor the architecture of a large software system to support a new feature. Take one of the systems that were studied in previous years, or choose a new program. Specify a new feature, extract its architecture, identify architecture refactorings to accommodate the feature and analyze impacts and risks. Identify possible tool support (and possibly implement) for this process.
You can also identify an architectural problem and come up with a refactoring to solve the problem.
Requirements
You must choose a software system larger than 100 KLOC. Example systems: Linux, Mozilla, PostgreSQL, MySQL, Emacs, Gnumeric etc. Your project submission should discuss tools actually used, and tools that would have been ideal to use.
Description
Analyze the historical sequence of refactorings of the architecture of a large software system. Take one of the systems that were studied in previous years, or choose a new program. Extract the architectures over a historical sequence of versions, discover architectural changes, identify the causes for changes and the kind of architectural refactorings have been performed. Identify possible tool support (and possibly implement) for this process.
Requirements
You must choose a software system larger than 100 KLOC. Extract at least 5 versions. Example systems: Linux, Mozilla, PostgreSQL, MySQL, Emacs, Gnumeric etc. Your project submission should discuss tools actually used, and tools that would have been ideal to use.
Description
Studies on the architecture of many systems in previous years showed how different the concrete architecture was from their conceptual architecture. Take one of these systems, identify how their concrete and conceptual architectures differ, and repair both the conceptual and concrete architectures. Identify possible automated tool support (and possibly implement such support) for this process.
Requirements
Example systems: Linux, Mozilla, PostgreSQL, MySQL, Emacs, Gnumeric etc.
Description
Build new tools or integrate existing tools into the toolkit used in this course. Examples:
Requirements
Before implementing anything new, study existing tools that accomplish similar tasks and identify the weaknesses that your tool will overcome. Validate usefulness of the tool by using it in the study of a system.
Description
Produce a landscape of a large piece of software. Examples:
Requirements
Landscape that was not done in previous years.
Description
Extract the architecture of a family of systems. Identify the commonalities and variablities of features in the systems family. Decompose the architecture based on the features. The configuration of the architectural components may be extracted from the pre-processor directives (#ifdef), makefiles or other artifacts.
Last update 22 Aug 2011
-- RCH