: Public Text
Created: |
25/07/2009 19:31:10 |
Modified: |
30/01/2010 14:35:04 |
|
Project: |
|
Author: |
T. Kostic |
Version: |
1.0 |
Phase: |
1.0 |
Status: |
Proposed |
Complexity: |
Easy |
Difficulty: |
|
Priority: |
|
Multiplicity: |
|
Advanced: |
|
UUID: |
{632C1234-5635-4d8e-81F6-56A71FE93659} |
Appears In: |
|
<b>[Comments by Tanja & replies by Greg, early 2008]</b><br/>Usage in messages (with DCIM 9) of classes Diagram and Map:<br/>- Permit message uses both Diagram and Map (from GmlDiagramObject).<br/>- ServiceWork and Design messages use only Map.<br/>- Presentation message is a list of Diagram-s with links to about anything in the model<br/><br/>1) Diagram<br/>1.a) Beautify the doc - say what the Diagram is in this model.<br/>[Greg] OK<br/><br/>2) Map<br/>According to the docs of attributes:<br/>2.2) 'mapLocGrid' is said to be "Map grid number." Why is a number represented with a string? Cannot we use some of the attributes inherited from IdentifiedObject (e.g., localName or name)?<br/>[Greg] Seems reasonable. We could check with Mike Daniels and Phillip Jones (also Scott Neumann and Chris Macqueen were involved with this) for their thoughts.<br/><br/>2.3) Question: Does Map need to inherit from Diagram (including kind attribute)? The usage of both Diagram and Map in Permit message indicates to me that they are different. It would maybe be better to introduce a common superclass (e.g., Presentation, or whatever) and make these two inherit from it. Also, all three shown associations from Diagram should be moved to the new superclass and properly renamed.<br/>2.4) Consider clearly documenting each class.<br/>[Greg] OK<br/><br/>2.5) Consider renaming GmlDiagramObject (e.g., GmlObject, GmlGeometry, GmlGraphicalObject, or whatever).<br/>[Greg] OK with me. Discuss with Phillip Jones.<br/><br/>3) DesignLocation<br/>It is said to be "a logical part of the design (e.g., pole and all equipment on a pole)". It is however not (subclass of) Location.<br/>3.a) I would rename the class, but don't know how... Maybe DesignPart or DesignComponent. Update association ends' names.<br/>3.b) If 1.a accepted, then rename DesignLocationCU the same way and update its doc and association end names.<br/>[Greg] We should discuss this with the Part 6 Team, particularly Chris Heineman & Ian Wells since they drove all of the modeling.<br/><br/>4) GmlDiagramObject<br/>It sounds strange to say GmlDiagramObject' IS-A Location; GmlDiagramObject rather HAS A Location. This just stroke me from this diagram, but will do more later, in GMLSupport package.<br/>[Greg] Discuss with Phillip Jones.<br/>