OwlSimulation Developer’s Guide
Please contact Daniel (IRC, Skype, or dpodder@gmail.com) if you want to edit this document. DO NOT
UPLOAD A NEW COPY UNDER ANY CIRCUMSTANCES!
Introduction
The purpose of this guide is to give you a quick yet informative introduction to the OwlSimulation
codebase. If you are planning on working with the OwlSimulation code—whether debugging it,
extending it, or using it as the foundation for a new project—this is the guide for you!
Formal Specifications
The official OwlSimulation System Requirements and Specifications document is a painstakingly detailed
reference document, and if you haven’t read it yet, start by reading the spec document first. Pay
particularly close attention to the terminology section, the conceptual system overview diagram, and
the implementation section (which also contains a top-level system block diagram). These diagrams are
not duplicated in this document, but the rest of the sections assume that you have a broad
understanding of their structure, and that you have them in front of you for reference.
Team Foundation Server (TFS)
The OwlSimulation code is maintained in a Microsoft Team Foundation Server (TFS) project. Please
contact the Rice University COMP 410 Staff (headed by Dr. Steven Wong) for details on how to access
the server.
The code in TFS is separated into several branches. The principal root of the branching structure is the
MAIN branch; all other branches are descendants of MAIN.
MAIN has two direct descendants (children), DEMO and DEV/Master. DEV/Master is the “master”
development branch, which is where all developed features are propagated into and merged from.
DEMO is a snapshot of MAIN, containing a frozen feature set for the latest demonstration, in addition to
temporary hacks and/or fixes that were necessary to get the code up and running. Changes from DEMO
are never integrated back into MAIN.
DEV/Master itself has four children:




DEV/Framework, the developer branch for the Framework team
DEV/Simulation, the developer branch for the Simulation team
DEV/UI, the developer branch for the UI team
DEV/ITB ("Inter-Team Branch"), a developer branch for code that is written outside of any one
team’s domain
Each team actively worked in these four developer branches. As features were finished and tested in
each developer branch, they would be Reverse-Integrated (RI-d) into the DEV/Master branch. Other
teams’ finished, integrated features could be Forward-Integrated (FI-d) from DEV/Master into any of the
four developer branches.
The four developer branches may themselves have descendants, but any such branches were created
for team-specific needs and will not be documented in detail here. There are also several branches in a
folder called “OLD”; these branches are archived versions of obsolete branches and should generally be
disregarded.
Solution Structure Overview
AspProviders: 3rd party utility code from MSDN to deal with Azure Table
No need to change anything within this project
Refer to AzureTableWrapper for usage examples
OwlSimCloudFabric: Azure Cloud service definitions
Right click and select "Properties" to modify
OwlSimulation.Domain:
Abstract:
ISessionNetworkLayer: Interface for SessionNetworkLayer
Concrete:
AzureTableWrapper: Utility class for storing stuff in Azure Table
COutputResult: Container for the simulation output data
OwlQueueMessage: Container for message between frontend and backend
Packer: Utility class for serializing OwlQueueMessage and put in Azure Queue
QueueSessionNetworkLayer:
Queue Implementation of Session NetworkLayer handling communication
between frontend and backend
SimulationNetworkLayer:
Simulation NetworkLayer Encasuplation that distriute modules, connections to
the workerHandler lists
StorageLayer: Database encapsulation
Entities:
Entities classes used in Azure Table
SimulationManager:
SimulationManager: Class that manages the Simulation Instances
WorkerRole: Azure WorkerRole that hosts the SimulationManager
Building OwlSimulation
TODO
Deploying OwlSimulation
TODO