<?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.3/uma.ecore" rmc:version="7.1.0" epf:version="1.0.0" xmi:id="-mAo18f36rZ1R98kpZX7HMw" name="new_guideline,_K32gYAoBEdu0OeEVPFogVA" guid="-mAo18f36rZ1R98kpZX7HMw" changeDate="2006-07-10T15:11:18.051-0700" version="1.0.0">
  <mainDescription>&lt;h3&gt; Design 
  Mechanism Characteristics and Mapping&lt;/h3&gt;
&lt;p&gt; Consider the analysis mechanism for &lt;strong&gt;persistence&lt;/strong&gt;. &lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt; 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. &lt;/li&gt;
  &lt;li&gt; There might be a need for several &lt;strong&gt;&lt;/strong&gt;very large &lt;strong&gt;&lt;/strong&gt; 
    objects to be stored permanently on disk for several months, never updated, 
    but with sophisticated means of retrieval. &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt; These objects require different support 
  for persistency. The best option depends on the characteristics 
  of the design mechanism:&lt;/p&gt;
&lt;ul&gt;
    
  &lt;li&gt; &lt;b&gt;In-memory storag&lt;/b&gt;&lt;strong&gt;e: &lt;/strong&gt;For up to 1 Mb total (size x 
    volume); very fast access for read, write, update. &lt;/li&gt;
  &lt;li&gt; &lt;b&gt;Flash card&lt;/b&gt;&lt;strong&gt;:&lt;/strong&gt; For up to 8 Mb; slow update and write 
    access; moderate read access. &lt;/li&gt;
  &lt;li&gt; &lt;b&gt;Binary file&lt;/b&gt;&lt;strong&gt;:&lt;/strong&gt; For 100 Kb to 200 Mb; slow update; 
    slow read-and-write access. &lt;/li&gt;
  &lt;li&gt; &lt;b&gt;Database management system (DBMS)&lt;/b&gt;&lt;strong&gt;: &lt;/strong&gt;For 100 Kb and 
    upward (essentially no upper limit); even slower update and read-and-write 
    access. &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt; 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.)&lt;/p&gt;
&lt;blockquote&gt;
    
  &lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;221&quot; title=&quot;Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes&quot; alt=&quot;Mapping Analyis Mechanisms to Design Mechanisms and Classes&quot; src=&quot;./resources/co_dmec1.gif&quot;
        width=&quot;372&quot; /&gt; &lt;/p&gt;
&lt;/blockquote&gt;
&lt;div align=&quot;center&quot;&gt;
  &lt;p&gt;&lt;strong&gt;Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes&lt;/strong&gt;&lt;/p&gt;
  &lt;h3 align=&quot;left&quot;&gt;Mapping Design Mechanisms to Implementation Mechanisms &lt;/h3&gt;
  &lt;p align=&quot;left&quot;&gt; The &lt;b&gt;persistence&lt;/b&gt; design mechanisms can be mapped to implementation 
    mechanisms as Figure 2 shows: &lt;/p&gt;
  &lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;216&quot; title=&quot;Figure 2. How persistence design mechanism map to implementation mechanism&quot; alt=&quot;How persistence design mechanism map to implementation mechanism&quot; src=&quot;./resources/co_dmec2.gif&quot; width=&quot;325&quot; /&gt;&lt;/p&gt;
  &lt;p align=&quot;center&quot;&gt;&lt;strong&gt;Figure 2. How persistence design 
    mechanism map to implementation mechanism&lt;/strong&gt; &lt;/p&gt;
  &lt;p align=&quot;left&quot;&gt;A possible mapping between analysis mechanisms and design mechanisms. 
    Dotted arrows mean &quot;is specialized by,&quot; implying that the characteristics 
    of the design mechanisms are inherited from the analysis mechanisms but that 
    they will be specialized and refined. &lt;/p&gt;
  &lt;p align=&quot;left&quot;&gt; After you have finished optimizing the mechanisms, the following 
    mappings exist (see Figure 3): &lt;/p&gt;
  &lt;blockquote&gt; 
    &lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;110&quot; title=&quot;Figure 3. Mapping structure after optimizing the mechanisms&quot; alt=&quot;Illustration of mapping structure after optimizing the mechanisms&quot; src=&quot;./resources/co_dmec3.gif&quot; width=&quot;418&quot; /&gt; 
    &lt;/p&gt;
    &lt;p align=&quot;center&quot; class=&quot;picturetext&quot;&gt;&lt;strong&gt;Figure 3. Mapping structure 
      after optimizing the mechanisms &lt;/strong&gt;&lt;/p&gt;
    &lt;p align=&quot;left&quot; class=&quot;picturetext&quot;&gt;The design decisions for a client class 
      in terms of mappings between mechanisms. The Flight 
      class needs two forms of persistency&lt;strong&gt;:&lt;/strong&gt; &lt;strong&gt;in-memory 
      storage&lt;/strong&gt;, implemented by a predefined  
      library routine, and &lt;strong&gt;a database,&lt;/strong&gt; implemented with an off-the-shelf 
      ObjectStorage product. &lt;/p&gt;
  &lt;/blockquote&gt;
  &lt;p align=&quot;left&quot;&gt; The map must be navigable in both directions to make it easy 
    to determine client classes when changing implementation mechanisms. &lt;/p&gt;
  &lt;h4 align=&quot;left&quot;&gt;Refining 
    the mapping between design and implementation mechanisms &lt;/h4&gt;
&lt;/div&gt;
&lt;p&gt; 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. 
&lt;/p&gt;
&lt;p&gt; Proceed iteratively to refine the mapping between design and implementation 
  mechanisms. Eliminate &lt;strong&gt;&lt;/strong&gt;redundant 
  paths, working both top-down and bottom-up. &lt;/p&gt;
&lt;p&gt; &lt;b&gt;Working top-down: &lt;/b&gt;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: &lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Too many different design mechanisms make the system too complex.
    &lt;/li&gt;
  &lt;li&gt; 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. &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt; &lt;b&gt;Working bottom-up: &lt;/b&gt;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. &lt;/p&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;blockquote&gt;
  &lt;p class=&quot;example&quot;&gt; &lt;b&gt;Example&lt;/b&gt; &lt;/p&gt;
  &lt;p class=&quot;example&quot;&gt; 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. &lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt; It is not uncommon to have more than one design mechanism associated with 
  a client class as a compromise between different characteristics. &lt;/p&gt;
&lt;p&gt; 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. &lt;/p&gt;
&lt;blockquote&gt; 
  &lt;p class=&quot;example&quot;&gt; &lt;b&gt;Examples&lt;/b&gt; &lt;/p&gt;
  &lt;ul&gt;
    &lt;li&gt; The notification mechanism can be based on the inter-process communication 
      mechanism. &lt;/li&gt;
    &lt;li&gt; The error reporting mechanism can be based on the persistency mechanism. 
    &lt;/li&gt;
  &lt;/ul&gt;
&lt;/blockquote&gt;
&lt;p&gt; Refinement continues over the whole Elaboration phase, and is always a compromise 
  between: &lt;/p&gt;
&lt;ul&gt;
    
  &lt;li&gt; An exact fit with the requirements of the clients of the design mechanism, 
    in terms of the expected characteristics. &lt;/li&gt;
    &lt;li&gt;
        The cost and complexity of having too many different implementation mechanisms to acquire and integrate.
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt; The overall goal is always to have a simple, clean set of mechanisms that 
  give conceptual integrity, simplicity, and elegance to a large system. &lt;/p&gt;
&lt;h3&gt; Describing Design Mechanisms &lt;/h3&gt;
&lt;p&gt;
    As with analysis mechanisms, design mechanisms can be modeled using a collaboration, which may instantiate one or more
    architectural or design patterns (see &lt;a class=&quot;elementLinkWithType&quot;
    href=&quot;./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html&quot;
    guid=&quot;_0cr7cACrEdu8m4dIntu6jA&quot;&gt;Concept: Using Patterns&lt;/a&gt;).
&lt;/p&gt;
&lt;blockquote&gt;
  &lt;p&gt; &lt;strong&gt;Example: A persistence mechanism &lt;/strong&gt;&lt;/p&gt;
  &lt;p&gt; This example uses an instance of a pattern for RDBMS-based persistency drawn 
    from &lt;strong&gt;&lt;/strong&gt;&lt;a 
    href=&quot;http://java.sun.com/products/jdbc/index.html&quot; target=&quot;_blank&quot; &gt;&lt;u&gt;Java&amp;#8482; 
    Database Connectivity (JDBC)&lt;/u&gt;&lt;/a&gt;. 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. &lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt; Figure 4, titled &lt;strong&gt; JDBC: Static view,&lt;/strong&gt; shows the classes (actually, 
  the classifier roles) in the collaboration. &lt;strong&gt;&lt;/strong&gt;&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;382&quot; title=&quot;Figure 4. JDBC: Static View&quot; alt=&quot;Diagram of the figure titled Static View: JDBC shows the classes (actually, the classifier roles) in the collaboration. &quot; src=&quot;./resources/jdbc1.gif&quot; width=&quot;571&quot; /&gt;&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;strong&gt;Figure 4. JDBC: Static view &lt;/strong&gt;&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; The yellow classes are the ones that were supplied. The others, 
  in tan (myDBClass and so on), 
  were bound by the designer to create the mechanism. &lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; In a Java database class, a client will work with a &lt;b&gt;DBClass&lt;/b&gt; 
  to read and write persistent data. The DBClass is responsible for accessing the JDBC database, using the &lt;b&gt;DriverManager&lt;/b&gt; 
  class. Once a database &lt;b&gt;connection&lt;/b&gt; is open, the DBClass can then create SQL statements that will be sent to the underlying RDBMS 
  and executed using the &lt;b&gt;Statement&lt;/b&gt; class. The Statement class is what communicates with the database. The result of the SQL query 
  is returned in a &lt;b&gt;ResultSet&lt;/b&gt; object.&lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt; 
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; The &lt;b&gt;DBClass&lt;/b&gt; is responsible for making another class instance 
  persistent. It understands the OO-to-RDBMS mapping and can interface with the 
  RDBMS. The DBClass 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 DBClass.&amp;nbsp; 
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; The &lt;b&gt;PersistentClassList&lt;/b&gt; is used to return a set of persistent 
  objects as a result of a database query, for example: DBClass.read(). 
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; A series of dynamic views follow, in Figures 5 thorough 9, to 
  show how the mechanism actually works. &lt;strong&gt;&lt;/strong&gt;&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;146&quot; title=&quot;Figure 5. JDBC: Initialize&quot; alt=&quot;Diagram of JDBC: Initialize&quot; src=&quot;./resources/jdbc2.gif&quot; width=&quot;285&quot; /&gt; 
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;b&gt;Figure5. JDBC: Initialize&lt;/b&gt; &lt;/p&gt;
&lt;p&gt;
    Initialization must occur before any persistent class can be accessed.
&lt;/p&gt;
&lt;p&gt; To initialize the connection to the database, the DBClass 
  must load the appropriate driver by calling the DriverManager 
  getConnection() operation with a URL, user, and password. &lt;/p&gt;
&lt;p&gt; The operation getConnection() 
  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. 
&lt;/p&gt;
&lt;blockquote&gt; 
  &lt;p&gt; &lt;strong&gt;Parameters&lt;/strong&gt;&lt;/p&gt;
  &lt;blockquote&gt; 
    &lt;p&gt; &lt;b&gt;URL&lt;/b&gt;&lt;strong&gt;: &lt;/strong&gt;A database URL in the form jdbc:subprotocol:subname. 
      This URL is used to locate the actual database server and is not Web-related, 
      in this instance. &lt;/p&gt;
    &lt;p&gt; &lt;b&gt;user&lt;/b&gt;&lt;strong&gt;: &lt;/strong&gt;The database user who is making the connection.&lt;/p&gt;
    &lt;p&gt; &lt;b&gt;pass&lt;/b&gt;&lt;strong&gt;:&lt;/strong&gt; The user's password &lt;/p&gt;
  &lt;/blockquote&gt;
  &lt;p&gt; &lt;strong&gt;Returns&lt;/strong&gt;&lt;/p&gt;
  &lt;blockquote&gt;
    &lt;p&gt; A connection to the URL.&lt;/p&gt;
  &lt;/blockquote&gt;
&lt;/blockquote&gt;
&lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;253&quot; title=&quot;Figure 6. JDBC: Create&quot; alt=&quot;Diagram of JDBC: Crreate&quot; src=&quot;./resources/jdbc3.gif&quot; width=&quot;478&quot; /&gt; 
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;b&gt;Figure 6. JDBC: Create&lt;/b&gt; &lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; To create a new class, the persistency client asks the DBClass 
  to create the new class. The DBClass 
  creates a new instance of PersistentClass with default values. The DBClass 
  then creates a new Statement using the Connection class createStatement()
  operation. The Statement runs, 
  and the data is added to the database.&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;352&quot; title=&quot;Figure 7. JDBC: Read&quot; alt=&quot;Diagram of JDBC: Read&quot; src=&quot;./resources/jdbc4.gif&quot; width=&quot;600&quot; /&gt; 
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;b&gt;Figure 7. JDBC: Read&lt;/b&gt; &lt;/p&gt;
&lt;p&gt; To read a persistent class, the persistency client asks the DBClass 
  to read. The DBClass creates 
  a new Statement using the Connection class createStatement() operation. The Statement is executed, and the 
  data is returned in a ResultSet object. The DBClass then creates 
  a new instance of the PersistentClass and populates it with the retrieved data. The data is returned in a collection 
  object, an instance of the PersistentClassList class. &lt;/p&gt;
&lt;p&gt; &lt;strong&gt;Note: &lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;The string passed to executeQuery() 
  is not necessarily exactly the same string as the one passed into the 
  read(). The DBClass 
  will build the SQL query to retrieve the persistent data from the database, 
  using the criteria passed into the . 
  This is because it is not useful for the client of the DBClass 
  to know the internal structure of the database to create a valid query. This 
  knowledge is encapsulated within DBClass. 
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;255&quot; title=&quot;Figure 8. JDBC: Update&quot; alt=&quot;Diagram of JDBC: Update&quot; src=&quot;./resources/jdbc5.gif&quot; width=&quot;473&quot; /&gt; 
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;b&gt;Figure 8. JDBC: Update&lt;/b&gt; &lt;/p&gt;
&lt;p&gt; To update a class, the persistency client asks the 
  DBClass to update. The DBClass 
  retrieves the data from the given PersistentClass object, and creates a new Statement 
  using the Connection class createStatement() 
  operation. Once the Statement 
  is built, the database is updated with the new data from the class. &lt;/p&gt;
&lt;p&gt; &lt;strong&gt;Remember: &lt;/strong&gt;It is the job of the DBClass 
  to flatten the PersistentClass and 
  write it to the database. That is why it must be retrieved from the given PersistentClass 
  before creating the SQL Statement. 
&lt;/p&gt;
&lt;p&gt; &lt;strong&gt;Note: &lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;In the above mechanism, the PersistentClass 
  must provide access routines for all persistent data so that 
  DBClass 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.&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;img height=&quot;255&quot; title=&quot;Figure 9. JDBC: Delete&quot; alt=&quot;Diagram of JDBC: Delete&quot; src=&quot;./resources/jdbc6.gif&quot; width=&quot;473&quot; /&gt; 
&lt;/p&gt;
&lt;p align=&quot;center&quot;&gt; &lt;b&gt;Figure 9. JDBC: Delete&lt;/b&gt;&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; To delete a class, the persistency client asks the DBClass to delete the PersistentClass. 
  The DBClass creates a new Statement  using the Connection class createStatement() 
  operation. The Statement is 
  executed and the data is removed from the database. &lt;/p&gt;
&lt;p align=&quot;left&quot;&gt; In the actual implementation of this design, you would make some 
  decisions about the mapping of DBClass 
  to the persistent classes, such as having one DBClass 
  per persistent class and allocating them to appropriate packages. These packages 
  will depend on&lt;strong&gt; &lt;/strong&gt;the supplied java.sql file (see &lt;a href=&quot;http://java.sun.com/products/jdbc/index.jsp&quot;&gt;JDBC: 
  API Documentation&lt;/a&gt;)&lt;strong&gt; &lt;/strong&gt;package that contains the supporting 
  classes DriverManager, Connection, Statement, 
  and ResultSet. &lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>