Project #1 Sample - Code Repository OCD

Version 1.0,
Due Date: 12:00 am, Sunday, Wk2
Note:
This is a demonstration project, which you are not expected to implement.
Instead, you will implement the projects linked on the Synchronous pages.

Purpose:

The acronym OCD stands for Operational Concept Document. It's purpose is to make you think critically about the architecture, design, and implementation of a project before committing to code. It also serves to publish your concept to the development team, which for this course is you.
One focus area for this course is understanding how to structure and implement big software systems. By big we mean systems that may consist of hundreds or even thousands of packages1 and perhaps several million lines of code.
In order to successfully implement big systems we need to partition code into relatively small parts that are easy to understand and easy to test. This is important because we need to thoroughly test each of the parts before inserting them into the project's software baseline2. In order to do that effectively we need to understand each of the packages, their modifications, and dependencies on other packages.
As new parts are added to the baseline and as we make changes to fix latent errors or performance problems in existing packages, we will be creating new versions of existing packages as well as creating new packages. When we make changes we will run test sequences for those parts, all the parts that depend on the changed parts and, occasionally, for the entire baseline.
Because there are so many packages, some with several versions, we need a Repository to store the baseline and some semi-automated processes for checking in packages, for versioning, and for making queries on the Repository contents. These sample projects all focus on the structure, design, and implementation of a Repository for storing code baselines.
One obvious question is why would we do this since there are many well-established code control systems, e.g., git, Subversion, etc?
In order to implement a system for continuously integrating new code into complex systems, our goals are to detect breakage as soon as feasible after submitting a change to the baseline. That means that we want to test, not only the changes, but also all packages that directly depend on the changes. The most commonly used code control systems do not make the needed dependency information available, and sometimes make it awkward to extract just the packages needed for an integration test. Our Repository will be designed to provide fine-grained, dependency-aware, package management, to support continuous integration testing.
In this and following projects we will be creating a Repository - a semi-automated storage mechanism that provides pluggable policies for:
  • File managment
  • Version control
  • Package ownership
  • Checkin and Checkout
  • Package browsing
The term "pluggable" means that we can substitute one version of a policy with another without requiring any changes to the Repository code. We will see that means that policies will need to be implemented as components - a software part that has an interface and object factory2.
For this project we will develop and document the concept for creating a Repository that we will then implement in Sample Project #2, Sample Project #3, and Sample Project #4.
Your concept should explore:

Requirements:

  1. Shall be prepared as a PDF file, using embedded gliffy Diagrams3.
  2. Shall explore and describe the user interface(s) you will provide.
  3. Shall partition processing into at least the top-level packages.
  4. Shall describe the uses/responsibilities, activities, events, and interactions of each of the packages in your concept.
  5. Shall use both text and diagrams for the descriptions in 4, above.
  6. Shall document any prototype code you develop in an Appendix. You don't need to include source code in your OCD document, but you do need to discuss the design of the prototypes. Please include your source code in the zip file used to submit your project for grading.
  1. In C# a package is a single file that has a prologue, consisting of comments that describe the package and its operations, one or more class implementations, and a test stub main function that serves as a construction test while building the package. This test stub is quite different from the test drivers we use for integration test. We will discuss these differences in detail in the lectures.
  2. A software baseline consists of all the code that we currently consider to be part of the developing project, e.g., code that will eventually be delivered as part of the project results. It does not include prototypes and code from other projects that we are examining for possible later inclusion in the current project.
  3. You may use any office suite you prefer like Microsoft office, LibreOffice, or WPS. Please use gliffy for diagramming. It is available as a free chrome app. You will need to use the Chrome browser to install that.

What you need to know:

In order to successfully meet these requirements you will need to know:
  1. The definition of the term package and have looked carefully at a few examples.
  2. How to draw package and activity diagrams.
  3. How to organize and prepare a technical document. Here's some help.