| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-QklqSGB4aD07vUpfubpMJg" |
| name="new_guideline,_0SsecNr8EdyXE6np2_hUMA" guid="-QklqSGB4aD07vUpfubpMJg" changeDate="2008-02-14T05:06:27.531-0800" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| When applying visual modeling, you can use various techniques:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Identify the key perspectives:</strong> Focus on modeling the things that count. Few (if any) projects
 |
| benefit from modeling the entire design to a great level of detail. Make sure that you understand why you are
 |
| modeling something and who will benefit.
 |
| </li>
 |
| <li>
 |
| <strong>Communicate key architectural perspectives:</strong> Even if you choose to model very little&nbsp;of your
 |
| design, it is often advantageous to produce diagrams that communicate the key architectural aspects of the system.
 |
| Conveying the "big picture" to the rest of the team helps them understand the overall approach and develop cohesive
 |
| software.&nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Sketch the design:</strong> Not all models need to be detailed completely and presented in a software
 |
| modeling tool. It is often perfectly acceptable (if not desirable) to produce hand-drawn sketches on paper or on a
 |
| whiteboard when you are exploring and communicating the architecture and design with your team. You can use a
 |
| digital camera or an electronic whiteboard to capture these diagrams and share them. For many small projects, this
 |
| is often all you need. See <a href="http://www.agilemodeling.com/">http://www.agilemodeling.com/</a> for more
 |
| information.
 |
| </li>
 |
| <li>
 |
| <strong>Use a modeling tool as needed</strong>:&nbsp;If the team members are changing models throughout the
 |
| project, sharing patterns/structure, debugging design, describing behavior, etc., then static photos or paper will
 |
| become difficult to work with. The team may want to capture design in a software modeling tool. Other than
 |
| communicating the design to the team, another benefit of a such a tool is the&nbsp;generation of structural code
 |
| from the models. Many software development tools allow you to view the code as models, making it easier to
 |
| comprehend static and dynamic aspects of a complex code base.
 |
| </li>
 |
| <li>
 |
| <strong>Agree on a standard notation:</strong> In a team environment, it is important that others can understand
 |
| your diagrams without much explanation. Choosing a standard notation enables others to quickly comprehend your
 |
| diagrams without ambiguity. The Unified Modeling Language (UML) provides an industry-standard approach to software
 |
| modeling and is an example of a widely understood notation.
 |
| </li>
 |
| </ul>For more information, see <a class="elementLinkWithType" href="./../../../core.tech.common.extend_supp/guidances/concepts/visual_modeling_2C089766.html" guid="_0XY6UMlgEdmt3adZL5Dmdw">Concept: Visual Modeling</a>.<br /></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |