1310414 SYSTEM DESIGN APPROACHES TO MAKING RDBMS DATA PERSISTENT 1.Brute Force –embed SQL in...

1310414310414 SYSTEM DESIGNSYSTEM DESIGN

APPROACHES TO MAKING RDBMS DATA PERSISTENTAPPROACHES TO MAKING RDBMS DATA PERSISTENT

1. Brute Force– embed SQL in application

classes

Pros– can write code very quickly

– O.K. for small applications and prototypes

Cons– couples application classes

directly with database schema making schema changes require reworking the code

databaseSQL

Application classes

: Customer Database

build select statement

set data values

select statement

result set

2310414310414 SYSTEM DESIGNSYSTEM DESIGN

APPROACHES TO MAKING RDBMS DATA PERSISTENTAPPROACHES TO MAKING RDBMS DATA PERSISTENT

2. Data Access Objects– encapsulate SQL

statements in one or more “data classes”

Pros– encapsulates the source

code that handles hard-coded transactions in one place

Cons– needs recompilation of

data classes when changes are made to the database

databaseSQL

Application classes

Data classes

: CustData Database

set data values

build select statement

select statement

result set

: Customer

read(customer)

get key values

key value(s)

3310414310414 SYSTEM DESIGNSYSTEM DESIGN

APPROACHES TO MAKING RDBMS DATA PERSISTENTAPPROACHES TO MAKING RDBMS DATA PERSISTENT

3. Persistence Framework– a persistence layer maps

objects to the database so that simple changes to the database schema do not affect the object code

Pros– application classes do not

know anything about the database schema (they do not even know that a database is being used!)

Cons– impacts performance

databaseSQL

Application classes

Persistence Layer

: PersistenceFramework

Database

set data values

build select statement

select statement

: Customer

read(customer)

get key values

: MappingClasses

get maps

4310414310414 SYSTEM DESIGNSYSTEM DESIGN

Makes an object

persistent

EXAMPLE PERSISTENT DATA FRAMEWORKEXAMPLE PERSISTENT DATA FRAMEWORK

creates

maps

PersistentObject

-isProxy : Boolean-isPersistent : Boolean-timestamp : DateTime

+save()+retrieve()+delete() PersistentTransaction

-tasks : Collection

+processTransaction()+retry()+addTransaction()+addSaveObject()+addRetrieveObject()+addDeleteObject()+addCriteria()-attempt()-rollback()-commit()

PersistentCrteria

-areSubclassesIncluded : Boolean-forClass : Class

+addSelectXXX()+addOrCriteria()+perform()

SqlStatement

-statementComponents : Collection

+buildForObjects()+buildForCriteria()+asString()

ClassMap

-name : String

+getInsertSqlFor()+getDeleteSqlFor()+getUpdateSqlFor()+getSelectSqlFor()

PersistenceBroker

-singleInstance : Object-connections : Collection+saveObject()+retrieveObject()+deleteObject()+processCriteria()+processTransaction()+processSql()-connectTo()-disconnectFrom()-retrieveClassMaps()

PersistenceMechanism

-connection : Connection-name : String

+open()+open()+close()+isOpen()

*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer

+nextObjects()+nextProxies()+nextRows()+previousObjects()+previousProxies()+previousRows()-defaultSize()

*

created from

uses

*

connects to

processed by

processed by

processed by

6310414310414 SYSTEM DESIGNSYSTEM DESIGN

ProvidesQuery and

Transaction Processing

EXAMPLE PERSISTENT DATA FRAMEWORKEXAMPLE PERSISTENT DATA FRAMEWORK

creates

maps

PersistentObject

-isProxy : Boolean-isPersistent : Boolean-timestamp : DateTime

+save()+retrieve()+delete() PersistentTransaction

-tasks : Collection

+processTransaction()+retry()+addTransaction()+addSaveObject()+addRetrieveObject()+addDeleteObject()+addCriteria()-attempt()-rollback()-commit()

PersistentCrteria

-areSubclassesIncluded : Boolean-forClass : Class

+addSelectXXX()+addOrCriteria()+perform()

SqlStatement

-statementComponents : Collection

+buildForObjects()+buildForCriteria()+asString()

ClassMap

-name : String

+getInsertSqlFor()+getDeleteSqlFor()+getUpdateSqlFor()+getSelectSqlFor()

PersistenceBroker

-singleInstance : Object-connections : Collection+saveObject()+retrieveObject()+deleteObject()+processCriteria()+processTransaction()+processSql()-connectTo()-disconnectFrom()-retrieveClassMaps()

PersistenceMechanism

-connection : Connection-name : String

+open()+open()+close()+isOpen()

*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer

+nextObjects()+nextProxies()+nextRows()+previousObjects()+previousProxies()+previousRows()-defaultSize()

*

created from

uses

*

connects to

processed by

processed by

processed by

14310414310414 SYSTEM DESIGNSYSTEM DESIGN

Maps Objects to

Tables

EXAMPLE PERSISTENT DATA FRAMEWORKEXAMPLE PERSISTENT DATA FRAMEWORK

creates

maps

PersistentObject

-isProxy : Boolean-isPersistent : Boolean-timestamp : DateTime

+save()+retrieve()+delete() PersistentTransaction

-tasks : Collection

+processTransaction()+retry()+addTransaction()+addSaveObject()+addRetrieveObject()+addDeleteObject()+addCriteria()-attempt()-rollback()-commit()

PersistentCrteria

-areSubclassesIncluded : Boolean-forClass : Class

+addSelectXXX()+addOrCriteria()+perform()

SqlStatement

-statementComponents : Collection

+buildForObjects()+buildForCriteria()+asString()

ClassMap

-name : String

+getInsertSqlFor()+getDeleteSqlFor()+getUpdateSqlFor()+getSelectSqlFor()

PersistenceBroker

-singleInstance : Object-connections : Collection+saveObject()+retrieveObject()+deleteObject()+processCriteria()+processTransaction()+processSql()-connectTo()-disconnectFrom()-retrieveClassMaps()

PersistenceMechanism

-connection : Connection-name : String

+open()+open()+close()+isOpen()

*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer

+nextObjects()+nextProxies()+nextRows()+previousObjects()+previousProxies()+previousRows()-defaultSize()

*

created from

uses

*

connects to

processed by

processed by

processed by

17310414310414 SYSTEM DESIGNSYSTEM DESIGN

Interacts with

Persistence Mechanism

EXAMPLE PERSISTENT DATA FRAMEWORKEXAMPLE PERSISTENT DATA FRAMEWORK

creates

maps

PersistentObject

-isProxy : Boolean-isPersistent : Boolean-timestamp : DateTime

+save()+retrieve()+delete() PersistentTransaction

-tasks : Collection

+processTransaction()+retry()+addTransaction()+addSaveObject()+addRetrieveObject()+addDeleteObject()+addCriteria()-attempt()-rollback()-commit()

PersistentCrteria

-areSubclassesIncluded : Boolean-forClass : Class

+addSelectXXX()+addOrCriteria()+perform()

SqlStatement

-statementComponents : Collection

+buildForObjects()+buildForCriteria()+asString()

ClassMap

-name : String

+getInsertSqlFor()+getDeleteSqlFor()+getUpdateSqlFor()+getSelectSqlFor()

PersistenceBroker

-singleInstance : Object-connections : Collection+saveObject()+retrieveObject()+deleteObject()+processCriteria()+processTransaction()+processSql()-connectTo()-disconnectFrom()-retrieveClassMaps()

PersistenceMechanism

-connection : Connection-name : String

+open()+open()+close()+isOpen()

*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer

+nextObjects()+nextProxies()+nextRows()+previousObjects()+previousProxies()+previousRows()-defaultSize()

*

created from

uses

*

connects to

processed by

processed by

processed by

19310414310414 SYSTEM DESIGNSYSTEM DESIGN

Encapsulates Persistence Mechanism

EXAMPLE PERSISTENT DATA FRAMEWORKEXAMPLE PERSISTENT DATA FRAMEWORK

creates

maps

PersistentObject

-isProxy : Boolean-isPersistent : Boolean-timestamp : DateTime

+save()+retrieve()+delete() PersistentTransaction

-tasks : Collection

+processTransaction()+retry()+addTransaction()+addSaveObject()+addRetrieveObject()+addDeleteObject()+addCriteria()-attempt()-rollback()-commit()

PersistentCrteria

-areSubclassesIncluded : Boolean-forClass : Class

+addSelectXXX()+addOrCriteria()+perform()

SqlStatement

-statementComponents : Collection

+buildForObjects()+buildForCriteria()+asString()

ClassMap

-name : String

+getInsertSqlFor()+getDeleteSqlFor()+getUpdateSqlFor()+getSelectSqlFor()

PersistenceBroker

-singleInstance : Object-connections : Collection+saveObject()+retrieveObject()+deleteObject()+processCriteria()+processTransaction()+processSql()-connectTo()-disconnectFrom()-retrieveClassMaps()

PersistenceMechanism

-connection : Connection-name : String

+open()+open()+close()+isOpen()

*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer

+nextObjects()+nextProxies()+nextRows()+previousObjects()+previousProxies()+previousRows()-defaultSize()

*

created from

uses

*

connects to

processed by

processed by

processed by

23310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU Course RegistrationASU Course Registration

Class Diagram — DesignClass Diagram — Design

Select Courses to TeachSelect Courses to Teach

25310414310414 SYSTEM DESIGNSYSTEM DESIGN

SUBSYSTEM DESIGNSUBSYSTEM DESIGN

can contain:– design classes – use-case realizations– other subsystems – interfaces

use case can be designed as a collaboration of subsystems rather than classes class diagram of subsystems

subsystems can be used on interaction diagrams allows hierarchical decomposition

subsystemname

A A subsystemsubsystem is used to is used to organize artifactsorganize artifacts of the of the design modeldesign model into more manageable pieces into more manageable pieces

A A subsystemsubsystem is used to is used to organize artifactsorganize artifacts of the of the design modeldesign model into more manageable pieces into more manageable pieces

can be refinements of packages or be directly identified in the design workflow (if there is no analysis model)

6.3.1

26310414310414 SYSTEM DESIGNSYSTEM DESIGN

SUBSYSTEM DESIGN — LAYERS AND PARTITIONSSUBSYSTEM DESIGN — LAYERS AND PARTITIONS

recursively dividing subsystems into smaller and simpler subsystems leads to a hierarchy of subsystems/layers

each layer (subsystem) provides higher-level services and uses services of lower-level layers (subsystems)

subsystem layer architecture:– closed layered architecture: each layer can only depend on the

layer immediately below it lower coupling (more overhead)– open layered architecture: each layer can depend on any layer

below it higher coupling (less overhead)

subsystem partitions:– divide services in one layer into different subsystems– results in peer to peer services within a layer

6.3.4

Usually there are 3 to 5 subsystem layers in practice.

30310414310414 SYSTEM DESIGNSYSTEM DESIGN

PeopleMaintenance

CourseMaintenance

PeopleData

CourseData

ASU SUBSYSTEMS AND DEPENDENCIESASU SUBSYSTEMS AND DEPENDENCIES

SystemSecurity Application-specific layer

Application-general layer

ReportGeneration

Interfaces

CourseRegistration

31310414310414 SYSTEM DESIGNSYSTEM DESIGN

SUBSYSTEM INTERFACESSUBSYSTEM INTERFACES

An An interfaceinterface is the is the set of operationsset of operations that are that are accessible accessible from “outside”from “outside” the subsystem to other subsystems. the subsystem to other subsystems.

An An interfaceinterface is the is the set of operationsset of operations that are that are accessible accessible from “outside”from “outside” the subsystem to other subsystems. the subsystem to other subsystems.

6.3.2

also called the application programmer interface (API)

interface specification includes:– operation names – return values (if any)– parameters and their type

the interface implementation is provided by classes or other subsystems within the subsystem

if a subsystem has a dependency directed toward it,it is likely that it needs to provide an interface

any client using an interface is independent of the implementation of the subsystem

32310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU Course Registration SystemASU Course Registration System

Some Subsystem InterfacesSome Subsystem Interfaces

33310414310414 SYSTEM DESIGNSYSTEM DESIGN

CourseRegistration

ASU INTERFACES — COURSEREGISTRATION ASU INTERFACES — COURSEREGISTRATION SUBSYSTEM SUBSYSTEM

StudentRegistrationMgr

RequestEnrollmentMgr

PrepareBillingInfoMgr

IRegistration IEnrollment

IBilling

34310414310414 SYSTEM DESIGNSYSTEM DESIGN

CourseRegistration

StudentRegistrationMgr

RequestEnrollmentMgr

PrepareBillingInfoMgr

CourseRegistrationMgr

ASU INTERFACES — COURSEREGISTRATION ASU INTERFACES — COURSEREGISTRATION SUBSYSTEMSUBSYSTEM

ICourseRegistration

Use the Façade design pattern to minimize coupling.

35310414310414 SYSTEM DESIGNSYSTEM DESIGN

EXAMPLE PERSISTENT DATA FRAMEWORKEXAMPLE PERSISTENT DATA FRAMEWORK

creates

maps

PersistentObject

-isProxy : Boolean-isPersistent : Boolean-timestamp : DateTime

+save()+retrieve()+delete() PersistentTransaction

-tasks : Collection

+processTransaction()+retry()+addTransaction()+addSaveObject()+addRetrieveObject()+addDeleteObject()+addCriteria()-attempt()-rollback()-commit()

PersistentCrteria

-areSubclassesIncluded : Boolean-forClass : Class

+addSelectXXX()+addOrCriteria()+perform()

SqlStatement

-statementComponents : Collection

+buildForObjects()+buildForCriteria()+asString()

ClassMap

-name : String

+getInsertSqlFor()+getDeleteSqlFor()+getUpdateSqlFor()+getSelectSqlFor()

PersistenceBroker

-singleInstance : Object-connections : Collection+saveObject()+retrieveObject()+deleteObject()+processCriteria()+processTransaction()+processSql()-connectTo()-disconnectFrom()-retrieveClassMaps()

PersistenceMechanism

-connection : Connection-name : String

+open()+open()+close()+isOpen()

*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer

+nextObjects()+nextProxies()+nextRows()+previousObjects()+previousProxies()+previousRows()-defaultSize()

*

created from

uses

*

connects to

processed by

processed by

processed by

Query Transaction Processing

Mapping

RdbmsPort

37310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU INTERFACES — COURSEDATA SUBSYSTEMASU INTERFACES — COURSEDATA SUBSYSTEM

CourseData

PCourseICourseData

PSection

PCourseOffering

CourseQuery

TransactionProcessing

Mapping SectionQuery

TransactionProcessing

Mapping

CourseOffering

QueryTransactionProcessing

Mapping

RdbmsPort

IRdbmsPort

IPCourse

IPSection

IPCourseOffering

CourseDataMgr

38310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU INTERFACES — COURSEDATA SUBSYSTEMASU INTERFACES — COURSEDATA SUBSYSTEM

CourseData

ICourseData

RdbmsPort

IRdbmsPort

CourseDataMgr

IPCourse

IPSection

IPCourseOffering

PCourse

PSection

PCourseOffering

41310414310414 SYSTEM DESIGNSYSTEM DESIGN

DEPLOYMENT MODELDEPLOYMENT MODEL

A deployment diagram shows:– nodes: computational resources (e.g., processors)

– relationships: means of communication among nodes (e.g., network)

common distributed configurations use a three-tier architecture– clients (to handle user interactions) boundary classes– database functionality (to store persistent data) entity classes– business/application logic control classes

Describes how theDescribes how the functionalityfunctionality of the system of the system is is physically distributedphysically distributed toto processing nodesprocessing nodes

Describes how theDescribes how the functionalityfunctionality of the system of the system is is physically distributedphysically distributed toto processing nodesprocessing nodes

nodename

6.3.6

Client/server Architecture

(special case of three-tier architecture where business/ application logic is relocated to one of the other two tiers)

43310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU Course Registration SystemASU Course Registration System

Deployment ModelDeployment Model

44310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU DEPLOYMENT MODELASU DEPLOYMENT MODEL

DatabaseserverRegistrar

DormMain

BuildingLibrary

«intranet» «intranet» «intranet»

«intranet»

45310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU DEPLOYMENT MODEL — REGISTRAR NODEASU DEPLOYMENT MODEL — REGISTRAR NODE

Registrar

PeopleMaintenance

CourseMaintenance

PeopleData

CourseData

ReportGeneration

Interfaces

CourseRegistration

SystemSecurity

46310414310414 SYSTEM DESIGNSYSTEM DESIGN

ASU DEPLOYMENT MODEL — DORM NODEASU DEPLOYMENT MODEL — DORM NODE

Dorm

PeopleData

CourseData

Interfaces

CourseRegistration

SystemSecurity

47310414310414 SYSTEM DESIGNSYSTEM DESIGN

SYSTEM DESIGN ACTIVITIES — RETROSPECTIVESYSTEM DESIGN ACTIVITIES — RETROSPECTIVE

Use-case design– identifies active classes and additional classes needed to meet

design goals and handle the implementation environment

Class design– completes the specification of each class (attributes, operations);– identifies reusable components;– restructures and optimizes the design model

generic design mechanisms – handle nonfunctional requirements

Subsystem design– organize classes into cohesive, loosely coupled units;– specifies the physical distribution of software onto hardware

interfaces – describe a subsystems public operations

48310414310414 SYSTEM DESIGNSYSTEM DESIGN

SUMMARY — SYSTEM DESIGNSUMMARY — SYSTEM DESIGN

Design Model contains:

These are all documented in theSystem Design Specification (SDS)

Use-case realizations—design used to construct “builds” during implementation

Design classes, their operations, attributes, relationships and implementation requirements

implemented by files containing source code

Subsystems, their dependencies and their interfaces implemented by implementation subsystems containing

source code, scripts, binaries, executables, etc.

Deployment Model