1 / 31

Figure 10-1, Model transformations, refactorings, forward engineering, and reverse engineering.

Figure 10-1, Model transformations, refactorings, forward engineering, and reverse engineering. Forward engineering. Refactoring. Model transformation. Reverse engineering. Model space. Source code space. Figure 10-2, An example of an object model transformation.

chun
Télécharger la présentation

Figure 10-1, Model transformations, refactorings, forward engineering, and reverse engineering.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Figure 10-1, Model transformations, refactorings, forward engineering, and reverse engineering. Forward engineering Refactoring Modeltransformation Reverse engineering Model space Source code space

  2. Figure 10-2, An example of an object model transformation. Object design model before transformation LeagueOwner Advertiser Player +email:Address +email:Address +email:Address Object design model after transformation User +email:Address LeagueOwner Advertiser Player

  3. Before refactoring public class Player { private String email; //... } public class LeagueOwner { private String eMail; //... } public class Advertiser { private String email_address; //... } After refactoring public class User { private String email; } public class Player extends User { //... } public class LeagueOwner extends User { //... } public class Advertiser extends User { //... } Figure 10-3, Applying the Pull Up Field refactoring.

  4. Before refactoring public class User { private String email; } public class Player extends User { public Player(String email) { this.email = email; } } public class LeagueOwner extends User{ public LeagueOwner(String email) { this.email = email; } } public class Advertiser extends User{ public Advertiser(String email) { this.email = email; } } After refactoring public class User { public User(String email) { this.email = email; } } public class Player extends User { public Player(String email) { super(email); } } public class LeagueOwner extends User { public LeagueOwner(String email) { super(email); } } public class Advertiser extends User { public Advertiser(String email) { super(email); } } Figure 10-4, Pull Up Constructor Body refactoring.

  5. public class User { private String email; public String getEmail() { return email; } public void setEmail(String value){ email = value; } publicvoid notify(String msg) { // .... } /* Other methods omitted */ } public class LeagueOwner extends User { private int maxNumLeagues; public int getMaxNumLeagues() { return maxNumLeagues; } public void setMaxNumLeagues (int value) { maxNumLeagues = value; } /* Other methods omitted */ } Figure 10-5, Realization of User and LeagueOwner Object design model before transformation User LeagueOwner +email:String +maxNumLeagues:int +notify(msg:String) Source code after transformation

  6. Figure 10-6, Collapsing an object without interesting behavior into an attribute Object design model before transformation Person SocialSecurity number:String Object design model after transformation Person SSN:String

  7. Figure 10-7, Delaying expensive computations Object design model before transformation Image filename:String data:byte[] paint() Object design model after transformation Image filename:String paint() image RealImage ImageProxy 1 0..1 filename:String data:byte[] paint() paint()

  8. Figure 10-8, Realization of a unidirectional, one-to-one association public class Advertiser { private Account account; public Advertiser() { account = new Account(); } public Account getAccount() { return account; } } Object design model before transformation 1 1 Advertiser Account Source code after transformation

  9. public class Advertiser extends User{ /* The account field is initialized * in the constructor and never * modified. */ private Account account; public Advertiser() { account = new Account(this); } public Account getAccount() { return account; } } publicclass Account { /* The owner field is initialized * during the constructor and * never modified. */ private Advertiser owner; public Account(owner:Advertiser) { this.owner = owner; } public Advertiser getOwner() { return owner; } } Figure 10-9, Realization of a bidirectional one-to-one association Object design model before transformation 1 1 Advertiser Account Source code after transformation

  10. public class Advertiser { private Set accounts; public Advertiser() { accounts = new HashSet(); } public void addAccount(Account a) { accounts.add(a); a.setOwner(this); } public void removeAccount(Account a) { accounts.remove(a); a.setOwner(null); } } public class Account { private Advertiser owner; public void setOwner(Advertiser newOwner) { if (owner != newOwner) { Advertiser old = owner; owner = newOwner; if (newOwner != null) newOwner.addAccount(this); if (oldOwner != null) old.removeAccount(this); } } } Figure 10-10, Realization of a bidirectional, one-to-many association Object design model before transformation 1 * Advertiser Account Source code after transformation

  11. public class Tournament { private List players; public Tournament() { players = new ArrayList(); } publicvoid addPlayer(Player p) { if (!players.contains(p)) { players.add(p); p.addTournament(this); } } } public class Player { private List tournaments; public Player() { tournaments = new ArrayList(); } public void addTournament(Tournament t) { if (!tournaments.contains(t)) { tournaments.add(t); t.addPlayer(this); } } } Figure 10-11, Realization of a bidirectional, many-to-many association Object design model before transformation {ordered} * * Tournament Player Source code after transformation

  12. Figure 10-12, Realization of a bidirectional qualified association Object design model before transformation * * Player League Object design model before forward engineering * 0..1 League nickName Player

  13. public class League { private Map players; public void addPlayer (String nickName, Player p) { if (!players.containsKey(nickName)) { players.put(nickName, p); p.addLeague(nickName, this); } } } public class Player { private Map leagues; public void addLeague (String nickName, League l) { if (!leagues.containsKey(l)) { leagues.put(l, nickName); l.addPlayer(nickName, this); } } } Figure 10-12, Realization of a bidirectional qualified association (continued) Source code after forward engineering

  14. Figure 10-13, Transformation of an association class into an object and two binary associations Object design model before transformation Statistics + getAverageStat(name) + getTotalStat(name) + updateStats(match) Tournament Player * * Object design model after transformation Statistics + getAverageStat(name) + getTotalStat(name) + updateStats(match) 1 1 Tournament Player * *

  15. Figure 10-14, Example of exception handling in Java. public class TournamentControl { private Tournament tournament; public void addPlayer(Player p) throws KnownPlayerException { if (tournament.isPlayerAccepted(p)) { throw new KnownPlayerException(p); } //... Normal addPlayer behavior } } public class TournamentForm { private TournamentControl control; private ArrayList players; public void processPlayerApplications() { // Go through all the players who applied for this tournament for (Iteration i = players.iterator(); i.hasNext();) { try { // Delegate to the control object. control.acceptPlayer((Player)i.next()); } catch (KnownPlayerException e) { // If an exception was caught, log it to the console, and // proceed to the next player. ErrorConsole.log(e.getMessage()); } } } }

  16. «invariant» getMaxNumPlayers() > 0 Figure 10-15, A complete implementation of the Tournament.addPlayer() contract. Tournament -maxNumPlayers: int «precondition» !isPlayerAccepted(p) +getNumPlayers():int +getMaxNumPlayers():int +isPlayerAccepted(p:Player):boolean +addPlayer(p:Player) «precondition»getNumPlayers() <getMaxNumPlayers() «postcondition»isPlayerAccepted(p)

  17. Figure 10-16, An example of a relational table, with three attributes and three data records. Primary key User tab le fi r stName login email “alice” “am384” “am384@mail.org” “john” “js289” “john@mail.de” “bob” “bd” “bobd@mail.ch” Candidate key Candidate key

  18. Figure 10-17, An example of a foreign key. The owner attribute in the League table refers to the primary key of the User table in Figure 10-16. League table name login “tictactoeNovice” “am384” “tictactoeExpert” “am384” “chessNovice” “js289” Foreign key referencing User table

  19. Figure 10-18, Forward engineering of the User class to a database table User +firstName:String +login:String +email:String User table id:long firstName:text[25] login:text[8] email:text[32]

  20. Figure 10-19, Mapping of the LeagueOwner/League association as a buried association. 1 * LeagueOwner League LeagueOwner table League table id:long ... id:long ... o wner:long

  21. Figure 10-20, Mapping of the Tournament/Player association as a separate table. * * Tournament Player TournamentPlayerAssociation table Tournament table Player table id name ... tournament pla y er id name ... 23 no vice 23 56 56 alice 24 e xper t 23 79 79 john

  22. Figure 10-21, Realizing the User inheritance hierarchy with a separate table. User name LeagueOwner Player maxNumLeagues credits User table id name ... r ole 56 z oe LeagueOwner 79 john Pla y er LeagueOwner table Player table id maxNumLea gues ... id credits ... 56 12 79 126

  23. Figure 10-22, Realizing the User inheritance hierarchy by duplicating columns. User name LeagueOwner Player maxNumLeagues credits LeagueOwner table Player table id ... id ... name maxNumLeagues name credits 56 z oe 12 79 john 126

  24. Figure 10-23, Statistics as a product in the Game Abstract Factory Game Tournament createStatistics() TicTacToeGame ChessGame Statistics update() getStat() TTTStatistics ChessStatistics DefaultStatistics

  25. Figure 10-24, N-ary association class Statistics relating League, Tournament, and Player Statistics 1 * 1 1 0..1 0..1 0..1 0..1 Game League Tournament Player

  26. Figure 10-25, SimpleStatisticsVault object realizing the N-ary association of Figure 10-24. TournamentControl StatisticsView SimpleStatisticsVault Statistics getStatisticsObject(game,player) update(match,player) getStatisticsObject(league,player) getStatNames() getStatisticsObject(tournament,player) getStat(name) Game createStatistics()

  27. Figure 10-26, StatisticsVault as a Facade shielding the control and boundary objects from the Statistics storage and computation TournamentControl StatisticsView StatisticsVault Statistics update(match) update(match,player) getStatNames(game) getStatNames() getStat(name,game,player) getStat(name) getStat(name,league,player) getStat(name,tournament,player) Game createStatistics()

  28. Figure 10-27, Public interface of the StatisticsVault class (Java). public class StatisticsVault { public void update(Match m) throws InvalidMatch, MatchNotCompleted {...} public List getStatNames() {...} public double getStat(String name, Game g, Player p) throws UnknownStatistic, InvalidScope {...} public double getStat(String name, League l, Player p) throws UnknownStatistic, InvalidScope {...} public double getStat(String name, Tournament t, Player p) throws UnknownStatistic, InvalidScope {...} }

  29. Figure 10-28, Database schema for the Statistics N-ary association of Figure 10-24. Statistics table id:long scope:long scopetype:long player:long StatisticCounters table id:long name:text[25] v alue:double Game table Lea gue table T ournament table id:long ... id:long ... id:long ...

  30. Figure 10-29, Associations among Messages, Folders, Mailboxes, and Views in a hypothetical email client Mailbox Folder Message 1 * 1 * * * View

  31. Figure 10-30, Associations among League, Tournament, Round, and Player within ARENA League Tournament Round 1 * 1 * * * Player

More Related