Object Oriented Analysis and Design Using the UML
Object Oriented Analysis and Design Using the UML Version 4. 2 Architectural Design Patterns OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Analysis, Design, and Implementation Mechanisms w We know about (in RUP) Analysis Mechanisms – which are really Non Functional Requirtements… w In Design, the ‘conceptual’ is morphed into a general technology. w In Implementation, these ‘general technologies’ are mapped into quite specific technologies. § E. g. Relational Data Base Oracle; My. SQL, etc. w 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. OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Design/Implementation Mechanisms Analysis Design Implementation Mechanism (Conceptual) (Concrete) (Actual) (often constrained by Availability) A ‘what’ was needed to solve a problem: Persistency Legacy Data RDBMS JDBC New Data Persistency Distribution OODBMS Remote Method Invocation (RMI) Analysis OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved Design 34 Object. Store Java x. x from Sun Implementation
Design Mechanisms w Design mechanism assume § some details of the implementation environment, § but not tied to a specific implementation w For ‘persistency’ our design mechanisms might include: § RDBMS, § OODBMS, § in-memory storage, … w For ‘security’ there will be some other design mechanisms that address… OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Implementation Mechanisms w Implementation mechanisms are used during implementation. w They are bound to a certain technology, implementation language, vendor, technique, etc. w Examples: § § actual programming language, COTS products, Database (Oracle, Sybase, SQL Server…); Inter process communication/distribution technology (COM/DCOM, CORBA) , etc. § w We will use JDBC in our examples ahead – very detailed! OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Documenting Architectural Mechanisms w Architectural Mechanisms may be treated as patterns. w 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. Template Parameters Pattern Name Structural Aspect OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34 Behavioral Aspect
Documenting Architectural Mechanisms – more w 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 34 OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
Documenting Architectural Mechanisms – more** w Architect must: § decide on the pattern, § validate these by building (or integrating them), and § verify they do the job. w The architect must consistently impose these mechanisms on rest of system design. w The architect must ensure that these approaches are consistently used throughout OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Documenting the Architectural Mechanisms more w 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 § The Design Guidelines is a ‘how to’ document a design not yet done. (for your project) in a very specific way. ‘actual’ architectural design choices for a system based on functional / functional requirements. OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34 non-
Example: Persistency: RDBMS (design) JDBC (implementation) w Show both design and implementation patterns w Persistent data objects must be mapped into a storage structure. w 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. 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) w For JDBC, a client (entity) class (our job) will work with a DBClass to read and write persistent data for objects of that class. w 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…) w The DBClass - for objects of this class requiring persistence - is responsible for accessing the JDBC database using a Driver. Manager class. § (Note: Driver. Manager is found in java. sql) 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) w Once the DBClass gets a connection via Driver Manager (found in java. sql), w DBClass can then create SQL statements (via Connection Class – found in java. sql) w The SQL statement will be sent to the underlying Statement Class object (found in java. sql) and executed w The Statement object “talks” the database. w Result of the SQL query is returned in a Result. Set object (found in java. sql). OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Summary of ‘cooperation’ for this pattern w 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. 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 w For performance optimization, there is also the notion of Prepared. Statements, (which ‘inherits’ from Statement). w The basic idea with Prepared. Statement 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. w This is a performance optimization and is not that important from a mechanisms point of view. In this model, we did not include Prepared. Statements at all. w 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. OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Example: Persistency: RDBMS: JDBC <<role>> Persistency. Client Role classes must be built by designer. Roles to be filled by the designer applying the mechanism (from Sample. Persistency Client) <<role>> Persistent. Class. List (from Sample. Persistent. Class) Note: UML dependency arrows. new() add(c: Persistent. Class) <<role>> DBClass 1 create() : Persistent. Class read(search. Criteria : string) : Persistent. Class. List update(c : Persistent. Class) delete(c : Persistent. Class) Uses Driver. Manager to establish connection Then, DBClass builds statements which it transmits to Connection; Connection builds ‘real’ Statement for execution. <<role>> Persistent. Class (from Sample. Persistent. Class) get. Data() set. Data() command() new() 1 Driver. Manager (from java. sql) 1 Result. Set Statement (from java. sql) get. String() : string 0. . * execute. Query(sql : String) : Result. Set execute. Update(sql : String) : int OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34 get. Connection(url, user, pass) : Connection (from java. sql) create. Statement() : Statement Connection made to Database here and a connection object is returned to DBClass.
Example: Persistency: RDBMS: JDBC – continuing: DBClass w DBClass - responsible for making objects persistent. w It ‘understands’ the OO-to-RDBMS mapping. w This means that the DBClass possesses the behaviors (methods) to interface with the RDBMS. w 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. w (N. B. Recall: Every class whose objects are persistent will have a corresponding DBClass. ) OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Example: Persistency: RDBMS: JDBC. DBClass - more w A Persistent. Class. List 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. w Consider the need to: § Initialize, Read, Create, Update, Delete w (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. w This convention makes it easier to apply the mechanism because easier to recognize what the designer is to supply. ) OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Example: Persistency: RDBMS: JDBC: Initialize : DBClass : Driver. Manager (The objects to be replaced by concrete objects by the designer Note that Driver. Manager is applying the mechanism available via the Java. sql API. But the software designer shown in yellow. ) (That is, 1. get. Connection(url, user, pass) must develop the DBClass you program this. These if it is not already available Have the stereotype ‘role. ’) for objects of the client class. . 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 Driver. Manager. get. Connection() operation with a URL, user, and password. . get. Connection() 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. ) Driver. Manager 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 OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Example: Persistency: RDBMS: JDBC: Create : Persistency. Client : DBClass : : Persistent. Class : Connection : Statement 1. create( ) 1. 1. new() 1. 2. get. Data( ) 1. 3. create. Statement( ) 1. 4. execute. Update(String) (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 Persistent. Class. DBClass creates a new object via new(). . DBClass then retrieves (get. Data) the ‘object’. The DBClass ‘builds’ the object and serializes it (into a String) and then sends a message (create. Statement()) to the Connection object which returned by Driver. Manager earlier. . create. Statement() returns a Statement object to DBClass, which in turn sends the execute. Update() with the (now) string to the Statement object, which executes the SQL statement OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 will Rational Software, all rights reserved statement, add the string to the 34 database and returns an integer indicating success (or not)
Example: Persistency: RDBMS: JDBC: Read (two info…) w To read a persistent class object, the persistency client asks the DBClass to read (search. Criteria…). w The DBClass sends message to Connection object’s method create. Statement() which creates a new Statement object, as before. w w DBClass sends message to Statement. execute. Query(sql: String) with the appropriate SQL string to ‘select’ the correct data w execute. Query() returns a Result. Set object DBClass. w DBClass can now get the returned String retrieved via the get. String() from the Result. Set object. But note that the data retrieved is a String - not an object or series of objects. w 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. . w The data is returned in a collection object, an instance of the Persistent. Class. List 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! w Note: The string ultimately passed to execute. Query() 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. OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Example: Persistency: RDBMS: JDBC: Read : Persistency. Client : DBClass : Connection : Statement : Result. Set : Persistent. Class. List : Persistent. Class returns a Statement object 1. read(string) 1. 1. create. Statement( ) The criteria used to access data for the persistent class 1. 2. execute. Query(string) Create a list to hold all retrieved data 1. 3. new( ) 1. 4. new() Repeat these operations for each element returned from the execute. Query() command. 1. 5. get. String( ) 1. 6. set. Data( ) The Persistent. Class. List is loaded with the data retrieved from the database. called for each attribute in the class 1. 7. add(Persistent. Class) Add the retrieved course offering to the list to be returned Note the loop! Spend some time on this diagram 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) w To update an object, the persistency client sends a message to DBClass via update(). w The DBClass is retrieves a persistent object § (next sequence diagram) w DBClass obtains a Statement object returned from Connection class when the Connection object is sent the message create. Statement(). § (See Statement object in sequence diagram in next slide) Once the object is serialized into a String, the execute. Update(string) is executed via Statement. execute. Update(String) message. (Remember: It is the DBClass’s job to “flatten” the Persistent. Class object and write it to the database. ) OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Example: Persistency: RDBMS: JDBC: Update : Persistency. Client : DBClass : Persistent. Class : Connection : Statement 1. update(Persistent. Class) 1. 1. get. Data( ) 1. 2. create. Statement( ) 1. 3. execute. Update(string) OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34 execute SQL statement
Example: Persistency: RDBMS: JDBC: Delete : Persistency. Client : DBClass : Connection : Statement 1. delete(Persistent. Class) 1. 1. create. Statement( ) execute SQL statement 1. 2. execute. Update(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 create. Statement() is invoked. . The Statement. execute. Update(string) is executed (this is an SQL statement) and the data is removed from the database. 34 OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
Summary of Steps to Implement the RDBMS Persistency Mechanism (JDBC) w 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. w Create necessary DBClasses – one persistent class w Once created, incorporate DBClasses into the design § Allocated to a package/layer – likely middleware § Add relationships from persistency clients to the DBClasses w OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34 More…. .
Incorporating JDBC: Steps – Summary… w Create/Update interaction diagrams that describe: § Database initialization § Persistent class access: Create, Read, Update, Delete w Interaction diagrams used to verify all required database functionality is supported by the design elements. w 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. ) w Definition of the actual DBClasses and development of the detailed interaction diagrams - deferred until detailed design. OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34
Example: Incorporating JDBC The following changes must be made to the Course Registration Model to incorporate the JDBC persistency mechanisms: Sample Persistency Client Package java. sql Driver. Manager (from java. sql) Connection (from java. sql) Statement Result. Set (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 OOAD Using the UML - Architectural Design, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34 design (e. g. , Use-Case and Subsystem Design). will be determine during detailed
- Slides: 28