Computer Sciences at the University of Tampere

Download Report

Transcript Computer Sciences at the University of Tampere

OO A&D FOR DATABASEDRIVEN SOFTWARE
University of Tampere, CS Department
Jyrki Nummenmaa
• 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).
Software Engineering – http://www.cs.uta.fi/se
An Initial Class Diagram
University of Tampere, CS Department
Jyrki Nummenmaa
Piece
Place
Player
Walk
Connected
Special place
Card
Software Engineering – http://www.cs.uta.fi/se
Flight
Associations? / 1
University of Tampere, CS Department
Jyrki Nummenmaa
• 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!
Software Engineering – http://www.cs.uta.fi/se
Associations? / 2
University of Tampere, CS Department
Jyrki Nummenmaa
• 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).
Software Engineering – http://www.cs.uta.fi/se
Associations? / 3
University of Tampere, CS Department
Jyrki Nummenmaa
• Suppose our class diagram shows associations:
Player
Place
Walk
• 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.
Software Engineering – http://www.cs.uta.fi/se
Database retrieval row-byrow?
University of Tampere, CS Department
Jyrki Nummenmaa
• 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!
Software Engineering – http://www.cs.uta.fi/se
Set-based database retrieval
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
Classes And Associations
University of Tampere, CS Department
Jyrki Nummenmaa
owns
uses
Piece
0..1
0..1
Player
0..1
0..1
Treasure
* {ordered}
play
1
*
located
Game
Special place
1
2
end
cover
0..1
1
contains
Place
*
*
1
Map
Card
*
Flight
Connection
*
connected
Software Engineering – http://www.cs.uta.fi/se
Game ER Diagram
University of Tampere, CS Department
Jyrki Nummenmaa
Connected
Flight
N
Located
Place
M
Walk
Special
Place
Covers
N
M
M
Is a
N
Card
N
Player
Is a
Is a
Is a
Piece
Jewel
Treasur
e
Software Engineering – http://www.cs.uta.fi/se
Has
Owns
Bandi
t
Analysis Class Diagrams
Player
Piece
color: Integer
University of Tampere, CS Department
Jyrki Nummenmaa
move(p: Place)
getPlace(): Paikka
Dice
throw(): Integer
In no
relation
1
use
0..1
Card
name: String
funds: Integer
effect (p: Pelaaja)
0..1 isAtAirport(): Boolean
hasMoney(): Boolean
*
getPlace(): Place
move(p: Place)
isWinner(): Boolean
hasTreasure(): Boolean
giveTreasure(): Treasure
located
takeTreasure(t: Treasure)
pay()
clearFunds()
*
own
0..1
0..1
Treasure
value: Integer
play
1
Players
1
addPlayer(n: String)
nextPlayer(): Player
treasurePlayer(p: Place):
Player
initialize()
addPlayer(n: String)
throwDice()
movePlayer(p: Paikka)
takeCard(p: Place)
end()
getDestinations(p: Place):
1
set of Place
Jewel
{ordered}
Game
FlightTraffic
Bandit
0..1
1
place
In one
relation
Place
hasCard():Boolean
giveCard()
cover
Map
*
follow
giveAdjacent(p: Place,
n: Integer): set<Paikka>
SpecialPlace
Software Engineering
– NormalPlace
http://www.cs.uta.fi/se
*
FlightRoute
*
2
Database Design
University of Tampere, CS Department
Jyrki Nummenmaa
• Transform the ER model into an SQL database schema.
• You should know by now how to do it.
Software Engineering – http://www.cs.uta.fi/se
From relations to objects
University of Tampere, CS Department
Jyrki Nummenmaa
• In ”traditional” OO methodology, so-called persistent objects
are stored in a database.
• 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”.
Software Engineering – http://www.cs.uta.fi/se
Relations-to-classes
University of Tampere, CS Department
Jyrki Nummenmaa
•
•
•
•
•
The main idea here is that we create OO classes for database
objects (not the other way round).
Notice that to use the database in a smart way, you will want to
add views to your database.
They are like predefined SQL queries, which can be used in
further queries.
They also require classes for accessing them.
The MVC model part implementation can often largely be based
on these classes.
Software Engineering – http://www.cs.uta.fi/se
Sequence Diagram for
”Take Card”
University of Tampere, CS Department
Jyrki Nummenmaa
Application
User
Choose to take card
Show player’s funds with one unit taken
Show Card
Show player’s funds with jewel value added
Software Engineering – http://www.cs.uta.fi/se
Sequence diagrams are ok
also here
University of Tampere, CS Department
Jyrki Nummenmaa
This is a new class
User
GameController
Choose to take card
Also a new class, but for a query
Player
CardForPlaceQuery
reduceFunds(price)
showFunds(p:Player)
getCard()
showCard(card)
addFunds(value)
showFunds(p:Player)
Software Engineering – http://www.cs.uta.fi/se
Operation design
University of Tampere, CS Department
Jyrki Nummenmaa
• 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.
Software Engineering – http://www.cs.uta.fi/se
Example: treasurePlayer(p:
Place)
University of Tampere, CS Department
Jyrki Nummenmaa
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
Software Engineering – http://www.cs.uta.fi/se
Example: treasurePlayer(p:
Place)
University of Tampere, CS Department
Jyrki Nummenmaa
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 = p
if result-set contains player_no
then return player_no
else
return nil
Software Engineering – http://www.cs.uta.fi/se
Example: treasurePlayer(p:
Place)
–
old
formulation
Reads:
University of Tampere, CS Department
Jyrki Nummenmaa
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
end
end;
return nil
Software Engineering – http://www.cs.uta.fi/se