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