Project #4 Sample - Remote Code Repository

Version 1.0,
Due Date: 12:00 am, Sunday, Wk10
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:

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 baseline1. 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.
In this project we will be creating a Remote Repository. Most of this effort will involve integrating the prototypes you built in Sample Project #3 with the Local Code Repository you built in Sample Project #2. This project will implement code management operations:
  • File managment
  • Version control
  • Package ownership
  • Checkin and Checkout
  • Package browsing
From a remote client. Users will be presented with a Graphical User Interface that should support these operations in a relatively simple way.

Note:

For your project #4, you have a requirement to revise your OCD, developed in Project #1, to reflect changes to your concept as you implemented each of the projects. Here, you will find a revised OCD for the Sample Projects. It updates the OCD, a word document, in Project1Sample folder. Here's a link to the document: OCD docx.
This revised OCD was constructed as a webpage, due in part to difficulties, with Word, displaying some kinds of information, especially related to GUI views. I've experimented a bit, trying to make the document useful for conveying a lot of information about the concept and its implementation. You will find that you can navigate with key presses, just as you do for lecture pages and notes.

Requirements:

Your Remote Code Repository Project:
  1. Shall be written in C#, using the .Net Framework. You may also use helper code provided in Project2Helpers.
  2. Shall use Visual Studio 2015, Community Edition available at no cost.
  3. Shall use the message-passing communication channel as implemented in Sample Project #3.
  4. That channel Shall send Message class instances that have:
    • Source and Destination addresses
    • Message type
    • Author
    • Time-Date
    • String body:
      Expected to hold an XML string supplying information needed to execute a specific request.
  5. Shall support uploading and downloading files.
  6. Shall provide a Client, with GUI, and Repository server, in separate processes, that allow users to exercise the complete functionality of the Repository.
  7. Shall demonstrate each of the Repository activities, e.g., CheckIn, CheckOut, Browsing, and making queries about the stored, versioned, package content.
  8. Shall create an updated version of your Project #1 OCD, that accurately represents the concept as you have implemented it. Please comment, in an appendix, the differences between the two OCDs and what you learned, in these projects, about expressing a solid concept.

  1. 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.

What you need to know:

In order to successfully meet these requirements you will need to know:
  1. How to integrate several relatively complex sets of packages into a solution holding projects for each process you need.