Upload
efrem
View
27
Download
1
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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).
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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/
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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”.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
12
PiecePiece Special placeSpecial placePlayerPlayer
WalkWalk CardCardPlacePlace Flight Flight
An Initial Class Diagram
ConnectedConnected
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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!
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.1.2003 Software Engineering 2003Jyrki Nummenmaa
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
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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!
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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”
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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.
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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
15.1.2003 Software Engineering 2003Jyrki Nummenmaa
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