Course Assignments 20072008

Architecture project

You are asked to design the software architecture for an online learning system satisfying the following requirements. Please

• give a rationale for your decisions,
• follow the guidelines in the course manual,
• and give an estimate for the development effort required.

Remember to send in your architecture document no later than Monday 14 January.

Overview

This document describes the requirements for a distributed collaboration environment for large programming projects, in particular for EHC. A collaboration environment for large programming projects is a set of software tools to help programmers, code reviewers, designers, managers, and researchers to develop and maintain a program. A distributed environment allows contributors to the project to participate independently of physical location.

Data Organization

Code, documentation, and other artefacts required for building the program are organized as a collection of text fragments (or chunks) and normal files. Each chunk resides in a normal file, tagged with a variant number, an optional name, and a type (Haskell, plain text, AG, C, ...). A tool called shuffle extracts chunks and combines these for the creation of source files for further processing by other tools like compilers (gcc, ghc, uuagc, ...) and text processors (lhs2tex, latex, ...). Files themselves are also typed, e.g. based on the suffix of their name. Types are used throughout the system to tailor functionality of system components.

Variant numbers are used to distinguish program variants. This mechanism is used to partition the construction of the program into steps. Each variant therefore builds upon a previous variant: variants are ordered. Subsequent variants may redefine/override a chunk of a previous variant. When shuffle generates its output for a single source file for a compiler, it does so for a particular variant, including all previous variants and taking chunk redefinitions into account. A chunk may explicitly refer by name to another chunk as to include its corresponding text.

Currently, all files reside in an SVN repository. Users collaborate via the SVN repository by checking out its content, modify the local checked out copy, and committing changes.

See also TheStructureOfTheEssentialHaskellCompiler.

Coding Tools

Coding tools are special purpose user interfaces for common coding tasks. For example, code browsing is intended for users who want to learn about the implementation of the system by means of inspection of chunks. Tools may overlap in their functionality and/or may be variations of eachother. All tools have an user interface for the aspects dealt with by the tools.

Code Browsing Tool

Code browsing allows inspection of all artefacts of the project, exploiting the meaning of all formalisms used to encode sources:

• Files can be inspected for their raw content and their location in the svn repository.
• Chunks can be inspected for their raw or pretty printed content, the latter according to its type. Location as well as remaining tagged information can be inspected as well. The hierarchy imposed by the explicit inclusion of other chunks can be inspected as if it were a file system.
• Files can also be inspected in a type driven way: its rendering is dependent on its type.

In general, any referential information available in a file based on its type is exploited by the browser: e.g. chunks may refer to chunks, makefiles to files, source code to imported modules, etc.

Code Editing Tool

Code editing is the modification of any artefact of the project, again exploiting the type of those artefacts. Code editing may be partially or fully integrated with code browsing. The type of an artefact is used to tailor the following additional functionality:

• Name completion: suggest the completion of partially typed keywords and identifiers based upon the available definitions.
• Language construct completion: suggest the completion of partially typed language constructs.
• Check for syntax while typing.

Code Analysis Tool

Code analysis scrutinizes artefacts for properties. Simple properties independent of the type of an artefact are "number of lines" or "number of words". A simple property taking into account the type of an artefact partitions such properties into comment and code. Complex properties like "this identifier is referred to by ..." are also allowed. Users must be able to add new analyses.

Code Documenting Tool

All artefacts must be explained. Explanation may be for a single artefact (e.g. describing an interface), a group of artefacts (e.g. a design decision), or independent of artefacts (e.g. a tutorial). Explanation can be browsed in different ways, the default being per artefact. Explanation can also be browsed as specified by a user, e.g. a tutorial, a paper, or a thesis.

Other Tools

Bug Tracking Tool

Bug tracking allows users to enter problems with the programs of the project. The following is tracked:

• The process of solving a problem, similar to e.g. Google Code.
• The connection to required modifications: design documents, additional documentation, chunks/files, etc.

Feature Request Tool

Feature requests are similar to bugs, but differ in that they address additional functionality instead of fixing existing functionality. Tracking is similar to bug tracking but less structured, and a more liberal use of documents and connecting to artefacts is allowed.

Meeting Tool

Meeting supports the resolution of project related problems. Meeting offers a blackboard mechanism where users can freely communicate by any means they see fit (audio, video, documents). The Bug Tracking and Feature Request tools may be used by the Meeting Tool.

Export Tool

Export of the following:

• Source code distribution.
• Pdf documentation (paper, tutorial, ...).

Exporting requires a description of how to construct the exported material. This is similar to the Unix make commandline tool, but need not necessarily be the same.

Other Requirements

The following requirements address tool independent issues. The required functionality may require tools like the ones described above, but this is left open and depends on the actual need for such tools.

Extensibility

The system can be extended with new types, by the user. This influences all functionality which exploits the type of artefacts. Extension of such functionality is part of the type extension mechanism. Developers can write plugins which implement all type specific behavior for the various tools. An API (Application Programmers Interface) describes which functionality must be implemented by a plugin and how it can be incorporated into the environment.

Security, Users, Trackability and Blame

The users of the environment can be identified and have different access rights to different tools:

• A user (1) cannot, or (2) can read (3) can modify groups of artefacts.
• A user (1) cannot, or (2) can use a tool

All interaction by a user with the environment is tracked in order to be able to find which user has modified which artefact. Users (and user groups) can be organized into user groups so that access can be regulated per group instead of per user, as to ease the administration of access.

Interface Technology

All tools are available in two varieties:

• Platform independent, as web browsing clients, interfacing to the environment via web application technology (i.e. Wiki, HTTP, etc).
• Platform dependent, using the capabilities of operating system platforms (MacOS? , WinXX? , Linux, ...) the provide a more integrated interface (like Eclipse, ...)

Repository Technology: Use of SVN, Use of a repository

All data is available in at least the following varieties:

• As a SVN repository, to allow developers to work in the classical "checkout + modify + commit" cycle.
• As a database based repository, for fast access by analysis tools.

Maintaining consistency between these two is a concern that must be addressed.

Other Concerns and Quality Requirements

• The system must be responsive for common editing activities. Less frequently used functionality may take more time but must indicate the expected time an operation takes.
• The system must either guarantee consistency between the various copies of artefacts, that is, in user interfaces, applications and repository. Of, if it cannot guarantee consistency, it must indicate possible inconsistency and indicate how long it takes until consistency can be guaranteed, possibly offering the user a way to help by making necessary choices between inconsistent parts.