|
System Design Document - Revision Control
|
|
formattedDocument
|
| Section |
Currently being edited by
|
Link to plain text
|
| INTRODUCTION |
| 1.1 Purpose/Objectives/Goals |
Complete
|
|
| 1.2 Glossary |
Complete
|
link |
| 1.3 Overview (Document Overview) |
Complete
|
|
| DESIGN BREAKDOWN |
| 2.1 System Decomposition |
Complete
|
|
| 2.2 Concurrency Issues |
Complete
|
|
| 2.3 Data Management |
Complete
|
|
| 2.4 Resource Handling |
Complete
|
|
| 2.5 Software Control |
Complete
|
|
| 2.6 Boundary Conditions |
Complete
|
|
| MODULES DEFINITION |
| 3.1 Declaration of Entities |
Complete
|
|
| 3.2 Operations of Modules |
Complete
|
|
| 3.3 Module Interaction |
Complete
|
|
| Module Interation Diagram |
Complete
|
|
| CONTROL CENTER MODULE - SHOULD BE BRIEF AND CLEAR |
| 4.1-4.3 & 4.5 Entities, Attributes, Functions, Assumptions |
Complete
|
|
| 4.4 Diagram portraying the interactions of functions/data |
Complete
|
|
| EDITOR MODULE - SHOULD BE BRIEF AND CLEAR |
| 5.1-5.3 & 5.5 Entities, Attributes, Functions, Assumptions |
Complete
|
|
| 5.4 Diagram portraying the interactions of functions/data |
Complete
|
|
| SAVE/LOAD MODULE - SHOULD BE BRIEF AND CLEAR |
| 6.1-6.3 & 6.5 Entities, Attributes, Functions, Assumptions |
Complete
|
|
| 6.4 Diagram portraying the interactions of functions/data |
Complete
|
|
| COMMUNICATION MODULE - SHOULD BE BRIEF AND CLEAR |
| 7.1-7.3 & 7.5 Entities, Attributes, Functions, Assumptions |
Complete
|
link
|
| 7.4 Diagram portraying the interactions of functions/data |
Complete
|
|
| ERROR HANDLER MODULE - SHOULD BE BRIEF AND CLEAR |
| 8.1-8.3 & 8.5 Entities, Attributes, Functions, Assumptions |
Complete
|
|
| 8.4 Diagram portraying the interactions of functions/data |
Complete
|
|
Note:
- "WIP" = Work in Progress
- Red = No work done
- Green = Some work done but the section is open for more editing
- Blue = completed
Updates:
~Vincent
Just updated the CCM diagram, and Bret's paragraph works perfect over there, I think we should use his paragraph.
~bpeake
- Okay I have finished adding the "class diagram" section for the control center module. Instead of including a diagram with too little detail to adequately explain the Control Center Module (as DS was afraid it might) or update the diagram (and entire paper for that matter) to include a new system control entity which would make for an overly complicated diagram when you added the connections to the other 4 modules.... I have just added a brief paragraph glossing over why I decided not to include a diagram. If you have time please read it over and let me know if this concerns anyone. If the feeling is that the abstracted diagram would be better I could put that in instead.
- All that should be remaining is to update the version control at the start of the document (that I will do shortly) and update the table of conects and activity log. If there is anything else we should change/improve let me know asap.
- Good work all :)
DSharpe
The document is looking meaty and impressive.
I'm not sure the diagram for the CCM is really as it should be. The CCM entity is going to have interactions with the Editor entity, yes, but also the File Processor Entity and the Communication Processor entity. The fact it has interactions with these entities is integral to the fact that it's the "Control Center Module."
~DS
~bpeake
I have added the communication diagram to the doc but it may need revisions. Perhaps we needed a "Control Processor" entity as it seems like it should be the entity that calls the CreatePacket function...
I'll start adding the remaining sections to the document. The boundary conditions will be a lovely fit for one of my tables. I worry that he might say use cases should only be used to elicit requirements, but to me it seems like your use of it was very effective in portraying the system design boundries...
~Yuan Huang ( Vincent )
Just finish the diagrams. I will check wiki frequently, in case u guys want me to change any thing.
~ Dave F
Ok I've got most of the Design Breakdown up on wiki, if you guys see anything missing or to add feel free to edit the page. The Boundary Conditions have 3 use cases in them which may or may not require use case diagrams (its up to you guys, I think it should be fine with just a 'fancy template table' eh brett? ;) ;) haha )
Anyways, with the access area I spent like 45 minutes trying to make an access matrix but it really isn't worthwhile, we don't need access so I just erased it all. So it looks kind of empty on that section, but I don't think we can really do much about it. I did state that bit about mac address security, but still if you guys can think of anything else for that area too it could use a bit of a beef up.
~bpeake
For the glossary I have just been adding terms whose context in the paper implied inherent knowledge. When in doubt I suggest add it, as it can't hurt.
Vincent if you have time can you double check the class diagrams I am putting into the document. I am adjusting Kwabena's diagrams a little bit as we update the system design. If you could look over updates I have made and suggest any changes, that would be great. I have finished the save/load module so far. I will let you know when the communication module is complete.
Things like "Motion Plan" and "Motion Command" are in the glossary, and they're both entities. Should the entities listed in the "Modules Definition" section be there too?
~DS
I see that about the File Processor. I don't see a problem with that. Encapsulation of functions.
~DS
Sounds good.
~ DS
p.s. "Center" should be spelled "Centre" because we're Canadian. *fixed*
p.p.s. Hey, I spelled it like that in my document too. Ah well, eh?
~bpeake
Sorry I'm not completing any section, I'm just busy touching up the diagrams and adding them to the document. For the Modules definition section I envision something like:
Declartion of entities: (list all the entities and a brief, one sentence blurb, since they are scattered throughout the different modules)
Motion Plan - bla
Movement Command - bla
Editor Interface - bla
Input/Ouput Files - bla
Communication Processor - bla
File Processor <== I'd like to add this entity to the save/load module so that I can put the save/load functions into this object
Message - bla
Error Handler - bla
Declaration of Modules: (Same structure as the entities, with a small blurb saying that they were formed by grouping related entities)
Module Interaction: (A short blurb - descibing the system as "centralized control" or that nice term you had in mind previously DS)
Does this sound good or would you like to see something else with this section?
I'm awake, and I'm going to start writing, once I choose some topics.
I'm a little unclear on the "Modules Definition "section. What goes there that isn't covered by the following sections? Is it a general overview of the modules and their interactions? Is "Declaration of Entities" somewhat analogous to "Declaration of Modules"?
~DS
~bpeake
This is the class diagram we are mostly working from (using as a template)
~Dave F
I'll keep a-pumpin, and thats great that hes on those diagrams... makes me kinda wish I bought the damn book haha =p That would probably have made things easier
~bpeake
Hi Dave. I've added your section into the formatted doc. Looks good. Pump out as many sections as you feel up to :)
As for the diagrams I believe Vincent was going to take on the remaining three. I would like to have heard from him, but for the time being I will add his name into the table so there is no confusion on who is currenlty working on what. When you read this Vincent could you please confirm that you are infact working or going complete these sections (and possibly give a rough time frame for it).
Also I have finished cleaning up the formatting/editing of the module sections so I will change their status to complete. However if you would still like to edit these feel free, just append an asterisk onto the plain text link so I know something has changed.
~Dave F
Ok I don't really understand what the diagrams want, when it says how the functions/data interacts I don't know the format it expects us to be doing this in. Is there some place I can go for an example? In the meantime I will start on the documents
~Kwabena
Find the general overview of the system diagram, the save/load module diagram, and the communication module diagram from this link to the document.
~bpeake
- I've added the formatted document and the "plain text" for the different sections. I've also added the new sections I think we need. Does this look like an okay spot to put them? Most of the new sections will just tell you to refer to the explanations of different modules that are located later in the document...
- The "plain text" is just copied and pasted out of the formatted document so it may not be that easy to work with. If you do add modify something to the plain text and want it updated in the formatted document please put an asterisk (ie: * char) beside the link. This will indicate it has been updated and once I have added the updated changes I will remove the asterisk.
- I have still have some formatting to do so it isn't looking too pretty but it's getting there.
~bpeake
Communication protocol
link.
DSharpe
I'm looking over the communication protocol again, and I've got my own, fairly similar, ideas for modules. I'll post sometime tomorrow.
~bpeake
I have created a simple layout for the document. We don't have to use this, but it should help us start thinking what the document should include/look like. It closely follows what he talked about in class on Feb 9. Feel free to change/add to the document design table or start writing a section if you have information or diagrams you want included.
You will see I have defined 4 Modules for our station software:
- Motion Plan Module (responsible for creating the motion plans - perhaps this should be broken into another module for interpreting the movement commands?)
- GUI Module (responsible for input/output with the operator)
- Communication Module (reponsible for the sending and recieving of commands with the robot)
- Save/Load Module (responisble for saving and loading motion plans)
I don't necessary think these should be the final modules we go with so please add feedback around this.
I did respond to Scott Jones's email (of our sister team) and David Sharpe and myself met with their group on Feb 9th to lock down the communication protocol. You will see I have included the results of our discussion in the communication module. Please look this over and comment on anything that looks troublesome... or anything that looks good :)
All in all, this should allow us to start thinking and possibly start doing some work before we meet (on Monday?).
Comments (0)
You don't have permission to comment on this page.