Object Oriented Analysis and Design Using the UML Version 4.2

1. Object Oriented Analysis and Design Using the UMLVersion 4.2 Architectural Design Patterns

2. 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’ aremapped 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. Analysis Mechanism (Conceptual) Design Mechanism (Concrete) Implementation Mechanism (Actual) (often constrained by Availability) Legacy Data Persistency RDBMS JDBC New Data ObjectStore OODBMS Persistency Remote Method Invocation (RMI) Distribution Java x.x from Sun Analysis Design Implementation Design/Implementation Mechanisms A ‘what’ was needed to solve a problem:

4. 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. 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. Pattern Name TemplateParameters 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 Aspect Behavioral Aspect

7. 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…) • haveboth 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 interactiondiagram in many cases

8. Documenting Architectural Mechanisms – more** • Architect must: • decideon 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. 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 mayalready 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. Example: Persistency: RDBMS (design)  JDBC (implementation) • Show both design and implementation patterns • Persistentdataobjects 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. 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. • Everyclass that has persistent objects (e.g. book, student, country, etc.) will have acorresponding DBClass, and all persistentobjects from this persistentclass 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 aDriverManager class. • (Note: DriverManager is found in java.sql)

12. Example: Persistency: RDBMS and JDBC (2 of 2) • Once the DBClass gets a connection via DriverManager (found in java.sql), • DBClass can thencreateSQLstatements (via ConnectionClass – found in java.sql) • The SQL statement will be sent to the underlying StatementClass object (found in java.sql) and executed • The Statementobject “talks” the database. • Result of the SQL query is returned in a ResultSet object (found in java.sql).

13. 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. Performance in Statement Class – readonyourown • 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. Statement (from java.sql) executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int Example: Persistency: RDBMS: JDBC Role classes must be built by designer. Roles to be filled by the designer applying the mechanism <<role>> <<role>> PersistencyClient PersistentClassList (from SamplePersistency Client) (from SamplePersistentClass) Note: UML dependency arrows. new() add(c: PersistentClass) <<role>> DBClass 1 0..* create() : PersistentClass <<role>> read(searchCriteria : string) : PersistentClassList PersistentClass update(c : PersistentClass) (from SamplePersistentClass) Uses DriverManager to establish connection Then, DBClass builds statements which it transmits to Connection; Connection builds ‘real’ Statement for execution. delete(c : PersistentClass) getData() 1 setData() command() new() DriverManager (from java.sql) 1 getConnection(url, user, pass) : Connection Connection made to Database here and a connection object is returned to DBClass. Connection ResultSet (from java.sql) (from java.sql) createStatement() : Statement getString() : string

16. 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. Example: Persistency: RDBMS: JDBC. DBClass - more • A PersistentClassList object is returned from a DBClass.read(). (will show ahead) • The persistent class list objectis 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 <<role>> 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. Example: Persistency: RDBMS: JDBC: Initialize : DBClass : (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.’) DriverManager 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. 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

19. 1.4. executeUpdate(String) Example: Persistency: RDBMS: JDBC: Create : : DBClass : : Connection : Statement PersistencyClient :PersistentClass 1. create( ) 1.1. new() 1.2. getData( ) 1.3. createStatement( ) (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. 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. 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. The criteria used to access data for the persistent class Example: Persistency: RDBMS: JDBC: Read : : DBClass : Connection : Statement : ResultSet : : PersistencyClient PersistentClassList PersistentClass returns a 1. read(string) Statement object 1.1. createStatement( ) 1.2. executeQuery(string) Create a list to hold all 1.3. new( ) retrieved data 1.4. new() Repeat these operations for each element returned from 1.5. getString( ) called for each the executeQuery() attribute in the command. 1.6. setData( ) class The PersistentClassList is loaded with the data retrieved 1.7. add(PersistentClass) from the database. Add the retrieved course offering to the list to be returned Note the loop! Spend some time on this diagram

23. 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. execute SQL statement 1.3. executeUpdate(string) Example: Persistency: RDBMS: JDBC: Update : : DBClass : : Connection : Statement PersistencyClient PersistentClass 1. update(PersistentClass) 1.1. getData( ) 1.2. createStatement( )

25. Example: Persistency: RDBMS: JDBC: Delete : : DBClass : Connection : Statement PersistencyClient 1. delete(PersistentClass) 1.1. createStatement( ) execute SQL statement 1.2. executeUpdate(string) (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. 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. Incorporating JDBC: Steps – Summary… • Create/Update interactiondiagrams 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. Sample Persistency Client Package DriverManager (from java.sql) Example: Incorporating JDBC The following changes must be made to the Course Registration Model to incorporate the JDBC persistency mechanisms: java.sql Connection (from java.sql) Statement ResultSet (from java.sql) (from java.sql) 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).