From Class Diagrams to From Class Diagrams to DatabasesDatabases

So far we have considered “objects”customer

nameaddresstelephone number

order()pay for goods()

Objects have attributes

Objects have operations

Attributes are the things you record about an object

Operations are things you “do” to objects

DatabasesDatabases

Databases are used to store attributesDatabases are used to store attributes

nameaddresstelephone number

customer

order()pay for goods()

nameaddresstelephone number

We “remember” attributes by storing them on a computer’s hard disk

The most common way to keep a record of the attributes is to use a database

Ways of remembering attributesWays of remembering attributes

Relational Databases• Easy to get things in and out• Can do clever things

Files• Hard work• Cheaper and less to learn• Forget the clever things

Object Oriented Databases• Every computer scientist’s dream• But they don’t work too well yet

A database is a collection of tablesA database is a collection of tables

Part Number Part Name Price2 Spark plug 2.99

Parts

Customer Number Name Address Telephone number12 Peter 12 Ladbroke Street 01484 32434515 Mary 14 Perry Avenue 01274 98209

Customers

Customer Number Order Number Date Part Number12 1 28/08/2001 2

Orders

Linking tables togetherLinking tables together

One record refers to another by recording its key

Customer Number Order Number Date Part Number12 1 28/08/2001 2

So the order record holds the key of the customer record

Customer Number Name Address Telephone number12 Peter 12 Ladbroke Street 01484 32434515 Mary 14 Perry Avenue 01274 98209

Foreign key

Primary key

Entity-relationship diagramsEntity-relationship diagrams

These are like class diagramsThey show tables instead of objects

1

customer

ordern

1

part

1

nn

1

n

So what do we store from an object-oriented analysis

Later we will talk about:

• Boundary objects that define interfaces such as screens• Control objects that define where complex processing is done• Entity objects that are the primary objects

We store the entity objects in the database because

• boundary objects such as screens don’t need their states recording for long times – they are transient

• control objects do their work and you forget about them• entity objects need to be used again and again – need to be

persistent

: Order clerk : order screen : order control : customer : order

Get stored in databaseDon’t get storedin database

A Class diagramA Class diagram

Customer Orderplaces

OrderItem

made up of

Productof

Customer orderCustomer order

Add multiplicityAdd multiplicity

Customer Order

0..n

places

OrderItem

1..n

made up of

Product1..n

of

0..n

1..n

1..n

Add attributesAdd attributes

Customer

SurnameForenameAddress

TelNo

Order

DatePayment method

0..n

places

OrderItem

Quantity

1..n

made up of

Product

DescriptionPriceSizeColour

1..n

of

0..n

1..n

1..n

Add Primary KeysAdd Primary Keys

Customer

Customer NoSurnameForenameAddressTelNo

Order

Order NoDatePayment method

0..n

places

OrderItem

Item NoQuantity

1..n

made up of

Product

Product IDDescriptionPriceSizeColour

1..n

of

0..n

1..n

1..n

Add Foreign KeysAdd Foreign Keys

Customer

Customer NoSurnameForenameAddressTelNo

Order

Order No

Customer NoDatePayment method

0..n

OrderItem

Item NoOrderNoProduct IDQuantity

1..nProduct

Product IDDescriptionPriceSizeColour

1..n

0..n

1..n

1..n

These are the tables of your databaseThese are the tables of your database

Customer

Customer NoSurnameForenameAddress

TelNo

Order

Order NoCustomer No

DatePayment method

OrderItem

Item NoOrderNoProduct IDQuantity

Product

Product IDDescriptionPriceSizeColour

More on Implementing RelationshipsMore on Implementing Relationships

• The attributes of the object map to columns in a table.

• An object is stored as a row in a database table

Storing ObjectsStoring Objects

loan

loanNumbercustomerNumberamountBorrowed

LoanNumber CustomerNumber AmountBorrowed

152 21 £122.00

163 31 £62.50

164 21 £19.25

Objects stored as rows

Attributes stored as fields

One-to-many relationshipsOne-to-many relationships

• A customer places many orders

• An order is for many products

• A loan can have many payments

• A course has many students

• Record relationship by storing key of one side in the table on the many side

loan

loanNumbercustomerNumberamountBorrowed

payment

dateamount0..n0..n

loanNumber customerNumber amountBorrowed123 456 32,000156 321 13,000

Attributes into a table

loanNumber date amount123 17/05/1999 200123 18/06/1999 200

Attributes into a table

Record relationship by storing key of one side in the table on the many side

One-to-many relationshipsOne-to-many relationships

Many-to-many relationshipsMany-to-many relationships

• Many Customers order many items.• Many clients book many holidays• Many students select many modules

• Whilst many to many relationships are perfectly acceptable in class diagrams, they cannot be implemented directly into relational databases.

• A customer will not link directly to a product item• A product item will not link directly to a customer

• It is usual to produce a linking table to connect the two lots of information.

0..n

module

moduleNamemoduleNumber

student

nameaddressstudentNumber 0..n0..n 0..n

moduleName moduleNumberIM&D CHI107IM&D CHI107

Attributes into a table

name address student numberJohn Smith 13 Daisy Ave 123Mary Jones 17 Oak Lane 124

Attributes into a table

StudentNumber ModuleNumber123 CHI107124 CHI107

Create a table to store the relationship with keys from each of the other tables

Many-to-many relationshipsMany-to-many relationships

More objectsMore objects

• So far, we have looked at the idea of objects. When you build an "object oriented" system, everything is an object.

• We have not really considered all the different types of object.

• We have looked at entity objects and seen how they can be made into relational database tables

• Now we will look at: boundary objects and control objects.

Design ObjectsDesign Objects

• Add structure to the implementation

• Separate out interface, control and entity behaviour

• Make systems more maintainable

• Clarify design issues

Transferring MoneyTransferring Money

Bank ClerkTransfer Money

Primary Path:

1. Withdraw cash from account 12. Deposit cash in account 2

Our initial model

Documentation

First sequence diagramFirst sequence diagram

: Bank ClerkA1 : Account A2 : Account

transfer

withdraw

deposit

ProblemsProblems

• This model assumes that once the clerk has requested that account1 transfers funds, it will know to withdraw money from itself and credit account2

• Accounts in the real world do not know about each other, so this would be unnatural

• You need to log or record transactions, so the account would have to have a transaction logging ability, so again not natural

• If you wire up your objects this way, the wiring can get very messy

Better model:Better model:

A2 : Account : Bank Clerk

A1 : Account : Transfer

transferwithdraw

Deposit

Why is it better?Why is it better?

• There is a new notion of a “control” object called

“Transfer”

• The control object knows how to execute a transfer

• Accounts know how to be accounts

• The control object can be responsible for other related

transaction items (e.g. journaling)

InterfacesInterfaces

• The previous model didn’t consider any interface

behaviour

Even betterEven better

: Bank Clerk : TransferScreen : Transfer A1 : Account A2 : Account

Enter Amount

Enter Source Account

Enter Destination Account

TransferTransfer

Withdraw

Deposit

Why?Why?

• Actors always interact with boundary objects (e.g.

screens)

• Screens often do lots of things, such as collect data,

before causing some internal action to take place

• Screens instruct control objects to do things when

they have all the information they need

Object typesObject types

• Control

• Entity

• Boundary

Control ObjectsControl Objects

• Group inter-object communication

• Stop entity objects from having to “know” more than

is necessary to behave as entities

• Can do meaningful housekeeping

• Are easier to rewire than if interaction is spread

through the network

Entity objectsEntity objects

• Are the basic “domain” objects

• Find these first

• They are the things that tend to need to persist

• They usually become database tables

• Should know about their own behaviour

Boundary objectsBoundary objects

• Define interfaces

• Includes things like screens, web pages, sub-windows

• Separate interface from control and entity

A standard design pattern for A standard design pattern for interactive systemsinteractive systems

• There is an actor involved in the interaction

• There is a boundary object (e.g. screen) to which all

actor interactions are directed

• The boundary object passes on some requests to a

control object

• The control object deals with the entity objects

• The entity objects are stored as database tables

A standard design patternA standard design pattern

: ActorScreen Control Entity1 Entity2 Entity 3

A simpler design patternA simpler design pattern

• Merge the boundary and control class

• Normal for simple interactions

• Common way of working with simple packages like

Microsoft Access

A simpler design patternA simpler design pattern

: ActorScreen Entity1 Entity2 Entity 3

SummarySummary

• We have considered the three basic types of system object:

• Control

• Entity

• Boundary

• We have seen how to use each type properly to improve the design of a system.

• We can see how the objects would contribute to:– a relational database system

– an object based system.