| <?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="-mAo18f36rZ1R98kpZX7HMw" |
| name="new_guideline,_K32gYAoBEdu0OeEVPFogVA" guid="-mAo18f36rZ1R98kpZX7HMw" changeDate="2008-03-11T11:28:25.929-0700" |
| version="1.0.0"> |
| <mainDescription><h3>
 |
| Design Mechanism Characteristics and Mapping
 |
| </h3>
 |
| <p>
 |
| Consider the analysis mechanism for <strong>persistence</strong>.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| There might be a need for many (2,000) small objects (200 bytes each) to be stored for a few seconds, with no need
 |
| for them to survive thereafter.
 |
| </li>
 |
| <li>
 |
| There might be a need for several very large objects to be stored permanently on disk for several months, never
 |
| updated, but with sophisticated means of retrieval.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| These objects require different support for persistency. The best option depends on the characteristics of the design
 |
| mechanism:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <b>In-memory storag</b><strong>e:</strong> For up to 1 Mb total (size x volume); very fast access for read, write,
 |
| update.
 |
| </li>
 |
| <li>
 |
| <b>Flash card</b><strong>:</strong> For up to 8 Mb; slow update and write access; moderate read access.
 |
| </li>
 |
| <li>
 |
| <b>Binary file</b><strong>:</strong> For 100 Kb to 200 Mb; slow update; slow read-and-write access.
 |
| </li>
 |
| <li>
 |
| <b>Database management system (DBMS)</b><strong>:</strong> For 100 Kb and upward (essentially no upper limit); even
 |
| slower update and read-and-write access.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Note that these speeds are rated as slow only as compared to in-memory storage. Obviously, in some environments,
 |
| caching can improve apparent access times. (See Figure 1.)
 |
| </p>
 |
| <blockquote>
 |
| <p align="center">
 |
| <img title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" height="221" alt="Mapping Analyis Mechanisms to Design Mechanisms and Classes" src="./resources/co_dmec1.gif" width="372" />
 |
| </p>
 |
| </blockquote>
 |
| <div align="center">
 |
| <p>
 |
| <strong>Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes</strong>
 |
| </p>
 |
| <h3 align="left">
 |
| Mapping Design Mechanisms to Implementation Mechanisms
 |
| </h3>
 |
| <p align="left">
 |
| The <b>persistence</b> design mechanisms can be mapped to implementation mechanisms as Figure 2 shows:
 |
| </p>
 |
| <p align="center">
 |
| <img title="Figure 2. How persistence design mechanism map to implementation mechanism" height="216" alt="How persistence design mechanism map to implementation mechanism" src="./resources/co_dmec2.gif" width="325" />
 |
| </p>
 |
| <p align="center">
 |
| <strong>Figure 2. How persistence design mechanism map to implementation mechanism</strong>
 |
| </p>
 |
| <p align="left">
 |
| A possible mapping between analysis mechanisms and design mechanisms. Dotted arrows mean "is specialized by,"
 |
| implying that the characteristics of the design mechanisms are inherited from the analysis mechanisms but that they
 |
| will be specialized and refined.
 |
| </p>
 |
| <p align="left">
 |
| After you have finished optimizing the mechanisms, the following mappings exist (see Figure 3):
 |
| </p>
 |
| <blockquote>
 |
| <p align="center">
 |
| <img title="Figure 3. Mapping structure after optimizing the mechanisms" height="110" alt="Illustration of mapping structure after optimizing the mechanisms" src="./resources/co_dmec3.gif" width="418" />
 |
| </p>
 |
| <p class="picturetext" align="center">
 |
| <strong>Figure 3. Mapping structure after optimizing the mechanisms</strong>
 |
| </p>
 |
| <p class="picturetext" align="left">
 |
| The design decisions for a client class in terms of mappings between mechanisms. The <font face="Courier New, Courier, mono">Flight</font> class needs two forms of persistency<strong>:</strong>
 |
| <strong>in-memory storage</strong>, implemented by a predefined library routine, and <strong>a
 |
| database,</strong> implemented with an off-the-shelf ObjectStorage product.
 |
| </p>
 |
| </blockquote>
 |
| <p align="left">
 |
| The map must be navigable in both directions to make it easy to determine client classes when changing
 |
| implementation mechanisms.
 |
| </p>
 |
| <h4 align="left">
 |
| Refining the mapping between design and implementation mechanisms
 |
| </h4>
 |
| </div>
 |
| <p>
 |
| Initially, the mapping between design mechanisms and implementation mechanisms is likely to be less than optimal, but
 |
| it will get the project running, identify unforeseen risks, and trigger further investigations and evaluations. As the
 |
| project continues and you gain more knowledge, you will need to refine the mapping.
 |
| </p>
 |
| <p>
 |
| Proceed iteratively to refine the mapping between design and implementation mechanisms. Eliminate redundant paths,
 |
| working both top-down and bottom-up.
 |
| </p>
 |
| <p>
 |
| <b>Working top-down:</b> When working top-down (from top to bottom), new and refined use-case realizations will put new
 |
| requirements on the necessary design mechanisms through the analysis mechanisms that you need. These new requirements
 |
| might uncover additional characteristics of a design mechanism, forcing a split between mechanisms. A compromise
 |
| between the system's complexity and its performance is also necessary:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Too many different design mechanisms make the system too complex.
 |
| </li>
 |
| <li>
 |
| Too few design mechanisms can create performance problems for implementation mechanisms that stretch the limits of
 |
| the reasonable ranges of the values of their characteristics.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| <b>Working bottom-up:</b> When working bottom-up (from bottom to top) and investigating the available implementation
 |
| mechanisms, you might find products that satisfy several design mechanisms at once, but force some adaptation or
 |
| repartitioning of your design mechanisms. You want to minimize the number of implementation mechanisms you use, but too
 |
| few of them can also lead to performance problems.
 |
| </p>
 |
| <p>
 |
| After you decide to use a DBMS to store class A objects, you might be tempted to use it to store all objects in the
 |
| system. This could be very inefficient or very cumbersome. Not all objects that require persistency need to be stored
 |
| in the DBMS. Some objects may be persistent, but one application may access them frequently, while other applications
 |
| access them only infrequently. A hybrid strategy, in which the object is read from the DBMS into memory and
 |
| periodically synchronized, may be the best approach.
 |
| </p>
 |
| <blockquote>
 |
| <p class="example">
 |
| <b>Example</b>
 |
| </p>
 |
| <p class="example">
 |
| A flight can be stored both in memory for fast access and in a DBMS for long-term persistency. However, this
 |
| triggers a need for a mechanism to synchronize both.
 |
| </p>
 |
| </blockquote>
 |
| <p>
 |
| It is not uncommon to have more than one design mechanism associated with a client class as a compromise between
 |
| different characteristics.
 |
| </p>
 |
| <p>
 |
| Because implementation mechanisms often come in bundles in off-the-shelf components (operating systems and middleware
 |
| products), some optimization based on cost, impedance mismatch, or uniformity of style needs to occur. Also, mechanisms
 |
| are often interdependent, which makes clear separation of services into design mechanisms difficult.
 |
| </p>
 |
| <blockquote>
 |
| <p class="example">
 |
| <b>Examples</b>
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The notification mechanism can be based on the inter-process communication mechanism.
 |
| </li>
 |
| <li>
 |
| The error reporting mechanism can be based on the persistency mechanism.
 |
| </li>
 |
| </ul>
 |
| </blockquote>
 |
| <p>
 |
| Refinement continues over the whole Elaboration phase, and is always a compromise between:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| An exact fit with the requirements of the clients of the design mechanism, in terms of the expected
 |
| characteristics.
 |
| </li>
 |
| <li>
 |
| The cost and complexity of having too many different implementation mechanisms to acquire and integrate.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The overall goal is always to have a simple, clean set of mechanisms that give conceptual integrity, simplicity, and
 |
| elegance to a large system.
 |
| </p>
 |
| <h3>
 |
| Describing Design Mechanisms
 |
| </h3>
 |
| <p>
 |
| As with analysis mechanisms, design mechanisms can be modeled using a collaboration, which may instantiate one or more
 |
| architectural or design patterns.
 |
| </p>
 |
| <blockquote>
 |
| <p>
 |
| <strong>Example: A persistence mechanism</strong>
 |
| </p>
 |
| <p>
 |
| This example uses an instance of a pattern for RDBMS-based persistency drawn from <a href="http://java.sun.com/products/jdbc/index.html" target="_blank"><u>Java&trade; Database Connectivity (JDBC)</u></a>.
 |
| Although we present the design here, JDBC supplies actual code for some of the classes. Therefore, it is a short
 |
| step from what is presented here to an implementation mechanism.
 |
| </p>
 |
| </blockquote>
 |
| <p>
 |
| Figure 4, titled <strong>JDBC: Static view,</strong> shows the classes (actually, the classifier roles) in the
 |
| collaboration.
 |
| </p>
 |
| <p align="center">
 |
| <img title="Figure 4. JDBC: Static View" height="382" alt="Diagram of the figure titled Static View: JDBC shows the classes (actually, the classifier roles) in the collaboration. " src="./resources/jdbc1.gif" width="571" />
 |
| </p>
 |
| <p align="center">
 |
| <strong>Figure 4. JDBC: Static view</strong>
 |
| </p>
 |
| <p align="left">
 |
| The yellow classes are the ones that were supplied. The others, in tan (<font face="Courier New, Courier, mono">myDBClass</font> and so on), were bound by the designer to create the mechanism.
 |
| </p>
 |
| <p align="left">
 |
| In a Java database class, a client will work with a <b>DBClass</b> to read and write persistent data. The <font face="Courier New, Courier, mono">DBClass</font> is responsible for accessing the JDBC database, using the
 |
| <b>DriverManager</b> class. Once a database <b>connection</b> is open, the <font face="Courier New, Courier, mono">DBClass</font> can then create SQL statements that will be sent to the underlying
 |
| RDBMS and executed using the <b>Statement</b> class. The <font face="Courier New, Courier, mono">Statement</font> class
 |
| is what communicates with the database. The result of the SQL query is returned in a <b>ResultSet</b> object.<span style="mso-spacerun: yes">&nbsp;</span>
 |
| </p>
 |
| <p align="left">
 |
| The <b>DBClass</b> is responsible for making another class instance persistent. It understands the OO-to-RDBMS mapping
 |
| and can interface with the RDBMS. The <font face="Courier New, Courier, mono">DBClass</font> flattens the object,
 |
| writes it to the RDBMS, and then reads the object data from the RDBMS and builds the object. Every class that is
 |
| persistent has a corresponding <font face="Courier New, Courier, mono">DBClass</font>.&nbsp;
 |
| </p>
 |
| <p align="left">
 |
| The <b>PersistentClassList</b> is used to return a set of persistent objects as a result of a database query, for
 |
| example: <font face="Courier New, Courier, mono">DBClass.read()</font>.
 |
| </p>
 |
| <p align="left">
 |
| A series of dynamic views follow, in Figures 5 thorough 9, to show how the mechanism actually works.
 |
| </p>
 |
| <p align="center">
 |
| <img title="Figure 5. JDBC: Initialize" height="146" alt="Diagram of JDBC: Initialize" src="./resources/jdbc2.gif" width="285" />
 |
| </p>
 |
| <p align="center">
 |
| <b>Figure5. JDBC: Initialize</b>
 |
| </p>
 |
| <p>
 |
| Initialization must occur before any persistent class can be accessed.
 |
| </p>
 |
| <p>
 |
| To initialize the connection to the database, the <font face="Courier New, Courier, mono">DBClass</font> must load the
 |
| appropriate driver by calling the <font face="Courier New, Courier, mono">DriverManager getConnection()</font>
 |
| operation with a URL, user, and password.
 |
| </p>
 |
| <p>
 |
| The operation <font face="Courier New, Courier, mono">getConnection()</font> attempts to establish a connection to the
 |
| given database URL. The driver manager attempts to select an appropriate driver from the set of registered JDBC
 |
| drivers.
 |
| </p>
 |
| <blockquote>
 |
| <p>
 |
| <strong>Parameters</strong>
 |
| </p>
 |
| <blockquote>
 |
| <p>
 |
| <b>URL</b><strong>:</strong> A database URL in the form <font face="Courier New, Courier, mono">jdbc:subprotocol:subname</font>. This URL is used to locate the actual
 |
| database server and is not Web-related, in this instance.
 |
| </p>
 |
| <p>
 |
| <b>user</b><strong>:</strong> The database user who is making the connection.
 |
| </p>
 |
| <p>
 |
| <b>pass</b><strong>:</strong> The user's password
 |
| </p>
 |
| </blockquote>
 |
| <p>
 |
| <strong>Returns</strong>
 |
| </p>
 |
| <blockquote>
 |
| <p>
 |
| A connection to the URL.
 |
| </p>
 |
| </blockquote>
 |
| </blockquote>
 |
| <p align="center">
 |
| <img title="Figure 6. JDBC: Create" height="253" alt="Diagram of JDBC: Crreate" src="./resources/jdbc3.gif" width="478" />
 |
| </p>
 |
| <p align="center">
 |
| <b>Figure 6. JDBC: Create</b>
 |
| </p>
 |
| <p align="left">
 |
| To create a new class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to create
 |
| the new class. The <font face="Courier New, Courier, mono">DBClass</font> creates a new instance of <font face="Courier New, Courier, mono">PersistentClass</font> with default values. The <font face="Courier New, Courier, mono">DBClass</font> then creates a new <font face="Courier New, Courier, mono">Statement</font> using the <font face="Courier New, Courier, mono">Connection class
 |
| createStatement()</font> operation. The <font face="Courier New, Courier, mono">Statement</font> runs, and the data is
 |
| added to the database.
 |
| </p>
 |
| <p align="center">
 |
| <img title="Figure 7. JDBC: Read" height="352" alt="Diagram of JDBC: Read" src="./resources/jdbc4.gif" width="600" />
 |
| </p>
 |
| <p align="center">
 |
| <b>Figure 7. JDBC: Read</b>
 |
| </p>
 |
| <p>
 |
| To read a persistent class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to
 |
| read. The <font face="Courier New, Courier, mono">DBClass</font> creates a new <font face="Courier New, Courier, mono">Statement</font> using the <font face="Courier New, Courier, mono">Connection class
 |
| createStatement()</font> operation. The Statement is executed, and the data is returned in a <font face="Courier New, Courier, mono">ResultSet</font> object. The <font face="Courier New, Courier, mono">DBClass</font>
 |
| then creates a new instance of the <font face="Courier New, Courier, mono">PersistentClass</font> and populates it with
 |
| the retrieved data. The data is returned in a collection object, an instance of the <font face="Courier New, Courier, mono">PersistentClassList</font> class.
 |
| </p>
 |
| <p>
 |
| <strong>Note:</strong>
 |
| </p>
 |
| <p>
 |
| The string passed to <font face="Courier New, Courier, mono">executeQuery()</font> is not necessarily exactly the same
 |
| string as the one passed into the <font face="Courier New, Courier, mono">read()</font>. The <font face="Courier New, Courier, mono">DBClass</font> will build the SQL query to retrieve the persistent data from the
 |
| database, using the criteria passed into the <font face="Courier New, Courier, mono">read()</font>. This is because it
 |
| is not useful for the client of the <font face="Courier New, Courier, mono">DBClass</font> to know the internal
 |
| structure of the database to create a valid query. This knowledge is encapsulated within <font face="Courier New, Courier, mono">DBClass</font>.
 |
| </p>
 |
| <p align="center">
 |
| <img title="Figure 8. JDBC: Update" height="255" alt="Diagram of JDBC: Update" src="./resources/jdbc5.gif" width="473" />
 |
| </p>
 |
| <p align="center">
 |
| <b>Figure 8. JDBC: Update</b>
 |
| </p>
 |
| <p>
 |
| To update a class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to update.
 |
| The <font face="Courier New, Courier, mono">DBClass</font> retrieves the data from the given <font face="Courier New, Courier, mono">PersistentClass</font> object, and creates a new <font face="Courier New, Courier, mono">Statement</font> using the <font face="Courier New, Courier, mono">Connection class
 |
| createStatement()</font> operation. Once the <font face="Courier New, Courier, mono">Statement</font> is built, the
 |
| database is updated with the new data from the class.
 |
| </p>
 |
| <p>
 |
| <strong>Remember:</strong> It is the job of the <font face="Courier New, Courier, mono">DBClass</font> to flatten the
 |
| <font face="Courier New, Courier, mono">PersistentClass</font> and write it to the database. That is why it must be
 |
| retrieved from the given <font face="Courier New, Courier, mono">PersistentClass</font> before creating the SQL <font face="Courier New, Courier, mono">Statement</font>.
 |
| </p>
 |
| <p>
 |
| <strong>Note:</strong>
 |
| </p>
 |
| <p>
 |
| In the above mechanism, the <font face="Courier New, Courier, mono">PersistentClass</font> must provide access routines
 |
| for all persistent data so that <font face="Courier New, Courier, mono">DBClass</font> can access them. This provides
 |
| external access to certain persistent attributes that would have been private otherwise. This is a price you have to
 |
| pay to pull the persistence knowledge out of the class that encapsulates the data.
 |
| </p>
 |
| <p align="center">
 |
| <img title="Figure 9. JDBC: Delete" height="255" alt="Diagram of JDBC: Delete" src="./resources/jdbc6.gif" width="473" />
 |
| </p>
 |
| <p align="center">
 |
| <b>Figure 9. JDBC: Delete</b>
 |
| </p>
 |
| <p align="left">
 |
| To delete a class, the persistency client asks the <font face="Courier New, Courier, mono">DBClass</font> to delete the
 |
| <font face="Courier New, Courier, mono">PersistentClass</font>. The <font face="Courier New, Courier, mono">DBClass</font> creates a new <font face="Courier New, Courier, mono">Statement</font>
 |
| using the <font face="Courier New, Courier, mono">Connection class createStatement()</font> operation. The <font face="Courier New, Courier, mono">Statement</font> is executed and the data is removed from the database.
 |
| </p>
 |
| <p align="left">
 |
| In the actual implementation of this design, you would make some decisions about the mapping of <font face="Courier New, Courier, mono">DBClass</font> to the persistent classes, such as having one <font face="Courier New, Courier, mono">DBClass</font> per persistent class and allocating them to appropriate packages.
 |
| These packages will depend on the supplied java.sql file (see <a href="http://java.sun.com/products/jdbc/index.jsp">JDBC: API Documentation</a>) package that contains the supporting
 |
| classes <font face="Courier New, Courier, mono">DriverManager, Connection, Statement</font>, and <font face="Courier New, Courier, mono">ResultSet</font>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
