| <?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.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.2.0" xmi:id="-HJbvivaRmrZ6rdQcdFd78Q" |
| name="new_concept,_pLEGUNqGEdy88NBoQgfGyg" guid="-HJbvivaRmrZ6rdQcdFd78Q"> |
| <mainDescription><p>
 |
| Key abstractions are the key concepts and abstractions that the system needs to handle. They are those things that,
 |
| without which, you could not describe the system.
 |
| </p>
 |
| <p>
 |
| The requirements are good sources for key abstractions. These abstractions are often easily identified because they
 |
| represent things that are significant to the business. For example, Customer and Account are typical key abstractions
 |
| in the banking business.
 |
| </p>
 |
| <p>
 |
| Each key abstraction should have a short description.&nbsp; The are usually not described in detail as they will change
 |
| and evolve&nbsp;during the course of the project (as they are refined into actual design elements).&nbsp;
 |
| </p>
 |
| <p>
 |
| The value of defining the key abstractions (and any obvious relationships between them) is that they establish a common
 |
| understanding of the key concepts amongst the team, thereby enabling them to develop a&nbsp;coherant solution that
 |
| handles them consistently.&nbsp;
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
