Skip Ribbon Commands
Skip to main content

Quick Launch

  
Attachments
  
  
  
Notes
  
9/2/2012 12:00 PM
  
Regular Class Meeting

​Major Decisions:
- Decide to keep adapter interfaces inside respective team folders; the clear separation of responsibilities between groups is worth the uglyness of keeping controller code in another folder

Controller group cares about:
- Network: IControllerAdapter.IControllerAdapter, INetworkLayer.INetworkLayer
- GUI: IModuleView2ControllerAdapter
  (IView2ControllerAdapter [important], IView2Controller [connects to Network] [Composite maybe from Module] )
    * Connect
    * Disconnect
    * DisconnectAll
  IControllerAdapter
- Modules: IModule???
 
Controller group specific notes:
- When converting the String to IPAddress, use System.Net.IPAddress.Parse(String ipAddress)
- GUI gives a String, network expects an IPAddress
- IModuleManager.ExportModules
- Network.HandleModuleRequest, Network.
- return list of IModuleFactories
 
Modules explains:
- Trouble with TFS, interfaces in Sharepoint (unaccceptable! Controller group is not writing/putting your code in TFS)
 
Tasks:
- Need a proper solution in DEV so the Controller group can start writing code

Scattered, less important notes:
- may need an exportModule
- exportModule needs to be on the Network package's INetworkLayer
- the network group has a solution, but it took them a while to make
- the network module uses events that other people can add event handlers to (need to provide others the ability to subscribe to events)

9/2/2012 11:59 AM
8/30/2012 10:00 PM
  
Regular Class Meeting

​Date: 8-30-12
Time: 19:00 - 21:00
Attendees: Apoorv, Martha, Nathan

Tasks Completed:
* We put together a list of methods we believe need to be connected in the Modules package.
 These could be a preliminary Adapter interface for the Modules group, assuming the methods are as we guessed.
* We discussed how to structure the Controller and decided one Controller, one adapter interface per group, and six implemented adapters.

 

Major decisions:
* Need to figure out actual subsystem with interfaces (this is upcoming and should be the responsiblity of the individual group)
* Probably have six implemented adapters, six (?) adapter interfaces, and one Controller. (framework is dead)
* Need to make clear that Interfaces are actually interfaces and not just requests from Controller. (+ documentation)!!!

 

From Proposed Module Adapter Interfaces (separated from guessed functionalit in proposed module interfaces):
IModuleAdapter:
1) IModuleFactory
  + IModule ctreateInstance()
2) IModule
  + IList<Terminals> Inputs( ModuleId moduleID )
  + IList <Terminal> Outputs( ModuleId moduleID)
  + Dispose( ModuleId )
3) ITerminal
  + DisposeTerminal( ModuleID moduleID )
  + connect( M1, T1, T2, M2 )
  + Disconnect( M1, T1, M2, T2 )
  + Value( ModuleId moduleId )
  + Subscribe( ModuleId moduleId )
  + Terminal WireFrom( ??? )
  + Terminal[] WireTo( ??? )

 

What we require from other teams:
* Your adapter interfaces / documentation! Be sure to name them like IModuleAdapter for now. Preferably by tomorrow (Friday) evening.

 

8/30/2012 9:04 PM
8/26/2012 6:00 PM
  
Regular Class Meeting

​Meeting Notes:
Time: 8/26/2012 15:00 - 17:00

Last time, we studied GUI, Network, and Module connection code in Controller.
Apoorv has done a decent job of trying to understand the GUI and the concerned code - maybe can help the GUI people write their docs?

Is there a spec for controller-specific stuff?
Which aspects of the spec require communication between modules?

We're looking at the code and trying to guess what it does.

The Adapters are spread out between the Controller and the other packages.
Maybe we should make Adapters our group responsibility by moving them all to the Controller module, where they should be?
We will need to demand documentation from the other groups if we're to maintain/write the adapters.
(remember: should design, THEN code)

We can't start designing the specific Adapters until we know what needs to talk to what where in the other .

Maybe the other modules should tell us what needs to connect?

Martha - Write UML diagram of Controller (as Archetect, I can do this) CHANGE: need to autogenerate, can't unless we can edit the code

Tasks?:
- write a class diagram for the controller module
- write documentation for controller
- Really need ability to edit code in the repository - need a new TFS repository for F12 with the F11 warmup code
- Need to pressure modules group into writing documentation (otherwise we can't understand)

Findings:
- just reading the code and trying to understand it doesn't work out, we need a greater structural understanding
- We decided to leave the adapter interfaces in each package's folder (thus leaving each adapter interface the responsibility of their respective groups), and letting us implement the adapters themselves...
THOSE NEED TO BE DOCUMENTED.
- We really need documentation!
- Need a universal naming convention for their Adapter Interfaces.
- We need to tell the Modules group that their code is in the Controller (in Controller.Modules and OwlViewController's init() )
- We need a clear separation of boundaries between modules.
- IComputationManager should be in Modules
- IFramework is a little fishy; maybe its logic should either be in the adapters or in the controller
- Some of the classes with interfaces maybe can be generalized more
- need to fix MVC (our job)

MAJOR OBSTACLE: Want to generate UML diagrams, but can't because we aren't allowed to edit the F11 code.

Note: there should be no logic in the Controller!

Random findings for code:
GUI: background of main window is palette
StatelessModule contains lamda function that's assigned to do something (It implements AbstractModule.)
ShellID is the ModuleID and the IP address.
When the palette and modules are combined with a certain Shell. (A Template is everythin involved in a little box.)
Init with module window, selected modules, IP address.
TickingModuleInstance works as a timer/has a timer of some sort.
- There are small coding problems aside from the lack of docs and module code in Controller (bad naming, etc. )

8/26/2012 5:01 PM
8/26/2012 5:00 PM
  
Outside Class Meeting

Meeting Time:  8/26/2012 15:00 - 17:00

Attendees:  Nathan, Martha, Apoorv

Task Completed / Finding /Changes Required:

·         Studied Modules GUI, Network, Module code placed in the controller.

·         Decided upon the implementation of the adapters, according to the team consensus it has been decided that each module (UI, Network, Modules) need declare the adapters for their module and we need the descriptive documentation of their adapters (Interfaces).

Major Obstacles:

·         No specification present specific to the controller.

·         No module has provided us with the documentation or diagrams like UML, class diagram present in the project which made us difficult to understand their code and their relationship with other modules.

·         Warm up Code F11 do not have the write/edit privileges so when we tried to generate the UML diagrams automatically we started getting access denied exceptions.

·         Lots of time has been wasted in understanding in each modules interdependencies.

Changes Required from other Teams:

·         Need documentation specifying their relationship with other module layers.

·         Need to move out the logic of the module layer from controller’s code.

Work Assigned:

·         Nathan:  Would be taking with the Module team and discussing their adapter relationships.

·         Martha: Would be taking with the Network team and discussing their adapter relationships.

·         Apoorv: Would be taking with the GUI team and discussing their adapter relationships.

·         ALL: After understanding the responsibilities and dependency of each module layer we would all design the class diagrams, UML diagrams and documents for the controller layer.

Responsibilities Shared

·         Nathan: Team Designer

·         Martha: Team Architect

·         Apoorv: Team Leader

 

Personal Appreciation

Apoorv:  For doing a decent job of trying to understand the GUI and helping the other members with            their code.

8/26/2012 11:25 PM
8/24/2012 9:00 PM
  
Regular Class Meeting

http://cnx.org/content/m26104/latest/

http://www.clear.rice.edu/comp310/f12/labs/lab03/

8/24/2012 8:43 PM
8/24/2012 7:00 PM
  
Regular Class Meeting

​Agenda for tonight: 

look at code

artifact the code, what's going on

put all the pieces together/find more problems


Meeting time: 20:00-21:30


FindingS: 

1)Team leaders should know team leaders.  Should be on sharepoint.  Architects, (insert role here) should know 


their respective counterparts in other teams.  

2)Logic of modules should be in the modules' code ONLY​

8/24/2012 6:15 PM