Warmup Project Report
For our analysis of last year's code and development process, each team did an individual analysis on their sections which can be found below:
GUI Team Analysis
We analyzed their development process, however, on a class-wide basis:
- What development techniques and/or processes seemed to be effective and why?
- Sub-team structure with team leaders allowed for small enough groups for communication and tasking to be effective.
- Leadership team structure (PM, Organizer, SharePoint & TFS Masters) distributed duties evenly and handled most important record-keeping.
- What development techniques and/or processes seemed to be ineffective and why?
- They initially started with only three teams - Modules, Network, and GUI. The lack of the Controller team was extremely ineffective. Based off of what we've learned so far, the Controller team is one of the most critical, as it should shape what responsibilities the other teams have. Without the Controller team, each team does not have a distinct sandbox to work in, creating a coupled system which can easily break and become 'dead' as team's progress deadlock each other.
- Last year's team waited on making concrete API decisions until they had a decent amount of code. This combined with the amount of coupling they had led to different teams' code led to breaks whenever the API was changed.
- TFS structure was all over the place - code had to continually be moved around and edited (namespaces).
- Tasking and human resources management seemed to have failed. Some teams were struggling (Modules/Network) while other teams were finished and off designing 'fluff' features (GUI).
- Suggestions for changes to the development process with substantiated motivations for the change.
- Immediately created the Controller team from the get go. On the main project, will have them have an even more important role in designing and overseeing different team's 'sandboxes'.
- Spent the second week completely concerned with design / API decisions before code was delved into (a few example files were made). This helped ensure that everyone had a solid foundation in understanding what the project and their section of the project should do and how.
- TFS structure modeled after the DEMO and DEV folders from last year. For next project, will have one solution with different branches (based off of last year's main project's TFS style) rather than a solution with different projects.
- Architecture overview
The overall design of our project consists of three major components: GUI, Modules, and Networking. These components are connected together by the Controller which bridges the interface calls and events triggered between the subsystems.
The Modules subsystem defines the set of original modules and creates module factories that can be used to create each of those modules. When a module is created, it creates the input and output terminals and subscribes the output terminals to listen to changes in the input terminals and updates its own value based on the computation being performed by the module. The terminals also allow for subscribing one terminal to listen to the value change event of another terminal which will emulate the ability of wiring terminals together.
The Networking subsystem will take each module factory that is loaded and registers them into a module factory dictionary. On connection, the peers will send each other their local module factories and when they are received, the client will generate a delegate that can be used later to notify the hosting computer to host an actual module. This delegate will also be used for placing the terminals into a terminal dictionary so that the terminals can notify the remote computer of a change to its value. Finally, when a client receives a list of factories it will fire an event with the list of the factory data (which contain the module signature and the delegate).
The GUI subsystem creates all the views: the main window, the available module palette, and the connection manager. The main window has the canvas that the user uses to place the modules and connect the terminals together. It also supports the save button which will create a composite module based on the modules that are existing in the canvas. The module palette will create a new tab for each factory list from a new peer so the user will know who is hosting the module that the user trying to use.
See the OwlViewUML project for the UML Class Diagram.
- Installation Instructions
- Make sure your firewall is turned off or other users were be unable to connect to your server.
- Operating instructions for all features.
- This can be found in the program in the Help Window.
- Project Manager (Carrie)
- Created journal survey each week on SharePoint
- Read all of the journals each week and transformed them plus their comments into action and discussion points for the next week
- Created and posted agendas for each class meeting onto their calendar event on SharePoint (at first, went directly into Notes section, now in the Meetings Workspace agenda)
- Worked closely with each team leader, keeping up to date on each team's progress on their design and implementation and current obstacles
- Along with the team leaders, liasioned between teams discussing each team's concrete responsibilities and need dependencies between the teams
- Made a schedule for the project timeline, with deadlines with specific deliverables due
- Scheduled and sent announcements out for group meetings and coding sessions
- Mediated team meetings (in class and out), ensuring that objectives for each meeting were met and we didn't waste time on any one topic too long
- Created a Meetings Minutes Template and SharePoint Cheat Sheet
- Architect (Randy)
- Initiated the design process for deciding changes to last year’s program
- Updated User’s Guide to reflect changes from last year’s program
- Added Installation instructions
- Created UML class diagram of new project, wrote Architecture Overview.
- TFS Master (Archie)
- I was the chief researcher of how to handle and operate TFS within Visual Studio.
- I set up TFS to allow for teams to create their own projects for development. Showed the class checkout/checkin conventions, and instructed specific techinques like no multiple checkouts.
- Learned (from lots of mistakes) a much better way to structure TFS, including a DEV branch from a Main solution and then branches from this DEV for each team's development. This was not implemented for this project, but will be for the main project.
- Joined everyone's code into the same solution and placed team's code into their proper projects within the solution.
- SharePoint Master (Victor)
- Implemented the initial site map
- Created team pages and defined their layout
- Created Analysis, specs, etc pages
- Set up class meetings with meeting workspaces
- Organizer (Nithya)
- Documented and posted minutes for every meeting .
- Team Leader(s)
- Organized and set agenda for modules team
Scheduled daily and weekly tasks
Keep track of team progress and make sure we're on track
Met with GUI, Networking and Controllers to coordinate integration of modules
Organized and setup meetings for GUI team.
Represented GUI team in Team Leaders meetings.
Relayed design decisions to team and contributed to overall design discussion from the GUI perspective.
Distributed GUI tasks to team and kept track of their progress
- Organized meetings with the group team leaders to discuss functionalities and interfaces.
- Pushed other groups to get code into
the MAIN directory so that integration could begin ASAP and controllers could start making their design decisions .
- Met extensively with Modules and GUI
in order to help them debug, stay up to date on their API's.
- Keep everyone in the team members
updated of the team design followed in different teams, which had helped them
in code understanding and had influenced their design choices.
- Represented the GUI team at team leader meetings. Provided insight to design decisions from a GUI perspective and worked often with the Modules and Controller teams in the restructuring of the design.
- Helped develop the interfaces that represented the different adapters our main, factory, module, and terminal views would need in regards to what information the GUI team sends out to the Controller at different instructions from the user of the program.
- Created the TerminalView and worked in depth with having the TerminalView properly display updated values based on the lambda function call.
- Worked extensively on input terminals getting and displaying their updated values when connected to other terminals
- Added features to other view and windows. For instance added a selection border to the ModuleView, worked on the terminal views being drawn properly on the ModuleView, created the FactoryView, removed the extra tab from the PaletteWindow, and changed windows to have hide features as opposed to closing and re-creating.
- Changed the PaletteWindow to display the FactoryTerminals
- Worked closely with the Controller and Modules team discussing the interfacing between Controller, GUI, and Modules; drew diagrams of call order, discussed differences in interfaces and their concrete adapter implementations, and argued for decoupling based on GUI intrinsic responsibilities.
- Reworked the ConnectionManager to use new IView2Controller connection methods. Also changed ordering of connection protocol on GUI side from adding a peer to our list and then sending out a connect request to the opposite.
- Edited the PaletteWindow to correctly add, remove, and draw tabs containing FactoryViews with a scroll bar (!).
- Helped team with the code in MainWindow, FactoryView, and ModuleView to have correct drag and drop functionality - dropping a FactoryView into the MainWindow results in a new ModuleView being created, dragging a ModuleView in the MainWindow results in it being moved across the screen to a new position and its wires correspondingly moving
- Worked with the Modules & Controller team on updating a TerminalView's displayed value
- Helped determine what our individual views would require from the controller, building the API for the Controller team to use
- Helped organize our analysis of last year's code
- Worked with the existing wire code to apply it to our code, especially our module movement code. Also tweaked the visual aspect of the wires so they would look nice
- Implemented the logic for FactoryViews' creation of new modules upon dropping into the canvas
- Added an error label to the main window, and initially implemented the Create Composite button and name box (basic functionality)
- Implemented logic for connecting between terminals, deleting modules/wires
- Helped implement logic to draw terminals to a canvas instead of a grid, making terminal drawing significantly easier
- Helped implemented the drag and drop functionality of a module. Updated the Mouse_down function in moduleView to select a module for dragging, the canvas_dragenter function to drop module.
- Implemented the update wire when the module was moved around. Using the functions canvas_dragenter to access the module wires and call an update function in wire.cs
- Implemented the update terminal positions relative to each change in dragging the module.
- Went through last years and separated what code were reusable in GUIModule and distributed it to moduleView, terminal View.
- Edited the basic file for factory view and the constructor method.
- Helped the team with drawing terminals for each module relative to the number of inputs.
- Contributed to last years analysis report and making a list of interfaces and API.
- Work with GUI, Controller and Network to hash out control flow of various OwlView functions
- Code analysis of modules
- Design, Architeture, Good and Bad
- Put together final Document
- Add modules section to OwlView to uml
- Unit Tests
- Tests for IModuleFactory
- Tests for Terminal Events
- Tests for IModules
- Work with Adrien to formulate the modules API
- Code review
- QA work on modules
- Canvas modules wasn't removing modules that were deleted
- IModuleManager interface wasn't public
- Designed the “New World Order” of the module system closely with Frank and Kevin.
- Decided to make data terminal-oriented, rather than module-oriented.
- Defined a composite design pattern that allowed composite modules to whole a circuit composed of multiple inner modules.
- Chose to use event-based data propagation to minimize coupling between modules and other systems.
- Wrote proof-of-concept code for Terminals, then Modules, then Factories, then Composite modules, which mostly became our production code.
- Published a living API document for the modules system to try to communicate as easily as possible the design of our system, and how to use it: http://bandgap.cs.rice.edu/classes/comp410/f12/SitePages/Warmup%20Project%20Module%20Team%20Specs.aspx
- Worked closely with Controller team to aid in hooking up Networking and GUI code to the Modules code, after our system was mostly functional.
- Made incremental changes to the Modules system when features were requested by the Controller team and the Modules PM (Kevin).
- Assisted in the design of the "New World Order"
- Code Review
- Unit Tests
- Tests for Terminals
- Tests for Composite Modules
- Tests for EditableComposites
- Tests for ModuleManager
- Worked with Kevin to hash out control flow throughout process of creating and using remote modules
- Put together method call chain for creating remote modules and sending data across remote terminals
- Put together set of functional tests for networking and modules to ensure proper behavior of remote modules after integration
- Incremental changes to Modules System as issues arose in QA analysis
- Assisted in design of MVC
Worked closely with the GUI and
Module team integration and finished the implementation of the adapter
GUIViewAdapter, GUITerminalViewAdapter, GUIModuleViewAdapter, and
GUIFactoryViewAdapter to provide the functionality requested by GUI to connect
to other groups.
- Contributed with the team mates during the analysis of the last year's code.
- Worked with Archie to set up the TFS, so that all the modules/teams could bring their code under the common roof
- Worked closely with GUI in prviding the delegate functions from the module in the cases like value-changed, and creating composite modules.
- Implemented the design of having seperate adapters according to the functionality expected by the teams, whch helped in keeping the code modular and debugging easy.
- Assisted in design of MVC implementation.
- Documented Adapter classes and main Controller class.
- Implemented functionalities in GUITerminalViewAdapter, GUIModuleViewAdapter, and GUIFactoryViewAdapter.
- Contributed to Controller Team Analysis of last year's code.
- Made sure the Controller portion of the project UML diagram was up-to-date.
- Wrote down most of the Controller F11 code analysis and an unpolished documentation writing guide
- Helped get the Controller project and relevant solution on the MAIN TFS directory up and running
- With the rest of the Controller team, analyzed the F11 code and decided to throw out everything but the MVC pattern's structure
- Made final decision to move the Canvas module to the Controller due to lack of a missing fourth subsystem; implemented relevant functionality in adapters
- Helped finalize naming conventions for adapters and adapter interfaces
- Helped implement and connect missing delegates, helped straighten out threads
- Wrote/coordinated much of the network-related code in both Controller and adapters
- Helped finish graceful quitting
- Helped refine Controller code: reduced duplication, filled in missing documentation, pruned comments, filled in missing functionality
- Some bug squashing without and with the other teams (the GUI threading bug, some exceptions, minor bugs)
- Serialization - Contributed to the ensurance that all data can be sent over the network, helped debug the insidious unserializable Type error.
- Stub Modules - Helped develop the stub/double module used for testing pre-integration.
- Factory Sending - Helped design the protocol for sending our factories across the network, both on initial connect and when we create a composite.
- Connection - Contributed to the writing of the original Connection protocol/actual code.
- Dump Debug Info - Wrote the code to dump info for debugging connections/disconnections/checking if we were linked to remote people.
- As a team, we collaborated on the definition of our INetworkService (protocol for talking between computers), INetworkManager (API to the outside world), and overall design of our system.
- Drafted the analysis of last year's design/architecture.
- Stub GUI:
- Created a simple stub GUI which contains a series of buttons for every required functionality (connection, disconnection, terminal value sending, etc), and a list of current connections.
- Delegated Communication (Terminals and Modules):
- Helped design and write the series of network calls that creates a remote module, both on host and user ends, and hooks them up using event-listening delegates.
- Wrote the delegates (which listen to "valueChanged" events) and required network calls to make updating terminal values across the network seamless and automatic.
- Event Architecture
- Helped write the connected event, in addition to the test code in the stub gui which verified its success.
- Factory Sending
- Wrote the concrete RemoteFactory class, which includes the crucial CreateRemoteModule method, which sets up ids, and starts the network call chain for creating a remote module.
- Helped debug unclean disconnection problems:
- Helped determine a valid order for deleting stubs, deleting remote modules, removing both from dictionaries, and then deleting IServiceContracts.
- Wrote deletion delegates for automatic terminal ID dictionary removal and deletion.
- Threaded Connection
- Helped figure out the best design to make connection call nonblocking.
- Figured out a reasonable solution for making symmetric connections.
- Worked on setting up the calls to create a connection and request a symmetric connection
- Helped create stub a stub module, module factory, and terminal class to test the network system
- Worked with Damien on fixing serialization issues. Setting up data contracts, and KnownTypeAttributes
- Filled in the class diagram from the networking project
- Designed high-level communication architecture along with Damien/Randy/Alex and some feedback from the Modules team, taking into account a variety of connection and usage scenarios
- Completely encapsulated the component GUIDs needed for network communication, eliminating a significant number of dependenceies throughout the system
- Made an ill flowchart
- Aided in general implementation of networking subsystem
- Performed cleanup and refactoring, helped with delegated communication (Terminals and Modules), event architecture, disconnection, threading and asynchronous operations
- Provided miscellaneous C# assistance to teammates, especially regarding WCF, delegates/lambdas, and events
- Helped organize TFS by aggressively deleting orphaned directories on server
- Checked in a random GUI fix
Rough Outline for Presentation Tomorrow:
Points to Cover:
- talk about development decisions, design, dev process and end with demo, then Q & A
+ talk about what we want to change for the main project (e.g. Controller team decides inter-team interaction FIRST, not later)
- lessons learned
- time spent
- archie on tfs
- have Randy give a brief description of architecture
+ Adrien gives overview of New World Order and its superiority to last year
(emphasize that composites NOT POSSIBLE at all last year)
- Have one main machine on the projector where modules created (use PM’s)
- Creating some connected local module
- Show drag & drop + delete functionality for wires & modules
- Create a composite module (emphasis that this was not possible last year)
- Create a composite of composites
- Demonstrate cool modules (midi module)
- Connect to a peer
- Connect to multiple peers
- Prove peer-to-peer connection (A connects to B, B connects to C, A & C not connected)
- Having peer disconnect
- Adding remote module, having remote host disconnect