Final Projects

The idea:

The goal of this project is to support testing of more than one type of code. It does this by defining a base process class that supports process creation and communication with the main TestHarness process. Derived classes are defined to support a particular type of code execution, e.g., managed C# or Java code, or native C and C++ code.

This project will use C++ sockets to build a message-passing communication system, and C++ code to develop the TestHarness, Process class for loading and executing C and C++ library code, and a demonstration client.

The process class for testing C# code will be written in C++, but is intended to support starting and communicating with a process written in C# that loads C# libraries, and may use a C++\CLI wrapper to communicate with the Testharness.

The process class for testing Java code will be written in C++, but is intended to support starting and communicating with a process written in Java, that loads Java libraries and will use Java sockets to communicate with the Testharness.

The idea:

The goal of this project is to support management of code and documents using pluggable components for:

1. Storage:
   The mechanics for managing directories and placement of files. Means for identifying the root of dependency chains, identifying Systems, Modules, and Packages. Are categories used? Are they based on namespaces?
2. Dependency Information:
   How dependency information is stored and accessed, e.g., with metadata XML files or with a NoSql database.
3. Versioning:
   How are versions tracked? How does a user explore the version sequence of a specified package?
4. Ownership:
   Are packages owned by a single developer? by a group? by any registered Repository user?
5. Checkin and Checkout Process
   How are open (incomplete) checkins and closed (complete) checkins identified and managed.
6. Browsing
   What kind of information is supplyed to the user to browse the Repository structure. This is related to how storage is managed.
7. Building
   When and how packages are built into libraries. How are Graphical User Interface (GUI) codes handled. How are codes from different languages handled.

Components will be defined using interfaces and object factories. There needs to be a component installation interface that allows a component to register with, and be activated by, the Repository. Since some of these services need to use other services, there needs to be a way for them to communicate. One way is to use function call interfaces, but that means that every component may need to know the interfaces of many other components. That isn't a good idea as it promotes a very tight coupling between components.

One nice solution to this problem is to use message-passing communcation between components, as well as between the Repository and its Clients. This way each component has to support a "PostMessage(Message)" interface where the parameters of the call are encoded into the body of the message. The message has a "from" and "to" property so that the Repository's message dispatcher knows where to send the message, and the message recipient knows where to send a reply. Yes, you can support properties in C++.

One interesting question is how the Repository will be hosted. Here some options:

The idea:

The goal of this project is to implement small and simple components, HTTPClient and HTTPServer, used to build message passing communication channels in C++ on both Windows and Linux. Those can be used to communicate between any two platforms that support native code, e.g., Windows, Linux, Unix, Macs, etc. The most important measure of success for this project is to create a small code base to efficiently send messages with very low complexity for the using applications.

This project will use sockets (you may use a sockets package found in the Repository) to send HTTP style messages. Each message has a header consisting of text lines - the first is a command, and subsequent lines are attributes that describe the message with key:value pairs, e.g., content-length:543 implies that the header is followed by a block of 543 bytes of data. The HTTPClient and HTTPServer components will be developed for both Windows and Linux platforms. Another measure of success is the ratio of common code to that which is unique for each platform. Ideally that ratio should be large.

You may re-implement one of your class projects that used WCF or another socket implementation. Alternately, you may collaborate with one or two other students working on a project that requires message-passing communication.

Links:

The idea:

This project extends an existing C++ library of low-level program support components for both Windows and Linux. The idea is that each component provides the same interface on all supported platforms, but uses the operating system APIs to implement the interfaces. The current library has classes to manipulate files and directories for both Windows and Linux. To that, this project will add, for both Windows and Linux:

• FileSystem library (already complete for both Windows and Linux - see Repository).
• Sockets library, probably based on the library provided in Handouts/Repository. This will focus mostly on porting the existing Windows library to Linux and testing the result.
• Process library to create, start, and communicate with new processes. This will use the Windows and Linux APIs to implement a Process class with some of the capability of the .Net Process class.
• Thread Pool (already complete for Windows - See Repository, this may run on Linux as-is, but needs testing), using C++11 threading and locking constructs. This will involve creating a specified number of threads that block on a thread-safe blocking queue waiting to dequeue lambdas that define the work to be done¹.
• Communications library, perhaps based on collaborating with students working on the preceeding project.
• Graphical User Interface library, based on collaborating with students working on the next project.

Links:

The idea:

The .Net framework on Windows provides an elegant UI framework call Windows Presentation Foundation (WPF). On Linux there are a lot of GUI frameworks² that work well but don't provide the declarative programming style that WCF exposes through Xaml. The intent of this project is to provide a new alternative that works for Windows, Linux, and Macs, based on use of the Chrome browser and one or more HTML5 pages to support declarative layout of the user interface.

Each application that uses this new framework will host a tiny HTTPServer, as developed in the first project, and, on startup will start Chrome with an appropriate HTML5 page and Javascript library. Communication between the application and chrome is based on Ajax calls, e.g., a button click will send a message to the application to do something that usually will not result in downloading a new page to Chrome. The application performs the requested action and returns any information that needs to be displayed, probably using JSON or XML.

The result is that we can build cross-platform applications using the support libraries, developed in the preceeding project, application code that is common to both platforms, and GUI code that is also common to both platfroms.

Links:

The idea:

REpresentational State Transform (REST) services are web services that use the HTTP commands (Get, Post, Put, Delete, ...) as verbs that each describe an action applied to objects that are identified by a url. Unlike conventional web services REST does not use an embedded infrastructure like Simple Object Access Protocol (SOAP). It's messages are passed in clear text unless transmitted over SSL. REST applications are usually simpler and faster than conventional web services.

This project explores the decomposition of applications into a set of REST services and a small amount of glue code to complete the application. You might think of this as a UI application that delegates all of its processing to this set of REST services.

This allows applications to share a lot of code with other applications that may be remotely located. Think of the service collection as a repository of functionality that may be used across a federation of servers in some enterprise application.

Links:

The idea:

In a Software Modeling & Analysis final project (Fall 2012) we explored the use of a large display as a medium for collaboration in a Software Development Server Federation. This project implements a prototype for this kind of display system.

VDS is an application that drives a large display³ for use in collaboration systems. The purpose of this project is to develop a framework and rendering process to display simultaneously web-cam windows, document windows, drawing surfaces, directory views, and information derived from queries into NoSql Databases or some repository.

For this project the displayed resources would be source code text, pdf files, sketch pads, skype windows, all drawn from a local repository. It could be implemented as a browser displaying an HTML5 page that supports adding and removing elements, changing view sizes and locations, and saving a current session in some persistant format like XML.

Links:

The idea:

The Virtual Servers defined for this project have three properties:

• Support a clone operation that builds a clone of an existing server on any Windows or Linux platform that invokes the source server's clone operation. The invoker can request that some subset of the source server's content be replicated on the target server.
• Use a message-passing communication system based on the Tiny HTTPClient and HTTPServer from the first project.
• Implement a message dispatcher mediator that makes adding new server functionality exceptionally easy.

One obvious application of Virtual Servers is in Software Collaboration Systems. A project might have Repository, TestHarness, and Collaboration servers. Any one of the teams using the collaboration system may wish to replicate a Repository or TestHarness for their own team activities for initial development, before checking in software to the Project Repository.

Links:

The idea:

There is currently a lot of interest in using the MongoDB, ExpressJS, AngularJS, and NodeJS (MEAN) stack for developing responsive, scalable websites.

In this project you will explore these technologies by implementing a personal website that has the following features:

• Resume Page
• Repository page with descriptions and links to your project code submitted during your program and/or developed out of personal interest. This should include a mechanism to view individual pages of source code.
• A story page, telling your story with well formated text and pictures, e.g., your Undergraduate Program, your Program at Syracuse University, your work experience, etc.
• Other features that use specific properties of the MEAN stack.

You could subscribe to a hosting service and provide a link on your resume for prospective employers to view.

Links:

The idea:

Develop a drawing tool that provides a (small) subset of the facilities of Visio, but is easier to use. For example:

• Templates for specific visual objects like classes, packages, activity diagrams, connectors, etc.
• The ability to move visual objects and/or the break points for connecting lines, i.e., the places where a connection line forms a right angle.
• Connection points on visual objects that support maintaining the connections as a visual object is moved in the diagram.
• Annotating visual objects with text and dropping text on other parts of a diagram.
• You might, time permitting, implement a communication channel that allows remote collaboration using the drawing tool.

There are two interesting ways to implement this tool:

• Using HTML5 & Javascript. This would require you to implement a Javascript object model that wrapped the various visual objects.
• Using Cinder & C++11. Cinder is a C++ framework that wraps OpenGL, making it significantly easier to use. Here, you would implement a C++ object model for visual components.

This tool has an obvious application to the Visual Display System.

Links:

The idea:

Graphs - collectons of vertices connected with possibly directed edges - are very useful data structures for capturing dependency relationships, geographic relationships, corporate and team structures, etc.

For some applications the graphs may be very large, e.g., dependencies between packages in a large software system. The easiest way to extract useful information from large graphs is to view them in some well organized structure, perhaps on a computer screen. However, when the graphs are large it is not obvious how to organize them properly, e.g., place vertices in a view in which there aren't a lot of crossing edges. The larger the graph the more difficult it is to lay out the graph manually, e.g., by drag and drop.

This project focuses on routing and displaying possibly large graphs by simulating a physical system in which each vertex has a repulsive force on every other vertex, perhaps inverse square law, tending to push apart the vertices, and edges have a restraining force pulling the two end-point vertices together, thus preventing infinite expansion of the graph. Here's an example bl.ocks.org.

You would also need damping forces, proportional to the speed of motion of the vertices, to prevent oscillation in their motions. The way this routing algorithm behaves is determined by the constants used for the inverse square law repulsions, linear attractions, and linear retarding forces.

You will find a C++ graph class in the repository. So using Cinder to render the graphs would be a fairly direct way to approach the project implementation. Alternately you could port the Graph class to C#⁵ and use WPF for rendering.

Links:

The idea:

This project depends on the results of the preceeding project. Here you build the mechanics to determine dependency relationships between packages, and use that information to draw a dependency graph, where each vertex is associated with metadata that describes its package.

This supports traversal and exploration of large software systems. It could be very useful in a code repository for QA activities and for importing large projects into an existing repository.

Here all of the package information, including child dependency relationships is stored in a NoSql Database. We build one of those last semester in CSE681 - Software Modeling and Analysis in Project #2. You will find my implementation of that project in the Repository.

Links:

The idea:

Microsoft has released, in Visual Studio 2015, functionality for building applications for several different platforms, i.e., Windows, Android, and iOS. In this project you will build application(s) that run in at least two of those platforms.

One interesting possibility would be to collaborate with a team building a REST web service, Virtual Display System, or Personal MEAN Website. Alternately you could build an application that merged information from twitter and facebook.

Links:

The idea:

GO is an interesting new language developed by Google engineers. Unfortunately it does not support classes, but does have many interesting and powerful facilities, built in concurrency with coroutines, interprocess communication, and a built in web server - sort of like the C Language on steriods.

In this project you implement a directory synchronizer using GO. Directory synchronizers are used to:

• Update existing files in the target directory from newer files in a source directory on another machine.
• Optionally it will also copy files from the source directory that don't exist on the target machine.

This will give you the opportunity to explore the way communication channels are used, how concurrency works, and the ease of use of the GO syntax.

Links:

The idea:

NodeJS is a Javascript framework that focuses on spawning activities on a remote server. The NodeJS framework is based on the Chrome V8 Javascript engine and has a hosting process that allows Javascript applications to run in an executable outside the usually browser framework. It is based on a Single Threaded Apartment model⁵ that reads messages out of a queue and executes the message's request on a single thread. That has some interesting performance implications.

A lot of environmental sensing systems use remote sensors that communicate with a central server to capture a stream of values about environmental variables, e.g., heat, acidity, chemical composition, etc. and a NodeJS based system would be ideal for managing that sensed data.

Doing that will probably be impractical for a project in this class, but we could substitue data streams gathered from social media or simulated environmental models.

Links:

The idea:

Use the open-source Ubuntu Cloud which wraps OpenStack in a Ubuntu wrapper, or OpenStack Cloud directly to set up a demo cloud and develop a simple demo application. Alternately use Microsoft Azure or Amazon AWS via a developer account to set up and explore a cloud application.

Another interesting possibility is to use Node.js to build a private cloud.

Links: