Skip Ribbon Commands
Skip to main content

Quick Launch

Original Proposed Specifications

The "OwlView Virtual Machine System"

The warm-up project is to create a peer-to-peer networked virtual machine system where inidvidual machines present functional modules to their connected peers that they and their peers can "wire" together to form an larger processing module.  (This is akin to the way that National Instrument's LabView (, which some students may have used in other courses.)

Specifications: Application Features
  •  Processing Modules
    • Multiple, typed inputs
    • Only single, typed output required
    • Individual output-to-input connections only allowed if types are compatible
    • Modules must be able to be assembled into a larger, encapsulated, abstractly equivalent module that can be used as any other module.
  • Graphical Use Interface
    • Drag-and-drop interface
    • Inputs and outputs wired together by dragging a "wire" from one to the other.
    • Incorrectly typed input-output pairs should be rejected.
    • Available modules should all those presented by all connected peers
  • Connectivity
    • Transparent operation with regards to machine boundaries.
    • Connection to peers only required to be by typing in known IP addresses.
    • Two-way connections should be automatic when any one machine connects to another.
    • Unlimited number of connections and modules in use.
Requirements: Technical requirements:
  • Technical Requirements
    • Use Windows Communications Foundation (or a package derived from) for network communications
    • Use Windows Presentation Foundation (not Windows Forms) for GUI
    • System design must allow for maximum
      • flexibility
      • extensibility
      • robustness
      • correctness
  • Non-Technical Requirements
    • Detailed analysis previous year's warm-up project code and development process
      • The analysis report should include, at least
        • What the design and architecture is and how it is supposed to work.
          • The good points about the design
          • The bad points about the design
          • What needs to be changed and how
        • Operation of the orginal code
          • What features were and were not implemented.
          • What errors occurred.
          • Documentation issues
        • Code issues:
          • What parts can be reused?
            • With minimal rewriting
            • With mon-trivial rewriting
            • Unusable
          • What additional pieces need to be built?
        • Development issues
          • What development techniques and/or processes seemed to be effective and why?
          • What development techniques and/or processes seemed to be ineffective and why?
          • Suggestions for changes to the development process with substantiated motivations for the change.
      • Interviewing members of last year's team is highly recommended.
    • Technical documentation
      • The code should be fully documented at least to the class and method level.
      • Documentation at the line level is highly recommended for non-trivial processes.
      • A "User's Guide" is required that includes
        • Architecture overview that, in high-level terms, describes how the system works.
        • Installation instructions
        • Operating instructions for all features.
    • Documentation of individual contribution
      • All students must each write a non-trivial amount code that is used in the final product
      • All students must show written documentation of contribution to the final design.
      • Students may (should) work cooperatively on techniques for achieving the program's goals, both from design and coding standpoints.
      • The submitted code may adapt code from previous years.
      • As part of the written documentation, there should clear and specific notations of exactly parts of the system were designed by and written by which students.
        • Simply sayig that a person "helped" is NOT sufficient.
        • Full credit for ANY student will NOT be awarded unless ALL students demonstrate significant contributions at the design and coding levels to the final deliverable!
Grading requirements:
  • Analysis of previous year's warm-up project:  10 %
  • Operational demonstration of the above specifications: 50%
  • Complete documentation: 5%
  • Flexible, extensible, robust and correct (operationally) design: 20%
  • Achievement of significant contribution by all participants: 15%
Due Date:  
  • The class will demonstrate full operationality across all students' machines during class time on Mon, Sept. 10