OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/guidelines/abstract_away_complexity_vm.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\guidelines\abstract_away_complexity_vm.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: abstract_away_complexity_vm.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-OcMsciNn-UtD9fTHj26LGA CRC: 65919989 --><h4>
     Model key perspectives
 </h4>
 <p>
     Modeling helps raise the level of abstraction because you simplify complex ideas and represent them visually, as
     illustrations. Good models can convey information that helps the team visualize, specify, construct, and document
     software. The Unified Modeling Language (UML) provides an industry-standard approach to software modeling.
 </p>
 <p>
     When applying this strategy, 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 is an example of a widely understood notation.
     </li>
 </ul><!-- END:mainDescription,-OcMsciNn-UtD9fTHj26LGA -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\guidelines\abstract_away_complexity_vm.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: abstract_away_complexity_vm.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-OcMsciNn-UtD9fTHj26LGA CRC: 65919989 --><h4>
	Model key perspectives
	</h4>
	<p>
	Modeling helps raise the level of abstraction because you simplify complex ideas and represent them visually, as
	illustrations. Good models can convey information that helps the team visualize, specify, construct, and document
	software. The Unified Modeling Language (UML) provides an industry-standard approach to software modeling.
	</p>
	<p>
	When applying this strategy, 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 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.
	</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>: 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 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 is an example of a widely understood notation.
	</li>
	</ul><!-- END:mainDescription,-OcMsciNn-UtD9fTHj26LGA -->
	</body>
	</html>