Nov
5
Some Design for the Design Doc
Filed Under Uncategorized
Okay, so here’s what we’re looking at for the Design Doc. I don’t think it’ll be too bad, but it may prove a bit tedious.
1. Introduction
This shouldn’t be a big deal. It looks like the same basic thing as the introductions to our previous papers.
2. Scope of the System
This one might be a little tricky. Section 2.1 requires a system-level use-case diagram, so we probably want to figure out with Dr. Polack exactly what she wants from us in that regard. I’m not sure how well our project suits a system-level diagram. Section 2.2 isn’t a big deal; that just discusses deliverables, which is easy enough. Section 2.3 is our context diagram, so that’s just a matter of making it based on the one we’ve done in class. Finally, 2.3.3 will be the interrupt-driven system model.
3. Hardware, Software, and Network Specification
This should be another simple section. We’ll need to mention not only the computer requirements, but the Mindstorms stuff itself, but that’s not a big deal. I don’t think we’ll have a network, unless Dr. Polack wants us to count interaction between robots, and between the computer and the robots.
4. Module Decomposition
Here we might have to get a little creative in certain sections, notably 4.2 and 4.3. Everything else will be a little weird, but I suggest we base most of what we do on our individual modules. Then, I think things will work out without too much difficulty.
5. System Design Description
Finally, this section has some parts we may not need (like 5.4: Security Strategy), though we’ll have to clarify that with Dr. Polack to be sure. Section 5.1 will be the coding standards we use for our ROBOLAB modules. For Section 5.2, we might want to ask if Dr. Polack wants a description of the website, or if we should stick to the inputs the robots get.
The last section is another Appendix; we should just make sure that it has what it needs this time around.
-Brandon
Comments
2 Responses to “Some Design for the Design Doc”
Leave a Reply
You must be logged in to post a comment.
Besides the length, it doesn’t seem too bad. I’d like to go in to see Dr. Polack and clarify _everything_ before we start writing, and then have her check it a few times for good measure.
I wouldn’t mind going in to see her, but I’ll be out of town for most of tomorrow. I could go in on Wednesday after class, maybe.
I just got back from talking to Dr. Polack about it, and it sounds like everything will work pretty well in this fashion. The main thing that is different is in the Input and Output sections; the former is any sort of input (i.e. from the sensors) that the robot gets, and we should discuss, module by module, what the robot does with that input. We only need to do output for modules that actually print some kind of data to a screen somewhere (like with the Vernier probes, or if we could have the light sensor print its readings to the screen on the robot itself). Beeping also counts as output. Turning and things, however, do not, and if a module doesn’t have any output in any other sense, we don’t have to deal with it in that section. Finally, we don’t have any security, either (Section 5.4).