Einingalíkön og hermun
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.||
This is the most important question you will ever ask, when building a simulation!
Then follow up with:
|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
|*||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
(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|