1. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Object Oriented Analysis and Design Using the UML Version 4.2 Architectural Design Patterns

2. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Analysis, Design, and Implementation Mechanisms  We know about (in RUP) Analysis Mechanisms – which are really Non Functional Requirtements…  In Design, the ‘conceptual’ is morphed into a general technology.  In Implementation, these ‘general technologies’ are mapped into quite specific technologies.  E.g. Relational Data Base  Oracle; MySQL, etc.  Choice of Design Mechanism constrained by availability in implementation environment.  If we plan to use a relational databases and have one or two ‘on site,’ then this is a real constraint and influences how we accommodate such requirements.

3. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Design/Implementation Mechanisms AnalysisDesignImplementation Remote Method Invocation (RMI) Persistency Analysis Mechanism (Conceptual) Design Mechanism (Concrete) Implementation Mechanism (Actual) (often constrained by Availability) OODBMS RDBMSJDBC ObjectStore Java x.x from Sun Legacy Data New Data Distribution Persistency A ‘what’ was needed to solve a problem:

4. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Design Mechanisms  Design mechanism assume  some details of the implementation environment,  but not tied to a specific implementation  For ‘persistency’ our design mechanisms might include:  RDBMS,  OODBMS,  in-memory storage, …  For ‘security’ there will be some other design mechanisms that address…

5. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Implementation Mechanisms  Implementation mechanisms are used during implementation.  They are bound to a certain technology, implementation language, vendor, technique, etc.  Examples:  actual programming language,  COTS products,  Database (Oracle, Sybase, SQL Server…);  Inter process communication/distribution technology (COM/DCOM, CORBA), etc.   We will use JDBC in our examples ahead – very detailed!

6. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Documenting Architectural Mechanisms  Architectural Mechanisms may be treated as patterns.  Perhaps some ‘trusted’ way or mechanism (that is, a series of communicating classes or pattern of classes with specific responsibilities) for accommodating a specific requirement. Structural AspectBehavioral Aspect Pattern Name Template Parameters

7. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Documenting Architectural Mechanisms – more  Most of these requirements are:  Identified in analysis - like, persistence, or later as some kind of design pattern (observer, singleton, adaptor…)  have both a structural and behavioral aspect. (accompanied by rules of use – as indicated in the last slide)  Structural part - classes whose instances and their relationships implement the mechanism These constitute the ‘static view.’ Often class diagram.  Behavioral part shows how the instances collaborate to implement the mechanism – ‘dynamic view.’ Shown as an interaction diagram in many cases

8. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Documenting Architectural Mechanisms – more**  Architect must:  decide on the pattern,  validate these by building (or integrating them), and  verify they do the job.  The architect must consistently impose these mechanisms on rest of system design.  The architect must ensure that these approaches are consistently used throughout

9. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Documenting the Architectural Mechanisms - more  Most organizations have / specify a Software Architecture Document (SAD) and a Design Guidelines Document  organizational assets independent of the project particulars  These documents represents the collected reusable design wisdom.  In fact, a structural and behavioral model may already exist.  The Software Architecture Document (SAD) captures the ‘actual’ architectural design choices for a system based on non- functional / functional requirements.  The Design Guidelines is a ‘how to’ document a design not yet done. (for your project) in a very specific way.

10. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS (design)  JDBC (implementation)  Show both design and implementation patterns  Persistent data objects must be mapped into a storage structure.  Several slides (static view - classes) upcoming:  Design: demonstrates the pattern of use of the persistency mechanism chosen for the RDBMS classes  Implementation: Here in our example: JDBC.

11. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS and JDBC (1 of 2)  For JDBC, a client (entity) class (our job) will work with a DBClass to read and write persistent data for objects of that class.  Every class that has persistent objects (e.g. book, student, country, etc.) will have a corresponding DBClass, and all persistent objects from this persistent class are stored in one single table. (This makes sense.)  (Several ways to actually do this. See readings…)  The DBClass - for objects of this class requiring persistence - is responsible for accessing the JDBC database using a DriverManager class.  (Note: DriverManager is found in java.sql)

12. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS and JDBC (2 of 2)  Once the DBClass gets a connection via Driver Manager (found in java.sql),  DBClass can then create SQL statements (via Connection Class – found in java.sql)  The SQL statement will be sent to the underlying Statement Class object (found in java.sql) and executed  The Statement object “talks” the database.  Result of the SQL query is returned in a ResultSet object (found in java.sql).

13. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Summary of ‘cooperation’ for this pattern  So we have a DBClass for the desired persistent object – Driver Manager for connection, Connection object to build an SQL statement, to Statement for execution, to Result Set for results.

14. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Performance in Statement Class – read on your own  For performance optimization, there is also the notion of PreparedStatements, (which ‘inherits’ from Statement).  The basic idea with PreparedStatement is that most of the SQL can be precompiled, and then only the small amount of changing data needs to be passed in for each call.  This is a performance optimization and is not that important from a mechanisms point of view. In this model, we did not include PreparedStatements at all.  Let’s walk through the mechanisms diagrams at a high level. Do not get hung up on the mechanism details. Will look more closely at the RDBMS mechanism in Subsystem Design.

15. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC ResultSet getString() : string (from java.sql) Connection createStatement() : Statement (from java.sql) Statement executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int (from java.sql) DriverManager getConnection(url, user, pass) : Connection (from java.sql) DBClass create() : PersistentClass read(searchCriteria : string) : PersistentClassList update(c : PersistentClass) delete(c : PersistentClass) > 1 1 PersistencyClient (from SamplePersistency Client) > PersistentClass getData() setData() command() new() (from SamplePersistentClass) > PersistentClassList new() add(c: PersistentClass) (from SamplePersistentClass) > 0..* 1 Roles to be filled by the designer applying the mechanism Uses DriverManager to establish connection Then, DBClass builds statements which it transmits to Connection; Connection builds ‘real’ Statement for execution. Role classes must be built by designer. Connection made to Database here and a connection object is returned to DBClass. Note: UML dependency arrows.

16. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC – continuing: DBClass  DBClass - responsible for making objects persistent.  It ‘understands’ the OO-to-RDBMS mapping.  This means that the DBClass possesses the behaviors (methods) to interface with the RDBMS.  The DBClass responsible for ‘writing’ an object to the RDBMS and ‘reading’ an object data from the RDBMS and building objects.  (Note: DBClass does not directly do this; is ‘responsible.’)  (Note: DBClass is a control class.  (N.B. Recall: Every class whose objects are persistent will have a corresponding DBClass.)

17. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC. DBClass - more  A PersistentClassList object is returned from a DBClass.read(). (will show ahead)  The persistent class list object is used to set up an aggregate of persistent class objects of type Persistent Class. (See previous figure)  Will contain a number of objects of the persistent class.  Consider the need to:  Initialize, Read, Create, Update, Delete  (Note: The > stereotype is used for anything that should be regarded as a placeholder for the actual design element to be supplied by the developer.  This convention makes it easier to apply the mechanism because easier to recognize what the designer is to supply.)

18. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC: Initialize : DBClass : DriverManager 1. getConnection(url, user, pass). Initialization must occur before any persistent objects can be accessed.. To initialize the connection to the database, DBClass must load the appropriate driver by calling DriverManager.getConnection() operation with a URL, user, and password.. getConnection() attempts to establish a connection to the given database URL.. (The DriverManager attempts to select an appropriate driver from the set of registered JDBC drivers.) DriverManager then returns a connection object. Parameters: url: A database url of the form jdbc:subprotocol:subname. URL used to locate the actual database server and is not Web-related in this instance. user: The database user on whose behalf the Connection is being made password: The user's password. Returns: a Connection object to the URL (The objects to be replaced by concrete objects by the designer applying the mechanism shown in yellow.) (That is, you program this. These Have the stereotype ‘role.’) Note that DriverManager is available via the Java.sql API. But the software designer must develop the DBClass if it is not already available for objects of the client class.

19. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC: Create : Connection : Statement : PersistencyClient : DBClass : :PersistentClass 1. create( ) 1.1. new() 1.3. createStatement( ) 1.4. executeUpdate(String) 1.2. getData( ) (Lot of detail here…needed in order to better understand the persistency mechanism.). To create a new class, the persistency client asks the DBClass to create the new class.. DBClass creates a reference to a PersistentClass. DBClass creates a new object via new().. DBClass then retrieves (getData) the ‘object’. The DBClass ‘builds’ the object and serializes it (into a String) and then sends a message (createStatement()) to the Connection object which returned by DriverManager earlier.. createStatement() returns a Statement object to DBClass, which in turn sends the executeUpdate() with the (now) string to the Statement object, which executes the SQL statement statement, will add the string to the database and returns an integer indicating success (or not)

20. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC: Read (two info…)  To read a persistent class object, the persistency client asks the DBClass to read (searchCriteria…).  The DBClass sends message to Connection object’s method createStatement() which creates a new Statement object, as before.   DBClass sends message to Statement.executeQuery(sql: String) with the appropriate SQL string to ‘select’ the correct data  executeQuery() returns a ResultSet object DBClass.  DBClass can now get the returned String retrieved via the getString() from the ResultSet object. But note that the data retrieved is a String - not an object or series of objects.  The procedure that follows (see next sequence diagram) is that repeatedly retrieve a string, create a new instance of an object, and populate this new object. We will continue to do so until we have exhausted each string and have created a number of persistent objects – the aggregate of persistent objects..  The data is returned in a collection object, an instance of the PersistentClassList

21. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 More on Read…Very important. Read on your own!  Note: The string ultimately passed to executeQuery() is NOT the exact same string as the one passed into the read() from the client.  The DBClass will build the SQL query to retrieve the persistent data from the database, using the criteria passed into the read().  This is because we do not want the client of the DBClass to have the knowledge of the internals of the database.  This knowledge is encapsulated within DBClass.

22. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC: Read : Connection : Statement : ResultSet : PersistencyClient : DBClass : PersistentClass : PersistentClassList 1. read(string) 1.1. createStatement( ) 1.2. executeQuery(string) 1.4. new() 1.5. getString( ) 1.6. setData( ) called for each attribute in the class returns a Statement object 1.3. new( ) Create a list to hold all retrieved data 1.7. add(PersistentClass) Add the retrieved course offering to the list to be returned Repeat these operations for each element returned from the executeQuery() command. The PersistentClassList is loaded with the data retrieved from the database. The criteria used to access data for the persistent class Note the loop! Spend some time on this diagram

23. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC: Update (one info)  To update an object, the persistency client sends a message to DBClass via update().  The DBClass is retrieves a persistent object  (next sequence diagram)  DBClass obtains a Statement object returned from Connection class when the Connection object is sent the message createStatement().  (See Statement object in sequence diagram in next slide) Once the object is serialized into a String, the executeUpdate(string) is executed via Statement.executeUpdate(String) message. (Remember: It is the DBClass’s job to “flatten” the PersistentClass object and write it to the database.)

24. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC: Update : DBClass : PersistencyClient : PersistentClass : Connection : Statement 1. update(PersistentClass) 1.2. createStatement( ) 1.1. getData( ) 1.3. executeUpdate(string) execute SQL statement

25. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Example: Persistency: RDBMS: JDBC: Delete : PersistencyClient : DBClass : Connection : Statement 1. delete(PersistentClass) 1.1. createStatement( ) 1.2. executeUpdate(string) execute SQL statement (not to spend too much time on this one because it will not be applied later on…). To delete an object, persistency client asks the DBClass to delete the object.. DBClass is passed a new Statement object when Connection class createStatement() is invoked.. The Statement.executeUpdate(string) is executed (this is an SQL statement) and the data is removed from the database.

26. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Summary of Steps to Implement the RDBMS Persistency Mechanism (JDBC)  Provide access to the class libraries needed to implement JDBC  Import java.sql package (contains the design elements that support the RDBMS persistency mechanism. It will be depended upon by the packages in which the DBClasses are placed.  Create necessary DBClasses – one per persistent class  Once created, incorporate DBClasses into the design  Allocated to a package/layer – likely middleware  Add relationships from persistency clients to the DBClasses  More…..

27. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 Incorporating JDBC: Steps – Summary…  Create/Update interaction diagrams that describe:  Database initialization  Persistent class access: Create, Read, Update, Delete  Interaction diagrams used to verify all required database functionality is supported by the design elements.  The sample interaction diagrams provided for the persistency architectural mechanisms during Architectural Design should serve as a starting point for the specific interaction diagrams defined in detailed design. (Note: specific algorithms were not given.)  Definition of the actual DBClasses and development of the detailed interaction diagrams - deferred until detailed design.

28. OOAD Using the UML - Architectural Design, v 4.2 Copyright  1998-1999 Rational Software, all rights reserved 34 java.sql ResultSet (from java.sql) Connection (from java.sql) Statement (from java.sql) DriverManager (from java.sql) Sample Persistency Client Package Example: Incorporating JDBC Access must be provided to the java.sql package that contains the design elements that support the RDBMS persistency mechanism. The packages where the created DBClasses reside will need to have a dependency on the java.sql package. (Remember, there is a DBClass for every persistent class.) The creation of the DB classes and the decision as to where they reside in the architecture will be determine during detailed design (e.g., Use-Case and Subsystem Design). The following changes must be made to the Course Registration Model to incorporate the JDBC persistency mechanisms: