1310414 SYSTEM DESIGN APPROACHES TO MAKING RDBMS DATA PERSISTENT 1.Brute Force –embed SQL in application classes Pros –can write code very quickly –O.K

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



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


select statement

result set

: Customer

read(customer)

get key values

key value(s)



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


select statement

: Customer

read(customer)

get key values

: MappingClasses

get maps


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


ProvidesQuery and

Transaction Processing


creates

maps

PersistentObject



-tasks : Collection


PersistentCrteria



SqlStatement



ClassMap

-name : String


PersistenceBroker





*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer


*

created from

uses

*

connects to

processed by

processed by

processed by


Maps Objects to

Tables


creates

maps

PersistentObject



-tasks : Collection


PersistentCrteria



SqlStatement



ClassMap

-name : String


PersistenceBroker





*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer


*

created from

uses

*

connects to

processed by

processed by

processed by


Interacts with

Persistence Mechanism


creates

maps

PersistentObject



-tasks : Collection


PersistentCrteria



SqlStatement



ClassMap

-name : String


PersistenceBroker





*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer


*

created from

uses

*

connects to

processed by

processed by

processed by


Encapsulates Persistence Mechanism


creates

maps

PersistentObject



-tasks : Collection


PersistentCrteria



SqlStatement



ClassMap

-name : String


PersistenceBroker





*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer


*

created from

uses

*

connects to

processed by

processed by

processed by


ASU Course RegistrationASU Course Registration

Class Diagram — DesignClass Diagram — Design

Select Courses to TeachSelect Courses to Teach


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


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.


PeopleMaintenance

CourseMaintenance

PeopleData

CourseData

ASU SUBSYSTEMS AND DEPENDENCIESASU SUBSYSTEMS AND DEPENDENCIES

SystemSecurity Application-specific layer

Application-general layer

ReportGeneration

Interfaces

CourseRegistration


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


ASU Course Registration SystemASU Course Registration System

Some Subsystem InterfacesSome Subsystem Interfaces


CourseRegistration

ASU INTERFACES — COURSEREGISTRATION ASU INTERFACES — COURSEREGISTRATION SUBSYSTEM SUBSYSTEM

StudentRegistrationMgr

RequestEnrollmentMgr

PrepareBillingInfoMgr

IRegistration IEnrollment

IBilling


CourseRegistration

StudentRegistrationMgr

RequestEnrollmentMgr

PrepareBillingInfoMgr

CourseRegistrationMgr

ASU INTERFACES — COURSEREGISTRATION ASU INTERFACES — COURSEREGISTRATION SUBSYSTEMSUBSYSTEM

ICourseRegistration

Use the Façade design pattern to minimize coupling.



creates

maps

PersistentObject



-tasks : Collection


PersistentCrteria



SqlStatement



ClassMap

-name : String


PersistenceBroker





*

1

0..1

1..*

1

*

1

1

1

1*

*

1

Cursor

-size : Integer


*

created from

uses

*

connects to

processed by

processed by

processed by

Query Transaction Processing

Mapping

RdbmsPort


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


ASU INTERFACES — COURSEDATA SUBSYSTEMASU INTERFACES — COURSEDATA SUBSYSTEM

CourseData

ICourseData

RdbmsPort

IRdbmsPort

CourseDataMgr

IPCourse

IPSection

IPCourseOffering

PCourse

PSection

PCourseOffering


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)


ASU Course Registration SystemASU Course Registration System

Deployment ModelDeployment Model


ASU DEPLOYMENT MODELASU DEPLOYMENT MODEL

DatabaseserverRegistrar

DormMain

BuildingLibrary

«intranet» «intranet» «intranet»

«intranet»


ASU DEPLOYMENT MODEL — REGISTRAR NODEASU DEPLOYMENT MODEL — REGISTRAR NODE

Registrar

PeopleMaintenance

CourseMaintenance

PeopleData

CourseData

ReportGeneration

Interfaces

CourseRegistration

SystemSecurity


ASU DEPLOYMENT MODEL — DORM NODEASU DEPLOYMENT MODEL — DORM NODE

Dorm

PeopleData

CourseData

Interfaces

CourseRegistration

SystemSecurity


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


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

Documents

1310414 SYSTEM DESIGN APPROACHES TO MAKING RDBMS DATA PERSISTENT 1.Brute Force –embed SQL in application classes Pros –can write code very quickly –O.K