Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa OO A&D 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).

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Piece Special place Player Walk Card Place Flight An Initial Class Diagram Connected

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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!

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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).

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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. Walk Player Place

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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!

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa uses owns located contains play {ordered} cover end * * * ** * connected Piece Game Special place Treasure Player Map Card Place Flight Connection Classes And Associations

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Game ER Diagram Connected Treasur e Bandi t Player Place Special Place Jewel Card Is a CoversIs aLocatedOwnsFlightWalk M N M N M N N Piece Has

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Analysis Class Diagrams isAtAirport(): Boolean hasMoney(): Boolean getPlace(): Place move(p: Place) isWinner(): Boolean hasTreasure(): Boolean giveTreasure(): Treasure takeTreasure(t: Treasure) pay() clearFunds() Player name: String funds: Integer move(p: Place) getPlace(): Paikka Piece color: Integer 0..1 Card effect (p: Pelaaja) value: Integer TreasureJewel Bandit own use 0..1 Players addPlayer(n: String) nextPlayer(): Player treasurePlayer(p: Place): Player initialize() addPlayer(n: String) throwDice() movePlayer(p: Paikka) takeCard(p: Place) end() Game play throw(): Integer Dice {ordered} * 1 1 FlightTraffic getDestinations(p: Place): set of Place hasCard():Boolean giveCard() Place located * SpecialPlace NormalPlace FlightRoute place * 2 Map giveAdjacent(p: Place, n: Integer): set 1 * cover * follow In one relation In no relation

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Database Design Transform the ER model into an SQL database schema. You should know by now how to do it.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa From relations to objects 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 – University of Tampere, CS DepartmentJyrki Nummenmaa Relations-to-classes 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 – University of Tampere, CS DepartmentJyrki Nummenmaa 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”

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa UserPlayer 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

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Example: treasurePlayer(p: Place) 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 elsereturn nil

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa 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 end; return nil