| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-HQSI39vBrjpmQL1qHYOJtA" |
| name="new_checklist,_nnSXcD6SEduAL-bCqar_dg" guid="-HQSI39vBrjpmQL1qHYOJtA" version="1.0.0"> |
| <sections xmi:id="_sG8ZoD6SEduAL-bCqar_dg" name="Packages and Organization" guid="_sG8ZoD6SEduAL-bCqar_dg"> |
| <sectionDescription><ul>
 |
| <li> Is the package partitioning logical and consistent? Does it make sense 
 |
| to team members and stakeholders? </li>
 |
| <li> Do package names accurately describe the contents of the package and the 
 |
| role that they play in the architecture? Do they follow naming conventions? 
 |
| </li>
 |
| <li> Do public packages and interfaces provide a logically cohesive set of services? 
 |
| </li>
 |
| <li> Are all the contents of a package listed? Are the classes within a package 
 |
| cohesive? </li>
 |
| <li> Do package dependencies correspond to the dependencies of the contained 
 |
| classes? </li>
 |
| <li> Are there packages or classes within a package that can be separated into 
 |
| an independent or sub-package?<br />
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_tx6tsD6SEduAL-bCqar_dg" name="Views" guid="_tx6tsD6SEduAL-bCqar_dg"> |
| <sectionDescription><ul>
 |
| <li> Does each diagram help the designer reason about the design or communicate 
 |
| key design decisions to the team? </li>
 |
| <li> Are the relationships between diagrams clear when several diagrams are 
 |
| used to describe behavior? </li>
 |
| <li> Is it easy to navigate between related diagrams? </li>
 |
| <li> Does each diagram focus on a relevant perspective? For instance, does a 
 |
| set of diagrams show a single class and its direct relationships, rather than 
 |
| using&nbsp;one or two diagrams to show all classes? </li>
 |
| <li> Is each diagram complete, yet minimal? Does it show everything relevant 
 |
| to that view and nothing more? </li>
 |
| <li> Are the diagrams tidy and easy to interpret, with a minimum of clutter? 
 |
| </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_yeFh4D6SEduAL-bCqar_dg" name="UML" guid="_yeFh4D6SEduAL-bCqar_dg"> |
| <sectionDescription><ul>
 |
| <li> Does the visual model conform to UML standards so that all stakeholders 
 |
| can understand the model over time? (See the&nbsp;<a href="http://www.uml.org/" target="_blank">OMG 
 |
| UML Resource Page</a>&nbsp;for more information.)</li>
 |
| <li> Does the visual model conform to project- or organization-specific modeling 
 |
| standards? </li>
 |
| <li>Is the visual model internally consistent? For instance, if an object diagram 
 |
| shows a relationship between objects, does a corresponding relationship exist 
 |
| between the appropriate classes? </li>
 |
| <li> Does the name of each class clearly reflect the role that it plays? </li>
 |
| <li> Does each class offer the required behavior? </li>
 |
| <li> Is there at least one&nbsp;realization association defined for each interface? 
 |
| The realization may represent a third-party implementation of the subsystem. 
 |
| </li>
 |
| <li> Are&nbsp;there dependency associations from each subsystem to the interfaces 
 |
| that it uses? </li>
 |
| <li> Is each operation in a subsystem interface described in a sequence diagram 
 |
| or at least mapped directly to an operation in a class? </li>
 |
| <li> Does each class represent a single, well-defined abstraction? </li>
 |
| <li> Are generalization relationships used only to inherit definitions, not 
 |
| behavior (implementation)? In other words, is behavior shared through the 
 |
| use of association, aggregation, and containment relationships rather than 
 |
| generalization? </li>
 |
| <li> Are parent classes in generalization relationships abstract? Are the "leaf" 
 |
| classes in a generalization hierarchy the only concrete classes? </li>
 |
| <li> Are stereotypes used consistently and meaningfully? </li>
 |
| <li> Do&nbsp;state charts exist for classes with complex or restrictive state 
 |
| changes? </li>
 |
| <li> Do relationships have descriptive role or association names (one or the 
 |
| other, but not both) and&nbsp;correct multiplicities? </li>
 |
| <li> Are relationships between classes unidirectional whenever possible?<br />
 |
| &nbsp; </li>
 |
| </ul></sectionDescription> |
| </sections> |
| <sections xmi:id="_IsDY4D6TEduAL-bCqar_dg" name="Non-UML Visual Modeling" guid="_IsDY4D6TEduAL-bCqar_dg"> |
| <sectionDescription><ul>
 |
| <li> Are the semantics of the visual modeling language clearly defined, documented, 
 |
| and accessible to team members? The semantics should be meaningful to people 
 |
| who use the model. </li>
 |
| <li> Can the semantics of the modeling language be understood over time? Is 
 |
| the language documented well enough that team members can understand the model 
 |
| long after design decisions have been made? </li>
 |
| <li> Are team members and stakeholders trained in the modeling language being 
 |
| used? </li>
 |
| <li> Does the visual model conform to the semantics of the visual modeling language? 
 |
| In other words, are the meanings of&nbsp;the symbols in the diagrams&nbsp;consistent 
 |
| across the model and the diagrams?&nbsp; </li>
 |
| </ul></sectionDescription> |
| </sections> |
| </org.eclipse.epf.uma:ContentDescription> |