1. Elaboration Iteration 3 – Part 3 - Persistence Framework -
OO Methodology
Elaboration Iteration 3 – Part 3
- Persistence Framework -

2. Table of Contents Iteration 1 Iteration 2 Iteration 3 Use-Case Model
Process Sale Use Case
Domain Model
Design Model
Iteration 2
GRASP: More Patterns for Assigning Responsibilities
Designing Use-Case Realizations with GoF Design Patterns
Iteration 3
Related Use Cases
Modeling Generalization
Refining the Domain Model
Adding New SSDs and Contracts
Modeling Behavior in Statechart Diagrams
Designing the Logical Architecture with Patterns
Organizing the Design and Implementation Model Packages
Introduction to Architectural Analysis and the SAD
Designing More Use-Case Realization with Paterns
Designing a Persistence Framework with Patterns

3. Iteration 3 Requirements
Provide failover to local services when the remote services cannot be accessed.
Provide support for POS device handling, such as the cash drawer and coin dispenser
Handle credit payment authorization
Support for persistent objects

4. Designing a Persistence Framework
Objectives
Design part of a framework with the Template Method, State, and Command patterns
Introduce issues in object-relational(O-R) mapping
Implement lazy materialization with Virtual Proxies
Requirements
the NextGen application requires storing and retrieving information in a persistent storage mechanism, such as relational database (e.g. ProductSpefication )
Persistent Objects
objects that require persistent storage
Solution
a persistence service from a persistence framework
a persistence framework is a general, reusable, and extendable set of types that provides functionality to support persistent objects
Persistence service is usually written to work with RDB (O-R mapping service)
In terms of the layered architecture, a persistence service is a subsystem within the technical service layer

5. Frameworks
is a cohesive set of interfaces and classes that collaborate to provide services for the core, unvarying part of a logical subsystem
contains concrete and abstract classes that define interfaces to conform to, object interactions to participate in, and other invariants
usually requires the framework user to define subclasses of existing framework classes to make use of, customize, and extend the framework services
relies on the Hollywood Principle – “don’t call us, we’ll call you”

6. Persistence Framework
Requirements
store and retrieve objects in a persistent storage mechanism
commit and rollback transactions
Key Ideas
Mapping
mapping between a class and its persistent store(table), and between object attributes and the fields in a record
Object Identity
To easily relate records to objects, and to ensure there are no inappropriate duplicates
Database Mapper
responsible for materialization and dematerialization
Materialization and Dematerialization
materialization is to transform a non-object representation into objects
Caches
Transaction State of Object
the state of objects in terms of their relationship to the current transactions
Transaction Operations
commit, rollback
Lazy Materialization
materialized on demand
Virtual Proxies
lazy materialization can be implemented using a smart reference known as a virtual proxy

7. Representing Objects as Tables
How to map an object to a record
define a table in a RDB for each persistent object class
object attributes containing primitive data types mat to columns
UML Data Modeling Profile
a coherent set of UML stereotypes, tagged values, and constraints for modeling RDB

8. Object Identifier Consistent way to relate objects to records OID
Assign an object identifier(OID) to each record and object
OID
an alphanumeric value
unique to a specific object
within in objects, an OID is represented by OID interface or class, and in RDB OID is stored as a character string

9. Accessing Persistence Service
Facade to Persistence Subsystem
a unified interface to persistence subsystem
DB Adapter collaborates with Persistence Facade

10. Mapping Objects: Database Mapper
Who should be responsible for materialization and dematerialization of objects
persistent object itself by Information Expert (direct mapping)
strong coupling of the persistent object class to persistent storage knowledge
using Database Mapper (indirect mapping)
Database Mapper
a different mapper class is defined for each persistent object class

11. Framework Design with Template Method Pattern
define the skeleton of an algorithm in a method(template method), with some varying and unvarying parts, deffering some steps to subclasses.
template method invokes other methods, some of which may be overridden in a subclass(hook method)

12. An Application of Template Method
Painting in GUI Framework

13. Materialization with Template Method
Skeleton algorithm for get method in AbstractMapper
if (object in cache)
return it
else
create the object from its representation in storage
save object in cache

14. Materialization with Template Method
Overriding the hook method

15. Materialization with Template Method
getObjectFromStorage hook method is also a candidate template method

16. Persistence Framework

17. Configuring Mappers with a MapperFactory
a solutin
to get each mapper with a different operation within the Factory
class MapperFactory
{ public IMapper getProduct SpecificationMapper() {...}
public IMapper getsalemapper() { ... }
... }
violate Protected Variations
better solution
using data-driven, factory assign a set of IMappers {
public Map getAllMappers() { ... }
class PersistenceFacade
private java.util.Map mappers
= MapperFactory.getInstance().getAllMappers();
public Object get(OID oid, class persistenceClass)
IMapper mapper = (IMapper) mappers.get(persistenceclass);
return mapper.get(oid);

18. Transaction States and the State Pattern
persistent objects can be inserted, deleted, or modified
operating on a persistent object does not cause an immediate database update, rather an explicit commit operation must be performed

19. Context for State Pattern
Common technical services
Repeating case logic structure
public void commit() {
switch (state)
{ case OLD_DIRTY:
//...
break;
case OLD_CLEAN:
... }
public void rollback()

20. State Pattern Context/Problem Solution
An object’s behavior is dependent on its state, and its methods contain case logic reflecting conditional state-dependent actions.
Solution
Create state classes for each state, implementing a common interface. Delegate state-dependent operations from the context object to its current state object.

21. Applying State Pattern

22. Designing a Transaction with the Command Pattern
Transaction is a set of tasks that must all complete successfully, or none must be completed. (atomic)
the tasks of a transaction include inserting, updating, deleting objects.
e.g. a transaction can contain two inserts, one update, and three deletes.
Transaction
is a good candidate class
contains tasks
tasks can be queued, and delayed for execution, reordered for performance, integrity, etc.
Command Pattern
Context/Problem
How to handle requests or tasks that need functions such as sorting, queueing, delaying, logging, or undoing?
Solution
Make each task a class that implements a common interface
Example
GUI actions should be stacked and can be undoed
server-side handles client requests by queueing, prioritizing, executing them

23. Designing a Transaction with the Command Pattern
Commands for database operations

24. Lazy Materialization with a Virtual Proxy
It is sometimes desirable to defer the materialization of an object until it absolutely required, for performance
Virtual Proxy
is a proxy for another object that materializes the real subject when it is first referenced
is a lightweight object that stands for a real object