Final Projects - Spring 2019

Tiny HTTP Client and Server (TINYHTTP):

---

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: TOC

Cross-Platform GUI using Chrome and Tiny HTTP Server (CPGUI):

---

The idea:

The .Net framework on Windows provides an elegant UI framework called 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: TOC

Cross-Platform Library (CPLIB):

---

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 FileSystem-Windows). It would be interesting to reimplement based on std::FileSystem (C++17 : Microsoft C++ supports an experimental version). That has an interface based on directory_entry and iterators, which is harder to use than my FileSystem-Windows. I used essentially the same design as the .Net System.IO classes.
• 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¹.
• Process Pool, supports spawning a fixed number of processes that communicate with a mother process to get tasks to run, with the added benefit of process isolation.
• 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: TOC

C++ Testharness using Process Pool (CPPTH)

---

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

Repository using Pluggable Components (REPO)

---

The idea:

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

• 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?
• Dependency Information:
  How dependency information is stored and accessed, e.g., with metadata XML files or with a NoSql database.
• Versioning:
  How are versions tracked? How does a user explore the version sequence of a specified package?
• Ownership:
  Are packages owned by a single developer? by a group? by any registered Repository user?
• Checkin and Checkout Process:
  How are open (incomplete) checkins and closed (complete) checkins identified and managed.
• Browsing:
  What kind of information is supplyed to the user to browse the Repository structure. This is related to how storage is managed.
• 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: TOC

REST Web Services as Program Components (REST):

---

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: TOC

MicroServices (MICROSERV):

---

The idea:

Microservices are small, self-contained, building blocks used to create larger systems. The application aggregates a number of services to implement as much of its functionality as is practical. The application code instantiates services it intends to use and communicates with them using messages. If the services reside in seperate processes, then the design uses socket-based asynchronous messaging with HTTP style messages. If a service resides in the same process as the application code, then messages are sent directly to the receiver's queue. Application design focuses on selecting a set of services and configuring messages to support application activities. This project, of course, will have to build an initial set of services, based on a specified service architecture. Links: TOC

Virtual Display System (VDS):

---

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: TOC

Virtual Repository Server (VRS):

---

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: TOC

Remote Data Acquisition and Visualiation using NodeJS (NODEJS):

---

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: TOC

Cloud Computing (CLOUDCOMP)

---

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: TOC

Personal Website using the MEAN Stack (MEAN):

---

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: TOC

Visio-Style Drawing Tool (DRAW):

---

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: TOC

Graph Visualization (GRAPHVIZ):

---

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: TOC

Software Visualization (SWVIZ):

---

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: TOC

Audible logger (SPEECHLOG):

---

The idea:

It's a good idea to build loggers that allow programs to enqueue log items asynchronously, allowing the program operation to proceed quickly, while a background thread writes out the logged items from the queue. If you provide the child thread access to a vector of output streams, it writes each logged item into every registered stream in the vector. One of those streams could be a text to speech translator. The windows API provides that capability, and there may be open source libraries for that, as well. In this project you implement a logging library in C++ that provides at least three levels of logging:

• normal results
• demonstration outputs
• debugging outputs

You may wish to use a static thread-safe blocking queue so that logs written anywhere in the program are handled in the same logging process. Links: TOC

Using Web Applications on the Desktop (WEBDESKTOP):

---

The idea:

I might use a technology like that to make a WPF-based demo of my web site, perhaps building a slide show of pages and menu dropdowns, with commentary in an adjacent panel. You can think of a lot of interesting applications that could use this idea. What this project attempts to do is to build an application that works like a conventional browser, but doesn't have any of the browser chrome, e.g., borders, toolbars, buttons, ... Instead, it embeds a browser control in a GUI like WPF so you can tailor its functionality to suit a particular application. Mozilla labs (now shuttered) built a demo of that, and posted to github. Microsoft built a browser control for IE, then built an updated version for Edge. This is a "bleeding-edge" project in that the Mozilla project is now inactive, and the Edge browser is being redesigned to host the Chrome V8 engine. Links: TOC

Directory Synchronization using GO Language (GO):

---

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: TOC

Systems for Continuous Integration (SCI)

---

The idea:

Software Integration Issues:

Resources:

This project considers two, rather different, systems for supporting continuous integration:

• Microsoft's Team Foundation Server:
  This is a supported product that provides configuration management using either Team Foundation Version Control or git, automated builds, and testing and release management. It is intended to be a back-end for Visual Studio or Eclipse IDEs.
• Software Collaboration Federation (SCF):
  This is an idea, that has been partially realized in a series of projects in CSE681 - Software Modeling and Analysis, and CSE687 - Object Oriented Design. The intent is to use this idea as a straw man for what may be a desireable set of functionality for large scale developement. This project will use (SCF) as a reference for what may be an effective platform and use that to question, and perhaps modify, the way that Team Foundation Server supports development.

The Goal of this project is to evaluate Team Foundation Server's use in support of large projects, and to develop advice about process, tools, and configurations appropriate for its use in this context. One way to do this is to download a sizeable open-source project of interest and add some new functionality. Alternately, we could use one of these DO class projects as the controlled baseline. TOC