OO ANALYSIS & DESIGN FOR DATABASE-DRIVEN SOFTWARE

15.1.2003 Software Engineering 2003Jyrki Nummenmaa

1

OO ANALYSIS & DESIGN FOR DATABASE-DRIVEN SOFTWARE

• Larger software products typically use a relational database or several of them.

• The databases may exist before the software is being built.

• New databases may be created.• Old databases may be modified, most typically

they are extended.• Often the database represents the biggest

permanent value (software changes on top of the same database).


2

uses owns

located

contains

play

{ordered}

cover end

0..1 0..1

0..1

2

*

*

*

**

*

connected

PiecePiece

GameGame Special placeSpecial place

TreasureTreasurePlayerPlayer

MapMap CardCardPlacePlaceFlight

ConnectionFlight

Connection

1

1

1

0..10..1

1

Classes And Associations


3

Game ER Diagram

Connected

Treasure Bandit

Player

Place

SpecialPlace

Jewel

Card

Is a Is a Is a

CoversIs a

Located

Owns

Flight

Walk

M

NM

N

M

NN

Piece

Has


4

Analysis Class Diagrams

isAtAirport(): BooleanhasMoney(): BooleangetPlace(): Placemove(p: Place)isWinner(): BooleanhasTreasure(): BooleangiveTreasure(): TreasuretakeTreasure(t: Treasure)pay()clearFunds()

Player

name: Stringfunds: Integermove(p: Place)

getPlace(): Paikka

Piececolor: Integer 0..1

Card

effect (p: Pelaaja)

value: Integer

Treasure JewelBanditown

use

0..1 0..1

Players

addPlayer(n: String)nextPlayer(): PlayertreasurePlayer(p: Place): Player

initialize()addPlayer(n: String)throwDice()movePlayer(p: Paikka)takeCard(p: Place)end()

Gameplay

1 1

0..1

0..1

throw(): Integer

Dice

{ordered}*

1

1

FlightTraffic

getDestinations(p: Place): set of Place

hasCard():BooleangiveCard()

Place

located

*

SpecialPlace NormalPlace

FlightRoute

place

*

2

Map

giveAdjacent(p: Place, n: Integer): set<Paikka>

1

*

cover

*

follow

In onerelation

In norelation


5

Database Design – Motivation 1

• This is not a database course, so doing the actual database design is not really our main concern here.

• However, it would be very good to have some expertise on this subject.

• If you do not know how a database should be designed, then find someone who does.

• Unfortunately, such people are not always easy to find.


6

Database Design – Motivation 2

• Many universities give quite little teaching on databases and data management.

• Ours gives quite a lot. Therefore, there may be strong expectations towards our students in this respect. (In other words, people may be hopeful that you might have some database skills!)

• Ok, so you have decided to study that issue more. • In the meantime, I will give a couple of alternative

database designs for our game application based on our ER diagram.


7

Database Design 1

• This design is based on the idea, that we want to have fewer relations.

• This will speed up processing.• There is nothing to say that the speed-up is

meaningful or necessary…• On the other, we end up with a database, which

may contain null values.• Null values are conceptually more difficult, that is,

more difficult to understand.• Design one:

http://www.cs.uta.fi/~jyrki/se04/game1/


8

Database Design 2

• This design is based on the idea, that we do not want to have null values.

• This will make things easier to understand.• However, we will end up with more relations.• Design two:

http://www.cs.uta.fi/~jyrki/se04/game2/• In this particular case, either design feels possible,

there is no strict reason to rule out either of them.• However, we will take Design 1 as our starting

point for software design.


9

From relations to objects

• We will probably want our software to access the data in the relations.

• Conceptually, it will be straightforward and understandable to have one class for each relation, to access the data.

• You may also design the classes differently, but then the connection between the relations and the objects will be more complicated.

• However, if the relations reflect your ER-diagram, then many of them will be quite close to ”intuitive objects”.


10

Relations-to-classes finetuning/1

• In fact, we may like to generate two classes for each relation. Assume that we have relation X(A,B,C)

1. A ”Db” class DbX, which has the attribute data includes methods for inserting, updating, deleting and retrieving a single row from relation X.

2. The ”real” class X, which inherits DbX. All the manually programmed code goes here.

• It may be possible to regenerate BaseX and DbX so that we do not need to change X!

• The database design examples contain also examples of Java source files to make database access easier for programming.


11

Relations-to-classes finetuning/2

• Why would we want to regenerate DbX?- Datatypes of attributes may change.- New attributes may be added or old attributes may be removed.

• What about our class diagram?- Suppose a project contains 100 relations.- The total number of methods in automatically generated classes is several hundreds.- We certainly want to generate some parts of our class diagrams automatically.


12

PiecePiece Special placeSpecial placePlayerPlayer

WalkWalk CardCardPlacePlace Flight Flight

An Initial Class Diagram

ConnectedConnected


13

Associations? / 1

• Based on our ER-diagram and the relation attributes, it would now be possible to add associations to the class diagram.

• Should we do so?• On the other hand, they give information about the

relationships between classes.• However, the associations are typically used for

navigation.• In a database-driven application, this may be a big

mistake!


14

Associations? / 2

• Consider, for instance, relations player and place. Suppose, for instance, that one player has a treasure and is two steps away from the starting place.

• We want to check up , whether any other player still has theoretical chances to win the game.

• Any such player needs to steal the treasure in at most two rounds.

• For this, we need to check all players, their places, and distances to the player with the treasure.

• Thus, we need to access at least relations player, place and walk (maybe also flight).


15

Associations? / 3

• Suppose our class diagram shows associations:

• Associations suggest navigation:for each player {

get pl=player.place for each pl.walk …

• Q: What would this mean?• A: It would mean database retrieval row-by-row.

WalkWalkPlayerPlayer PlacePlace


16

Database retrieval row-by-row?

• Each retrieval may mean scanning of a whole relation: O(n) operations, if relation has n rows.

• At best, it means traversing a search structure such as a search tree: O(log n) operations.

• Relational databases are meant for set-based retrieval: get all data in one query.

• Conclusion: The associations were misleading.• These kinds of stupid solutions just lead to poor

performance and some people may even imagine that the database is slow!


17

Set-based database retrieval

• Rather, make a query to retrieve all data in one go: select * from player, place, …

• Maybe make this definition into a view (which is like a predefined query).

• Define a new class for the query. The class does not need to have connections with place or player, although for the conceptual information it should.

• Use an object to go through the results of the query row by row, which means just one execution of the query in the database.


18

Architectural design

• Design the basic system architecture (in our example project we use servlets on top of a database).

• Identify the system components necessary for the architecture.

• Test your basic technological solutions (e.g., write one servlet, which accesses the database and …)

• Once you are sure that the architecture and the technological solutions are sound, move on to implementing the functionalities.


19

Design

• Study the requirement specification document and use cases with use case sequence diagrams.

• Choose a suitable set for the next increment.• Design the execution of a use cases/functionalities:

- If database needs to be accessed, add new classes for queries if the existing ones are not enough.- Add necessary classes that the system needs to to function (e.g. dice in our example).

• Implement, test, and get feedback from users/customers.


20

User

Application

Choose to take card

Show player’s funds with one unit taken

Show Card

Show player’s funds with jewel value added

Sequence Diagram for ”Take Card”


21

User Player

Choose to take card

showFunds(p:Player)

Sequence diagrams are ok also here

GameController

reduceFunds(price)

CardForPlaceQuery

getCard()

showFunds(p:Player)addFunds(value)

showCard(card)

This is a new class Also a new class, but for a query


22

Operation design

• At the bottom level, you will encounter similar tasks as in the OO design discussed in our earlier slides.

• You will need to do “classic” OO design for the non-database classes.

• There, the rules discussed on previous lectures apply.

• Take, as an example, operation design, which is discussed in the following slides.


23

Example: treasurePlayer(p: Place)

Class: Players Operation: treasurePlayer(p: Place): Player

Description:If there is a player in place p with the treasure,

returns that player.Result:

Returns player Q, for which Q.owns nil and Q.uses.located = p, if such Q exists,

otherwise nil. Assumes:

p nil


24

Example: treasurePlayer(p: Place) – database formulation

Reads:Player, Piece

Exceptions:Player has no piece.

Algorithm:SELECT player_no FROM player, place

WHERE player.place_no=place.place_no AND hasTreasure = true AND

place_no = pif result-set contains player_nothen return player_no

else return nil


25

Example: treasurePlayer(p: Place) – old formulation

Reads:Player, Piece

Exceptions:Player has no piece.

Algorithm:while players not processed do Q = unprocessed player; if Q.hasTreasure() then if Q.getPlace() == p then return Q end endend;return nil

Documents

OO ANALYSIS & DESIGN FOR DATABASE-DRIVEN SOFTWARE