OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/guidances/guidelines/example_design_mechanisms.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\example_design_mechanisms.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: example_design_mechanisms.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_4k_Hsg4LEduibvKwrGxWxA CRC: 2840279475 -->Example: Design Mechanisms<!-- END:presentationName,_4k_Hsg4LEduibvKwrGxWxA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_4k_Hsg4LEduibvKwrGxWxA CRC: 4165502524 -->Examples that show how to describe design mechanisms<!-- END:briefDescription,_4k_Hsg4LEduibvKwrGxWxA -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-mAo18f36rZ1R98kpZX7HMw CRC: 1100663635 --><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 <strong></strong>very large <strong></strong>
     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 height="221" title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" 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 height="216" title="Figure 2. How persistence design mechanism map to implementation mechanism" 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 height="110" title="Figure 3. Mapping structure after optimizing the mechanisms" alt="Illustration of mapping structure after optimizing the mechanisms" src="./resources/co_dmec3.gif" width="418" />
     </p>
     <p align="center" class="picturetext"><strong>Figure 3. Mapping structure
       after optimizing the mechanisms </strong></p>
     <p align="left" class="picturetext">The design decisions for a client class
       in terms of mappings between mechanisms. The Flight
       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 <strong></strong>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 (see <a class="elementLinkWithType"
     href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
     guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>).
 </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 <strong></strong><a
     href="http://java.sun.com/products/jdbc/index.html" target="_blank" ><u>Java&#8482;
     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. <strong></strong></p>
 <p align="center"> <img height="382" title="Figure 4. JDBC: Static View" 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 (myDBClass 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 DBClass is responsible for accessing the JDBC database, using the <b>DriverManager</b>
   class. Once a database <b>connection</b> is open, the DBClass can then create SQL statements that will be sent to the underlying RDBMS
   and executed using the <b>Statement</b> class. The Statement 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 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.&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: DBClass.read().
 </p>
 <p align="left"> A series of dynamic views follow, in Figures 5 thorough 9, to
   show how the mechanism actually works. <strong></strong></p>
 <p align="center"> <img height="146" title="Figure 5. JDBC: Initialize" 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 DBClass
   must load the appropriate driver by calling the DriverManager
   getConnection() operation with a URL, user, and password. </p>
 <p> 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.
 </p>
 <blockquote>
   <p> <strong>Parameters</strong></p>
   <blockquote>
     <p> <b>URL</b><strong>: </strong>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. </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 height="253" title="Figure 6. JDBC: Create" 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 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.</p>
 <p align="center"> <img height="352" title="Figure 7. JDBC: Read" 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 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. </p>
 <p> <strong>Note: </strong></p>
 <p>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.
 </p>
 <p align="center"> <img height="255" title="Figure 8. JDBC: Update" 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
   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. </p>
 <p> <strong>Remember: </strong>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.
 </p>
 <p> <strong>Note: </strong></p>
 <p>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.</p>
 <p align="center"> <img height="255" title="Figure 9. JDBC: Delete" 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 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. </p>
 <p align="left"> 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<strong> </strong>the supplied java.sql file (see <a href="http://java.sun.com/products/jdbc/index.jsp">JDBC:
   API Documentation</a>)<strong> </strong>package that contains the supporting
   classes DriverManager, Connection, Statement,
   and ResultSet. </p><!-- END:mainDescription,-mAo18f36rZ1R98kpZX7HMw -->
 </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\example_design_mechanisms.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: example_design_mechanisms.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_4k_Hsg4LEduibvKwrGxWxA CRC: 2840279475 -->Example: Design Mechanisms<!-- END:presentationName,_4k_Hsg4LEduibvKwrGxWxA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_4k_Hsg4LEduibvKwrGxWxA CRC: 4165502524 -->Examples that show how to describe design mechanisms<!-- END:briefDescription,_4k_Hsg4LEduibvKwrGxWxA -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-mAo18f36rZ1R98kpZX7HMw CRC: 1100663635 --><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 <strong></strong>very large <strong></strong>
	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 height="221" title="Figure 1. Mapping Analysis Mechanisms to Design Mechanisms and Classes" 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 height="216" title="Figure 2. How persistence design mechanism map to implementation mechanism" 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 height="110" title="Figure 3. Mapping structure after optimizing the mechanisms" alt="Illustration of mapping structure after optimizing the mechanisms" src="./resources/co_dmec3.gif" width="418" />
	</p>
	<p align="center" class="picturetext"><strong>Figure 3. Mapping structure
	after optimizing the mechanisms </strong></p>
	<p align="left" class="picturetext">The design decisions for a client class
	in terms of mappings between mechanisms. The Flight
	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 <strong></strong>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 (see <a class="elementLinkWithType"
	href="./../../../openup_basic/guidances/concepts/using_patterns,_0cr7cACrEdu8m4dIntu6jA.html"
	guid="_0cr7cACrEdu8m4dIntu6jA">Concept: Using Patterns</a>).
	</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 <strong></strong><a
	href="http://java.sun.com/products/jdbc/index.html" target="_blank" ><u>Java™
	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. <strong></strong></p>
	<p align="center"> <img height="382" title="Figure 4. JDBC: Static View" 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 (myDBClass 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 DBClass is responsible for accessing the JDBC database, using the <b>DriverManager</b>
	class. Once a database <b>connection</b> is open, the DBClass can then create SQL statements that will be sent to the underlying RDBMS
	and executed using the <b>Statement</b> class. The Statement 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"> </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 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.
	</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: DBClass.read().
	</p>
	<p align="left"> A series of dynamic views follow, in Figures 5 thorough 9, to
	show how the mechanism actually works. <strong></strong></p>
	<p align="center"> <img height="146" title="Figure 5. JDBC: Initialize" 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 DBClass
	must load the appropriate driver by calling the DriverManager
	getConnection() operation with a URL, user, and password. </p>
	<p> 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.
	</p>
	<blockquote>
	<p> <strong>Parameters</strong></p>
	<blockquote>
	<p> <b>URL</b><strong>: </strong>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. </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 height="253" title="Figure 6. JDBC: Create" 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 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.</p>
	<p align="center"> <img height="352" title="Figure 7. JDBC: Read" 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 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. </p>
	<p> <strong>Note: </strong></p>
	<p>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.
	</p>
	<p align="center"> <img height="255" title="Figure 8. JDBC: Update" 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
	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. </p>
	<p> <strong>Remember: </strong>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.
	</p>
	<p> <strong>Note: </strong></p>
	<p>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.</p>
	<p align="center"> <img height="255" title="Figure 9. JDBC: Delete" 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 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. </p>
	<p align="left"> 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<strong> </strong>the supplied java.sql file (see <a href="http://java.sun.com/products/jdbc/index.jsp">JDBC:
	API Documentation</a>)<strong> </strong>package that contains the supporting
	classes DriverManager, Connection, Statement,
	and ResultSet. </p><!-- END:mainDescription,-mAo18f36rZ1R98kpZX7HMw -->
	</body>
	</html>