Assignment 2D

CS746 Assignments and Project

Overview

Assignment 1: (2 weeks) CONCEPTUAL ARCHITECTURE

   Part 1A     Fri Sept 17 2004 (Team and Account)

   Part 1B     Tue Sept 21 2004 (Mozilla References)

   Part 1C     Sun Sept 26 2004 (Diagram of architecture)

   Part 1D     Thu Sept 30 2004 (Conceptual architecture)

Assignment 2: (2 weeks) CONCRETE ARCHITECTURE

   Part 2A     Tue Oct 05 2004  (Landscape)

   Part 2B     Fri Oct 08 2004  (JGrok scripts)

   Part 2C     Tue Oct 12 2004  (Clustered landscape)

   Part 2D     Tue Oct 19 2004  (Concrete architecture)

Assignment 3 - OPT1: (2 weeks) REFACTORING --- FUTURE

   Part 3A     Tue Oct 26 2004  (New Feature)

   Part 3B     Fri Oct 29 2004  (Feature analysis)

   Part 3C     Tue Nov 02 2004  (Architecture Refactoring)

   Part 3D     Tue Nov 09 2004  (Refactored architecture)

Assignment 3 - OPT2: (2 weeks) REFACTORING --- HISTORICAL

   Part 3A     Tue Oct 26 2004  (Feature Summary)

   Part 3B     Fri Oct 29 2004  (Concrete Architectures)

   Part 3C     Tue Nov 02 2004  (Architectural changes)

   Part 3D     Tue Nov 09 2004  (Summary of Refactoring)

Course Project: Tue Dec 07 2004

Assignment 1: Conceptual Architecture

Assignment 1A

Submit a list of team members (size about 3 people) and your preferred user account name to cs746@swag.uwaterloo.ca. Each group gets only one account.

Assignment 1B

Submit a list of references (articles, books and URLs) on Mozilla to cs746@swag.uwaterloo.ca. These will be shared with the rest of the class.

Assignment 1C

Submit a diagram of the top-level architecture of Mozilla and a one-page description of its high-level subsystems and their interactions. Bring a hardcopy to class and email a PDF version to cs746@swag.uwaterloo.ca

Assignment 1D

Submit your conceptual architecture of Mozilla. Limit your paper to at most 10 pages. Bring a hardcopy to class and email a PDF version to cs746@swag.uwaterloo.ca

For guidance, see Description of Conceputual Architecture.

Assignment 2: Concrete Architecture

Assignment 2A

Using LDX Pipeline, produce a software landscape of Mozilla. You do not need to group files into subsystems. Store the landscape, in TA format, somewhere on the account you were given and send an email to cs746@swag.uwaterloo.ca with the location. Do not send a copy of the TA file to the course account.

Assignment 2B

Write jGrok scripts to modify your landscapes in various interesting ways of your own choosing. Describe how to use your scripts in a README file. Place a copy of the jGrok scripts, README, and modified landscapes somewhere on the account given to you and send an email to cs746@swag.uwaterloo.ca with the location. Do not submit a copy of the files to the course account. See Appendix.

Assignment 2C

Group the top-level entities of your previous landscape (from 2A) into subsystems (and those subsystems into subsystems if necessary). Place the new landscape, and contain.rsf file, somewhere on the account given to you and send an email to cs746@swag.uwaterloo.ca with the location. Do not submit a copy of the files to the course account.

Assignment 2D

Submit your concrete architecture of Mozilla.

Describe the architecture of one of the top-level subsystems of Mozilla. Please choose the subsystem to be distinct from subsystems chosen by other groups. Ideally, the set of groups together will cover all the main top-level Mozilla subsystems.

Your report should be organized approximately like your report for Assignment 1D. Give a clear description of each subsystem or module within you top-level subsystem.

You should use LSEdit to produce diagrams of the concrete architecture. Limit your paper to at most 10 pages. Bring a hardcopy to class and email a PDF version to cs746@swag.uwaterloo.ca.

Assignment 3 – Option I: Refactoring – Future

In this option of assignment, you are expected to design an adaptation (a refactoring) of the architecture of Mozilla to support a new feature. You should address at least the following questions: what feature to implement, what architectural components to change, and how to change. You are to decide upon the feature to be implemented. Ideally, the feature you propose will require some architectural changes to Mozilla.

Assignment 3A

Submit a brief description of a feature that has not been implemented in Mozilla. Such a feature may have shown up in similar products. Explain why you think that feature is desirable in Mozilla. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your description to at most 2 pages.

Assignment 3B

Submit a brief description of what changes need to be made in order to implement your proposed feature. You should identify which components in the current architecture should be modified and which components may be potentially impacted. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your description to at most 2 pages.

Assignment 3C

Submit a brief description of what kind of refactoring needs to be performed at the architectural level to accommodate your proposed feature. You might need to reference Martin Fowler’s online refactoring catalog (http://www.refactoring.com/index.html). You can also come up with your own refactoring. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your description to at most 2 pages.

Assignment 3D

Submit an analysis report for adapting the current architecture to support the requested feature. Describe the modified architecture of the system, the refactoring you proposed, and the components to be modified. Analyze the impacts your modifications may produce and their potential risks. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your report to at most 10 pages.

Assignment 3 – Option II: Refactoring – Historical

In this option of this assignment, you are expected to perform a retrospective analysis of architectural changes that occurred in Mozilla. You should extract several releases (at least THREE) and derive their concrete architectures. Contrast the derived architectures to identify changes at the architectural level. Explain why such changes have occurred.

Assignment 3A

Submit a list of releases you plan to analyze. Describe major features for each release. You need to review online documentation, such as release notes and development roadmap. Ideally, these releases should involve the release of an interesting set of features, which you should describe. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your description to at most 5 pages.

Assignment 3B

Submit extracted concrete architectures. For each release, you need to show its top-level architectural view and briefly describe its components. A desirable form would be half-page picture and half-page description. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your description to at most 5 pages.

Assignment 3C

Submit a brief description of architectural changes by comparing adjacent releases. You should associate architectural changes with major features you described in Assignment 3A. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your description to at most 5 pages.

Assignment 3D

Submit an analysis report on the refactoring, over the period you studied, to the architecture of Mozilla, including a description of introduced or modified features. Describe how the architecture has been modified in order to accommodate changing feature requirements and/or to facilitate maintenance tasks. You should map each feature to corresponding architectural components and related changes. Email a PDF version to cs746@swag.uwaterloo.ca.

Limit your report to at most 10 pages.

Course Project

The following are some suggested topic proposals for the CS746 course project.

1. Architecture Refactoring – Future

Description

Refactor the architecture of a large software system to support a new feature. Take one of the systems that were studied in previous courses, or choose a new program. Specify a new feature, extract its architecture, and identify architecture refactoring to perform, and analyze impacts and risks. Identify possible tool support (and possibly implement) for this process. You can choose to follow Option II for Assignment 3.

You can also identify an architectural problem and come up with a refactoring to solve the problem.

Requirements

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.

2. Architecture Refactoring -- Historical

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 courses, or choose a new program. Extract its architectures over a historical sequence of versions, discover architectural changes, and identify what caused those changes and what kind of architectural refactorings have been performed. Identify possible tool support (and possibly implement) for this process.

Requirements

3. Architectural Repair

Description

We've studied the architecture of many systems, and we saw 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.

4. New Tools

Description

Build new ones or use existing and integrate into the toolkit used in this course.

Requirements

Before implementing anything new, study existing tools that accomplish similar tasks, and identify the weaknesses that your tool will overcome. Validate usefulness of tool by using it in the study of a system.

1. Use/Implement an extraction tool that provides dynamic views.

2. Use/Implement an extraction tool that provides views of languages other than C/C++ (e.g. Java, C#, etc).

3. Use/Implement a tool that provides a method of analysis other than visualization.

4. Use/Implement a tool that does automatic layout or clustering.

5. New Landscapes

Description

Produce a landscape of a large piece of software.

Requirements

Landscape can't have been done in previous versions of CS746 or CS846. You may choose to do one or more of the following:

1. Extract the architecture of an interesting piece of C/C++ code

2. Compose a reference architecture for a specific domain

3. Study the dynamic view of a large piece of software

Extract the architecture of an interesting piece of code not written in C/C++

Appendix

Assignment 2B

Nested Box and Arrow (NBA) Systems and Permission Rule-sets

1) Create a multi-level Sum-of-Products (SoP) permission rule-set R that requires permission to exit subsystems (B = Buy), permission to cross sibling boundaries (I = Import) and permission to enter subsystems (E = Export). The basic relation is to be U (Use), which, with appropriate permission edges, should be allowed to connect any two leaves.

2) Create TA for an example system, called X, with the containment tree (contain) that includes example Buy, Import and Export edges as well as Use edges. Purposely include one illegal Use edge in system X.

3) Create a jGrok program that checks to see if example system X is legal according to your rule set. It should produce a list any illegal edges and should insert “BadU” edges corresponding to any illegal Use edges.

4) Create a TA schema appropriate for system X, including the possibility of BadU edges.

5) Based on your schema, use LSEdit to visualize system X, including any BadU edges (colored red) automatically added by your jGrok program.

6) Prove that the following SoP rule set allows a least one phantom:

T <= P u T o T o P o T u T o P o T o T

Where u means “union” and o means “composition”, P means parent (inverse of contain), T is simply the name of a relation.

You must work individually (not as teams).

Please turn in a hardcopy write-up including the responses each item above.