Project #3 Sample - Code Repository Prototypes

Version 1.0,
Due Date: 12:00 am, Sunday, Wk7
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 prototypes to support a Remote Repository. To implement that, we need a communication channel and Graphical User Interface (GUI) to support an easy to use mechanism for managing code from other locations, e.g., clients on the local network or somewhere else in the internet.
The Remote Repository must support operations implemented in our Local Repository, but accessible from another machine, e.g.:
  • File managment
  • Version control
  • Package ownership
  • Checkin and Checkout
  • Package browsing
This project will develop two of the necessary parts for that: a message-passing communication system that is also capable of transmitting files, and a GUI that allows the Repository Clients to participate in code management activities in a relatively simple way.
In order to make our communcation channel reusable in many other applications, we will use a message-passing mechanism instead of Remote Procedure Calls (RPCs). This moves application specific details out of the channel and into the client and server implementations where they belong.
We also would like to make our GUI as useful in other applications as feasible. To do that we will implement a tabbed display with each tab devoted to a particular client activity. Each of those activities will be defined by processing that is not encoded into the Window code, but rather is defined in terms of a set of services that are called by the window event-handlers.

Requirements:

Your Remote Code Repository Prototypes 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 implement a message-passing communication channel using Windows Communication Foundation (WCF).
  4. Shall define a Message class that provides:
    • 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 define service contracts for sending messages and for uploading and downloading files.
  6. Shall provide simple test client and server, designed to show that the communication channel works as specified.
  7. Shall provide a Graphical User Interface with a set of tabbed views. Each view provides or displays information for one of the Repository activities, e.g., CheckIn, CheckOut, Browsing, and making queries about the stored versioned package content.
  8. Shall provide, for each view, one or more packages that perform all of the processing necessary to send requests, receive query information, upload and download files.
  9. Shall use the Local Repository of Project #2 to test the GUI operations2.
  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.
  2. The GUI displays must show, unambiguously, that the GUI meets its requirements, as stated above.

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 implement WCF applications. As we will explain, you don't want to use the Visual Studio WCF Project wizard. Instead use the starter samples provided in Project #3 Helpers.
  3. How to implement WPF applications. You will find some of the demos in Project #3 Helpers will get you started quickly.