Einingalíkön og hermun


5. Constructionist Design Methodology Review




These slides are in reference to the Constructionist Design Methodology as posted on Mindmakers.





Define the Goals
  High-level goals Specify the primary motivation and goals behind the system to be developed: Provided by instructors
  Mid- and low-level goals This is your task
















Define the Scope of the System
  Specify at a high level what the (sub)system is intended to do.


  • What is the set of questions that my system supposed to answer?

This is the most important question you will ever ask, when building a simulation!

Then follow up with:

  • What is the data?
  • Where is the data?
  • How is it shared?
  • How is it processed/changed?
  Write example scenarios that typify its behavior Use narratives.
Start with an initial write up of a few high-level examples of system behavior. From this, a more detailed specification of the abilities of the system to answer questions can be built, using information from step 1 above. This will guide the selection of which modules to include and what their roles should be.

















  Classify modules into one of three roles In our case: Classify modules into as many roles as necessary
  Find off-the-shelf software and MINDMAKERS.ORG modules Not too relevant for us because of a lack of prior work
  Follow the natural breaks in the information processing path In our case: Try to match information exchange (messages) in your model with information exchange in the modeled system(s)
  Define message types This step operationalizes the role of each module and defines their interfaces.
You already have some experience in this -- now you will use this as a starting point
  Avoid duplication of information The default model: Modules exchange data via blackboards.
Modules with highly different functional roles should typically not need access to the same set of data – if they do it means they may have close functional dependencies; consider coupling them or putting them into the same executable with shared access to the same data.
  Determine the number of blackboards; which modules use which blackboards

The most obvious reason for modules to share a blackboard: They need to communicate directly.

Consider using two or more blackboards if
(i) there is a wide range of information types in the total set of messages in the system, e.g. co-existing complex symbolic plan structures and simple boolean switches;
(ii) there is a wide range of real-time requirements for the information flow, e.g. high-frequency vision processing and low-frequency plan announcements;
(iii) the system needs to run on multiple computers to achieve acceptable performance. It is natural that modules with messages containing similar content share a blackboard. Some modules are a natural bridge between blackboards, as for example when a module producing decisions to act requires perceptual data to make those decisions. Blackboards serve both as engineering support and system optimization.

* Develop and implement unit tests Design simple tests that use monitor modules to test for "normal" and "obvious" behavior of the system. These tests return known results and span short periods of time. They are run for sub-parts of the system.


*New for this project, not in original CDM















Test system against scenarios
  Expected communication (blackboard) throughput Network speed and computing power puts natural constraints on the maximum throughput of the blackboard. Make sure the architecture and the hardware setup meets performance expectations.
  Efficient information flow Static or semi-static information that is frequently needed in more than one place in the system may be a hint that the processes using that information should share an executable. (This is not a good idea when the processes sharing the information are of very different nature.)
  Convenience with regard to programming languages and executables If two modules are written in the same language it may be convenient to put them together into one executable. This is especially sensible if
(i) the modules use the same set of data,
(ii) are serially dependent on each other,
(iii) have similar update frequency requirements,
(iv) need to be tightly synchronized, or
(v) are part of the same conceptual system.














  Go through the steps above as often as needed.  













Assign modules to team members
  This will be your task in each group The natural way to assign responsibilities is along the lines of the modules, following people’s strengths and primary interest areas. Every module gets one Lead that is responsible for that module working, for defining the messages it receives and the messages it posts. A good way to assign tasks, especially if the number of team members is small, is to borrow from extreme programming and assign them to pairs: One Lead, chosen for their primary strength, and one Support, chosen by their interest and/or secondary strength
















Writing Module "Shells": Breadth-First
  Start with "empty boxes" before creating full system Expand incrementally over time while running whole system together
  Define versions with case scenarios Use case scenarios to implement some modules partially

















Test all modules in cooperation
  Use the unit tests to verify sub-components  
  This step often takes longer than expected.  
  It is also one of the most overlooked steps... ...yet it that cannot be avoided – doing so will only force it to happen later in the process, delaying the ability to accurately estimate the project’s full scope, and making it more likely that deadlines are missed and planned functionality has to be cancelled.















Build the modules to their full specification
  This step is naturally done in frequent alteration with the prior step  
  Write modules with resilience A distributed system can be very fragile; write modules to be resistent to downtime
  Write modules with temporal knowledge If the modules are unaware of the passing of time, they are less likely to represent the behavior of the system they are trying to simulate
  Mutability Use the benefits being able to freely mutate modules (split and merge) as the design and implementation process unravels

















Tune the system with all modules cooperating
  This step can be arbitrarily long Depends on the complexity of the interaction between modules, and the complexity of the message content being transmitted between them.
  Estimate time for each component Use scope and given time to assign percentages and duration to tasks in task list