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

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

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

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

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”

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

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

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

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

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

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)

An Application of Template Method Painting in GUI Framework

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

Materialization with Template Method Overriding the hook method

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

Persistence Framework

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);

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

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()

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.

Applying State Pattern

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

Designing a Transaction with the Command Pattern Commands for database operations

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