Chapter 10, Mapping Models to Code
|
|
- Walter Morton
- 6 years ago
- Views:
Transcription
1 Chapter 10, Mapping Models to Code Using UML, Patterns, and Java Object-Oriented Software Engineering
2 Overview Object design is situated between system design and implementation. Object design is not very well understood and if not well done, leads to a bad system implementation. In this lecture, we describe a selection of transformations to illustrate a disciplined approach to implementation to avoid system degradation. 1. Operations on the object model: Optimizations to address performance requirements 2. Implementation of class model components: Realization of associations Realization of operation contracts 3. Realizing entity objects based on selected storage strategy Mapping the class model to a storage schema Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2
3 Characteristics of Object Design Activities Developers perform transformations to the object model to improve its modularity and performance. Developers transform the associations of the object model into collections of object references, because programming languages do not support the concept of association. If the programming language does not support contracts, the developer needs to write code for detecting and handling contract violations. Developers often revise the interface specification to accommodate new requirements from the client. All these activities are intellectually not challenging However, they have a repetitive and mechanical flavor that makes them error prone. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
4 State of the Art of Model-based Software Engineering The Vision During object design we would like to implement a system that realizes the use cases specified during requirements elicitation and system design. The Reality Different developers usually handle contract violations differently. Undocumented parameters are often added to the API to address a requirement change. Additional attributes are usually added to the object model, but are not handled by the persistent data management system, possibly because of a miscommunication. Many improvised code changes and workarounds that eventually yield to the degradation of the system. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4
5 Four types of transformations Model transformations operate on object models Refactoring source code transformations Forward Engineering changes in an object (e.g., attributes or associations) map into corresponding changes in source code Reverse Engineering the model space is defined based on existing source code Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5
6 Model transformations Forward engineering Refactoring Model transformation Reverse engineering Model space Source code space Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
7 Model Transformation Example Object design model before transformation LeagueOwner + address Advertiser + address Player + address Object design model after transformation: User + address LeagueOwner Advertiser Player Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7
8 Refactoring by pulling up a field Create a parent class that will hold the field that is factored out Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
9 Refactoring Example: Pull Up Field public class Player { private String ; //... public class LeagueOwner { private String ; //... public class Advertiser { private String _address; //... public class User { private String ; public class Player extends User { //... public class LeagueOwner extends User { //... public class Advertiser extends User { //... Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9
10 Refactoring by pulling up a constructor body Create a parent class that will assign a value to the field in common Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10
11 Refactoring Example: Pull Up Constructor Body public class User { private String ; public class Player extends User { public Player(String ) { this. = ; public class LeagueOwner extends User{ public LeagueOwner(String ) { this. = ; public class Advertiser extendsuser{ public Advertiser(String ) { this. = ; public class User { public User(String ) { this. = ; public class Player extends User { public Player(String ) { super( ); public class LeagueOwner extends User { public LeagueOwner(String ) { super( ); public class Advertiser extends User { public Advertiser(String ) { super( ); Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
12 Refactoring by pulling up methods The field and initialization in the constructor have been pulled up to the parent class Now see if any methods associated with can be moved to the parent class Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
13 Forward Engineering Example Object design model before transformation User + string +notify(msg:string) LeagueOwner +maxnumleagues:int Source code after transformation public class User { private String ; public String get () { return ; public void set (string value){ = value; public void 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 */ Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
14 Transformation principles Each transformation must address a single criteria Each transformation must be local Each transformation must be applied in isolation to other changes Each transformation must be followed by a validation step Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14
15 Other Mapping Activities Optimizing the Object Design Model Mapping Associations Mapping Contracts to Exceptions Mapping Object Models to Tables Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
16 Some optimizations Avoid frequent repeated association traversals Multiple association traversals can lead to code such as method1().method2().. methodn() The sequence diagram can be used to identify such traversals See if a direct connection is possible to improve efficiency Try to make many associations more efficient Try to use a qualified association to reduce multiplicity to one Try to use ordering or indexing to decrease access time Try to avoid misplaced attributes Inefficient due to the need for get and set methods Try bringing the attribute into the calling class Catch the result of expensive computations Example, statistics in the Arena example are only updated after a match is completed This only has to be calculated once at the end of each match and not repeatedly until another match is completed Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
17 Collapsing an object without interesting behavior Object design model before transformation Person SocialSecurity number:string Object design model after transformation Person SSN:String Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
18 Delaying expensive computations Object design model before transformation Image filename:string data:byte[] paint() Object design model after transformation Image filename:string paint() ImageProxy filename:string paint() image RealImage data:byte[] paint() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
19 Other Mapping Activities Optimizing the Object Design Model Mapping Associations Mapping Contracts to Exceptions Mapping Object Models to Tables Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
20 Realization of a unidirectional, one-to-one association Object design model before transformation Advertiser 1 1 Account Source code after transformation public class Advertiser { private Account account; public Advertiser() { account = new Account(); public Account getaccount() { return account; Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
21 Bidirectional one-to-one association Object design model before transformation Advertiser 1 1 Account Source code after transformation public class Advertiser { /* 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; public class 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; Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21
22 Bidirectional, one-to-many association Object design model before transformation 1 Advertiser * Account Source code after transformation 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); Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
23 Bidirectional, many-to-many association Object design model before transformation * {ordered * Tournament Player Source code after transformation public class Tournament { private List players; public Tournament() { players = new ArrayList(); public void 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); Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
24 Bidirectional qualified association Object design model before transformation League * * Player nickname Object design model before forward engineering League nickname * 0..1 Player Source code after forward engineering Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
25 Bidirectional qualified association (continued) Source code after forward engineering public class League { private Map players; public class Player { private Map leagues; public void addplayer (String nickname, Player p) { if (!players.containskey(nickname )) { players.put(nickname, p); p.addleague(nickname, this); public void addleague (String nickname, League l) { if (!leagues.containskey(l)) { leagues.put(l, nickname); l.addplayer(nickname, this); Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
26 Transformation of an association class Object design model before transformation Statistics +getaveragestat(name) +gettotalstat(name) +updatestats(match) Tournament * * Player Object design model after transformation: 1 class and two binary associations Statistics Tournament +getaveragestat(name) +gettotalstat(name) +updatestats(match) 1 1 * * Player Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
27 Other Mapping Activities Optimizing the Object Design Model Mapping Associations Mapping Contracts to Exceptions Mapping Object Models to Tables Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
28 Exceptions as building blocks for contract violations Many object-oriented languages, including Java do not include built-in support for contracts. However, we can use their exception mechanisms as building blocks for signaling and handling contract violations In Java we use the try-throw-catch mechanism Example: Let us assume the acceptplayer() operation of TournamentControl is invoked with a player who is already part of the Tournament. In this case acceptplayer() should throw an exception of type KnownPlayer. See source code on next slide Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
29 The try-throw-catch Mechanism 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 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 Bernd Bruegge the & Allen console H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29 ErrorConsole log(e getmessage());
30 Implementing a contract For each operation in the contract, do the following Check precondition: Check the precondition before the beginning of the method with a test that raises an exception if the precondition is false. Check postcondition: Check the postcondition at the end of the method and raise an exception if the contract is violoated. If more than one postcondition is not satisfied, raise an exception only for the first violation. Check invariant: Check invariants at the same time as postconditions. Deal with inheritance: Encapsulate the checking code for preconditions and postconditions into separate methods that can be called from subclasses. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
31 A complete implementation of the Tournament.addPlayer() contract «invariant» getmaxnumplayers() > 0 «precondition»!isplayeraccepted(p) Tournament -maxnumplayers: int +getnumplayers():int +getmaxnumplayers():int +isplayeraccepted(p:player):boolean +addplayer(p:player) «precondition» getnumplayers() < getmaxnumplayers() «postcondition» isplayeraccepted(p) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
32 The code Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
33 Heuristics for Mapping Contracts to Exceptions Be pragmatic, if you don t have enough time. Omit checking code for postconditions and invariants. Usually redundant with the code accomplishing the functionality of the class Not likely to detect many bugs unless written by a separate tester. Omit the checking code for private and protected methods. Focus on components with the longest life Focus on Entity objects, not on boundary objects associated with the user interface. Reuse constraint checking code. Many operations have similar preconditions. Encapsulate constraint checking code into methods so that they can share the same exception classes. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
34 Heuristics for mapping contracts to exceptions Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34
35 Other Mapping Activities Optimizing the Object Design Model Mapping Associations Mapping Contracts to Exceptions Mapping Object Models to Tables Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
36 Mapping an object model to a relational database UML object models can be mapped to relational databases: Some degradation occurs because all UML constructs must be mapped to a single relational database construct - the table. UML mappings Each class is mapped to a table Each class attribute is mapped onto a column in the table An instance of a class represents a row in the table A many-to-many association is mapped into its own table A one-to-many association is implemented as buried foreign key Methods are not mapped Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
37 Mapping the User class to a database table User +firstname:string +login:string + string User table id:long firstname:text[25] login:text[8] text[32] Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
38 Primary and Foreign Keys Any set of attributes that could be used to uniquely identify any data record in a relational table is called a candidate key. The actual candidate key that is used in the application to identify the records is called the primary key. The primary key of a table is a set of attributes whose values uniquely identify the data records in the table. A foreign key is an attribute (or a set of attributes) that references the primary key of another table. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
39 Example for Primary and Foreign Keys User table Primary key firstname alice john bob login am384 js289 bd Candidate key Candidate key League table name tictactoenovice tictactoeexpert chessnovice login am384 am384 js289 Foreign key referencing User table Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39
40 Buried Association Associations with multiplicity one can be implemented using a foreign key. For one-to-many associations we add a foreign key to the table representing the class on the many end. For all other associations we can select either class at the end of the association. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40
41 Buried Association Associations with multiplicity one can be implemented using a foreign key. Because the association vanishes in the table, we call this a buried association. For one-to-many associations we add the foreign key to the table representing the class on the many end. For all other associations we can select either class at the end of the association. 1 LeagueOwner * League LeagueOwner table League table id:long... id:long... owner:long Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41
42 Another Example for Buried Association Transaction transactionid * Foreign Key Portfolio portfolioid... transactionid Transaction Table portfolioid Portfolio Table portfolioid... Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42
43 Mapping Many-To-Many Associations In this case we need a separate table for the association City cityname * Serves * Airport airportcode airportname Separate table for Serves association Primary Key City Table Airport Table Serves Table cityname Houston Albany Munich Hamburg airportcode IAH HOU ALB MUC HAM airportname Intercontinental Hobby Albany County Munich Airport Hamburg Airport cityname Houston Houston Albany Munich Hamburg airportcode IAH HOU ALB MUC HAM Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43
44 Mapping the Tournament/Player association as a separate table Tournament * * Player Tournament table id name novice 24 expert TournamentPlayerAssociation table tournament player Player table id name alice 79 john Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44
45 Realizing Inheritance Relational databases do not support inheritance Two possibilities to map UML inheritance relationships to a database schema With a separate table (vertical mapping) The attributes of the superclass and the subclasses are mapped to different tables By duplicating columns (horizontal mapping) There is no table for the superclass Each subclass is mapped to a table containing the attributes of the subclass and the attributes of the superclass Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45
46 Realizing inheritance with a separate table name User LeagueOwner maxnumleagues Player credits id User table name... role 56 zoe LeagueOwner 79 john Player LeagueOwner table Player table id maxnumleagues... id credits Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46
47 Realizing inheritance by duplicating columns name User LeagueOwner maxnumleagues Player credits LeagueOwner table Player table id name maxnumleagues... id name credits zoe john 126 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47
48 Comparison: Separate Tables vs Duplicated Columns The trade-off is between modifiability and response time How likely is a change of the superclass? What are the performance requirements for queries? Separate table mapping We can add attributes to the superclass easily by adding a column to the superclass table Searching for the attributes of an object requires a join operation. Duplicated columns Modifying the database schema is more complex and error-prone Individual objects are not fragmented across a number of tables, resulting in faster queries Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48
49 Heuristics for Transformations For a given transformation use the same tool If you are using a CASE tool to map associations to code, use the tool to change association multiplicities. Keep the contracts in the source code, not in the object design model By keeping the specification as a source code comment, they are more likely to be updated when the source code changes. Use the same names for the same objects If the name is changed in the model, change the name in the code and or in the database schema. Provides traceability among the models Have a style guide for transformations By making transformations explicit in a manual, all developers can apply the transformation in the same way. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49
50 Summary Undisciplined changes => degradation of the system model Four mapping concepts were introduced Model transformation improves the compliance of the object design model with a design goal Forward engineering improves the consistency of the code with respect to the object design model Refactoring improves the readability or modifiability of the code Reverse engineering attempts to discover the design from the code. We reviewed model transformation and forward engineering techniques: Optiziming the class model Mapping associations to collections Mapping contracts to exceptions Mapping class model to storage schemas Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50
51 Statistics as a product in the Game Abstract Factory Tournament Game createstatistics() TicTacToeGame ChessGame Statistics update() getstat() TTTStatisticsChessStatisticsDefaultStatistics Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51
52 N-ary association class Statistics Statistics relates League, Tournament, and Player Statistics 1 * Game League Tournament Player Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52
53 Realization of the Statistics Association TournamentControl StatisticsView StatisticsVault Statistics update(match) update(match,playe getstatnames(game) getstatnames() getstat(name,game,player) getstat(name) getstat(name,league,player) getstat(name,tournament,player) Game createstatistics() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53
54 StatisticsVault as a Facade TournamentControl StatisticsView StatisticsVault Statistics update(match) getstatnames(game) getstat(name,game,player) getstat(name,league,player) getstat(name,tournament,player) update(match,player) getstatnames() getstat(name) Game createstatistics() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 54
55 Public interface of the StatisticsVault class 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 {... Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 55
56 Database schema for the Statistics Association Statistics table id:long scope:long scopetype:long player:long id:long StatisticCounters table name:text[25] value:double Game table League table Tournament table id:long... id:long... id:long... Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 56
57 Restructuring Activities Realizing associations Revisiting inheritance to increase reuse Revising inheritance to remove implementation dependencies Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 57
58 Realizing Associations Strategy for implementing associations: Be as uniform as possible Individual decision for each association Example of uniform implementation 1-to-1 association: Role names are treated like attributes in the classes and translate to references 1-to-many association: "Ordered many" : Translate to Vector "Unordered many" : Translate to Set Qualified association: Translate to Hash table Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 58
59 Unidirectional 1-to-1 Association Object design model before transformation ZoomInAction MapArea Object design model after transformation ZoomInAction MapArea -zoomin:zoominaction +getzoominaction() +setzoominaction(action) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 59
60 Bidirectional 1-to-1 Association Object design model before transformation ZoomInAction 1 1 MapArea Object design model after transformation ZoomInAction -targetmap:maparea +gettargetmap() +settargetmap(map) MapArea -zoomin:zoominaction +getzoominaction() +setzoominaction(action) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 60
61 1-to-Many Association Object design model before transformation Layer 1 * LayerElement Object design model after transformation Layer -layerelements:set +elements() +addelement(le) +removeelement(le) LayerElement -containedin:layer +getlayer() +setlayer(l) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 61
62 Qualification Object design model before transformation Scenario simname * 0..1 SimulationRun Object design model after transformation Scenario -runs:hashtable +elements() +addrun(simname,sr:simulationrun) +removerun(simname,sr:simulationrun) SimulationRun -scenarios:vector +elements() +addscenario(s:scenario) +removescenario(s:scenario) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 62
63 Increase Inheritance Rearrange and adjust classes and operations to prepare for inheritance Abstract common behavior out of groups of classes If a set of operations or attributes are repeated in 2 classes the classes might be special instances of a more general class. Be prepared to change a subsystem (collection of classes) into a superclass in an inheritance hierarchy. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 63
64 Building a super class from several classes Prepare for inheritance. All operations must have the same signature but often the signatures do not match: Some operations have fewer arguments than others: Use overloading (Possible in Java) Similar attributes in the classes have different names: Rename attribute and change all the operations. Operations defined in one class but no in the other: Use virtual functions and class function overriding. Abstract out the common behavior (set of operations with same signature) and create a superclass out of it. Superclasses are desirable. They increase modularity, extensibility and reusability improve configuration management Turn the superclass into an abstract interface if possible Use Bridge pattern Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 64
65 Object Design Areas 1. Service specification Describes precisely each class interface 2. Component selection Identify off-the-shelf components and additional solution objects 3. Object model restructuring Transforms the object design model to improve its understandability and extensibility 4. Object model optimization Transforms the object design model to address performance criteria such as response time or memory utilization. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 65
66 Design Optimizations Design optimizations are an important part of the object design phase: The requirements analysis model is semantically correct but often too inefficient if directly implemented. Optimization activities during object design: 1. Add redundant associations to minimize access cost 2. Rearrange computations for greater efficiency 3. Store derived attributes to save computation time As an object designer you must strike a balance between efficiency and clarity. Optimizations will make your models more obscure Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 66
67 Design Optimization Activities 1. Add redundant associations: What are the most frequent operations? ( Sensor data lookup?) How often is the operation called? (30 times a month, every 50 milliseconds) 2. Rearrange execution order Eliminate dead paths as early as possible (Use knowledge of distributions, frequency of path traversals) Narrow search as soon as possible Check if execution order of loop should be reversed 3. Turn classes into attributes Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 67
68 Implement Application domain classes To collapse or not collapse: Attribute or association? Object design choices: Implement entity as embedded attribute Implement entity as separate class with associations to other classes Associations are more flexible than attributes but often introduce unnecessary indirection. Abbott's textual analysis rules Every student receives a number at the first day in in the university. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 68
69 Optimization Activities: Collapsing Objects Student Matrikelnumber ID:String Student Matrikelnumber:String Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 69
70 To Collapse or not to Collapse? Collapse a class into an attribute if the only operations defined on the attributes are Set() and Get(). Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 70
71 Design Optimizations (continued) Store derived attributes Example: Define new classes to store information locally (database cache) Problem with derived attributes: Derived attributes must be updated when base values change. There are 3 ways to deal with the update problem: Explicit code: Implementor determines affected derived attributes (push) Periodic computation: Recompute derived attribute occasionally (pull) Active value: An attribute can designate set of dependent values which are automatically updated when active value is changed (notification, data trigger) Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 71
72 Optimization Activities: Delaying Complex Computations Image filename:string data:byte[] width() height() paint() Image filename:string width() height() paint() ImageProxy filename:string width() height() paint() image RealImage data:byte[] width() height() paint() Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 72
73 Increase Inheritance Rearrange and adjust classes and operations to prepare for inheritance Generalization: Finding the base class first, then the sub classes. Specialization: Finding the the sub classes first, then the base class Generalization is a common modeling activity. It allows to abstract common behavior out of a group of classes If a set of operations or attributes are repeated in 2 classes the classes might be special instances of a more general class. Always check if it is possible to change a subsystem (collection of classes) into a superclass in an inheritance hierarchy. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 73
74 Generalization: Building a super class from several classes You need to prepare or modify your classes for generalization. All operations must have the same signature but often the signatures do not match: Some operations have fewer arguments than others: Use overloading (Possible in Java) Similar attributes in the classes have different names: Rename attribute and change all the operations. Operations defined in one class but no in the other: Use virtual functions and class function overriding. Superclasses are desirable. They increase modularity, extensibility and reusability improve configuration management Many design patterns use superclasses Try to retrofit an existing model to allow the use of a design pattern Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 74
75 Implement Associations Two strategies for implementing associations: 1. Be as uniform as possible 2. Make an individual decision for each association Example of a uniform implementation (often used by CASE tools) 1-to-1 association: Role names are treated like attributes in the classes and translate to references 1-to-many association: Always Translate into a Vector Qualified association: Always translate into to Hash table Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 75
10. Mapping Models to Code
10. Mapping Models to Code Outline! Overview! Mapping Concepts! Mapping Activities! Case Study 1. Overview! Object design is situated between system design and implementation. Object design is not very
More informationChapter 9, Object Design: Specifying Interfaces
Chapter 9, Object Design: Specifying Interfaces Using UML, Patterns, and Java Object-Oriented Software Engineering Specifying Interfaces Requirements analysis activities Identifying attributes and operations
More informationChapter 10, Mapping Models to Relational Schema
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 10, Mapping Models to Relational Schema Lecture Plan Last lecture: Operations on the object model: Optimizations to address performance
More informationCSSE 490 Model-Based Software Engineering: Introduction to MetaModels
CSSE 490 Model-Based Software Engineering: Introduction to MetaModels Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu Learning Outcomes: Transformations Define
More informationLecture Notes on. Object Design. Object Design. Bill Scherlis / Bernd Brügge Software Engineering Fall October November 1999
v 8 September 1994 Lecture Notes on Object Design Object Design Bill Scherlis / Bernd Brügge 15-413 Software Engineering Fall 1999 21 October 1999 2 November 1999 Bruegge/Software 15-413 Software Engineering
More informationModel-Driven Architecture/ Development
CSSE 490 Model-Based Software Engineering: Shawn Bohner Model-Driven Architecture/ Development Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu Learning Outcomes: Transformations
More informationSoftware Engineering Fall 2014
Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 11/03/2014 Re Cap - Object Design Close the gap between the application objects and the off-the shelf components.
More informationCourse "Softwaretechnik" Book Chapters 9, 10 Object Design: Specifying Interfaces, Model-to-implementation mapping
Course "Softwaretechnik" Book Chapters 9, 10 Object Design: Specifying Interfaces, Model-to-implementation mapping Lutz Prechelt, Bernd Bruegge & Allen H. Dutoit Freie Universität Berlin, Institut für
More informationChapter 6, System Design Lecture 2
Object-Oriented Software Engineering Conquering Complex and Changing Systems Chapter 6, System Design Lecture 2 Preliminaries Guest lectures December 15: Andersen Consulting December 22: Viant January
More informationSoftware Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/03/2015
Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/03/2015 http://cs.gsu.edu/~ncasturi1 Object Design Software Engineering -CSC4350/6350 - Rao Casturi 2 Object Design Close
More informationChapter 9 Object Design: Specifying Interfaces
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9 Object Design: Specifying Interfaces Object Design Object design is the process of adding details to the requirements analysis
More informationFinal Exam. Final Exam Review. Ch 1: Introduction: Object-oriented analysis, design, implementation. Exam Format
Final Exam Final Exam Review CS 4354 Fall 2012 Jill Seaman Friday, December 14, 11AM Closed book, closed notes, clean desk Content: Textbook: Chapters 1, 2, 4-10 Java Lectures, GRASP + JUnit 35% of your
More information9. Object Design: Specifying Interfaces
9. Object Design: Specifying Interfaces Outline! An Overview of Object Design! Interface Specification Concepts! Interface Specification Activities 1. An Overview of Object Design Object Design! Object
More informationChapter 9, Object Design: Specifying Interfaces
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces Lecture Plan Specifying Interfaces (Chapter 9) Object Design Activities Visibilities and
More informationChapter 8, Object Design: Object Constraint Language
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 8, Object Design: Object Constraint Language Outline of the Lecture OCL Simple predicates Preconditions Postconditions Contracts
More informationChapter 8, Object Design: Reusing Pattern Solutions
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 8, Object Design: Reusing Pattern Solutions Application Objects and Solution Objects Application objects, also called domain objects,
More informationChapter 8, Object Design: Reuse and Patterns
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 8, Object Design: Reuse and Patterns Object Design Purpose of object design: Prepare for the implementation of the system model
More informationEINDHOVEN UNIVERSITY OF TECHNOLOGY
EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics & Computer Science Exam Programming Methods, 2IP15, Wednesday 17 April 2013, 09:00 12:00 TU/e THIS IS THE EXAMINER S COPY WITH (POSSIBLY INCOMPLETE)
More informationHow We Refactor, and How We Know It
Emerson Murphy-Hill, Chris Parnin, Andrew P. Black How We Refactor, and How We Know It Urs Fässler 30.03.2010 Urs Fässler () How We Refactor, and How We Know It 30.03.2010 1 / 14 Refactoring Definition
More informationCSE 70 Final Exam Fall 2009
Signature cs70f Name Student ID CSE 70 Final Exam Fall 2009 Page 1 (10 points) Page 2 (16 points) Page 3 (22 points) Page 4 (13 points) Page 5 (15 points) Page 6 (20 points) Page 7 (9 points) Page 8 (15
More informationChapter 5, Analysis: Object Modeling
Chapter 5, Analysis: Object Modeling Résumé Maintenant: Modélisation des objets du domaine La partie statique (diagramme de classe) Les activités durant la modélisation des objets L identification des
More informationSOFTWARE ENGINEERING SOFTWARE EVOLUTION. Saulius Ragaišis.
SOFTWARE ENGINEERING SOFTWARE EVOLUTION Saulius Ragaišis saulius.ragaisis@mif.vu.lt CSC2008 SE Software Evolution Learning Objectives: Identify the principal issues associated with software evolution and
More information5C. Examples of OCL in use, especially in "Object Design: Specifying Interfaces"
5C. Examples of OCL in use, especially in "Object Design: Specifying Interfaces" Note: This section is based heavily on Chapter 9 of the very useful text book Object- Oriented Software Engineering by Bruegge
More informationPROGRAMMING LANGUAGE 2
31/10/2013 Ebtsam Abd elhakam 1 PROGRAMMING LANGUAGE 2 Java lecture (7) Inheritance 31/10/2013 Ebtsam Abd elhakam 2 Inheritance Inheritance is one of the cornerstones of object-oriented programming. It
More informationChapter 11, Testing, Part 2: Integration and System Testing
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing
More informationDesign Patterns 2. Page 1. Software Requirements and Design CITS 4401 Lecture 10. Proxy Pattern: Motivation. Proxy Pattern.
Proxy : Motivation Design s 2 It is 3pm. I am sitting at my 10Mbps connection and go to browse a fancy web page from the US, This is prime web time all over the US. So I am getting 100kbps What can you
More informationObject-Oriented Programming
Object-Oriented Programming 3/18/14 Presentation for use with the textbook Data Structures and Algorithms in Java, 6th edition, by M. T. Goodrich, R. Tamassia, and M. H. Goldwasser, Wiley, 2014 Object-Oriented
More informationChapter 11, Testing, Part 2: Integration and System Testing
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing
More informationFault, Error, and Failure
Fault, Error, and Failure Testing, Quality Assurance, and Maintenance Winter 2018 Prof. Arie Gurfinkel based on slides by Prof. Lin Tan and others Terminology, IEEE 610.12-1990 Fault -- often referred
More informationChapter 8: Class and Method Design
Chapter 8: Class and Method Design Objectives Become familiar with coupling, cohesion, and connascence. Be able to specify, restructure, and optimize object designs. Be able to identify the reuse of predefined
More informationChapter 4 Requirements Elicitation
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 4 Requirements Elicitation Outline Today: Motivation: Software Lifecycle Requirements elicitation challenges Problem statement
More informationChapter 7, System Design: Addressing Design Goals
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 7, System Design: Addressing Design Goals Overview System Design I ü 0. Overview of System Design ü 1. Design Goals ü 2. Subsystem
More informationDesign Concepts and Principles
Design Concepts and Principles Analysis to Design Data Object Description Entity- Relationship Diagram Data Flow Diagram Process Specification (PSPEC) Component level design (or) procedural design Data
More informationIndex. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107
A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105
More informationChapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering
Chapter 11, Testing Using UML, Patterns, and Java Object-Oriented Software Engineering Outline Terminology Types of errors Dealing with errors Quality assurance vs Testing Component Testing! Unit testing!
More informationInheritance. Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L
Inheritance Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L 9.1 9.4 1 Inheritance Inheritance allows a software developer to derive
More informationChapter 5, Analysis: Dynamic Modeling
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 5, Analysis: Dynamic Modeling ü Requirements Elicitation (Ch.4) ü Introduction (Ch 1-3) OOSE- Galaxy ü Nonfunctional Requirements
More informationChapter 6 System Design: Decomposing the System
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 6 System Design: Decomposing the System Requirements Elicitation & Analysis results in; Non-functional requirements and constraints
More informationChapter 5, Analysis: Dynamic Modeling
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Analysis: Dynamic Modeling An overview of OOSE development activities and their products Problem Statement Requirements Elicitation
More informationLecture 20: Implementation () / 33
Lecture 20: Implementation 15.07.2013 () 15.07.2013 1 / 33 Contents Implementation Implementation Principles Example: Eight Queens by Refinement () 15.07.2013 2 / 33 Implementation Input: software architecture,
More informationSummary of the course lectures
Summary of the course lectures 1 Components and Interfaces Components: Compile-time: Packages, Classes, Methods, Run-time: Objects, Invocations, Interfaces: What the client needs to know: Syntactic and
More informationWhy Design by Contract! CS 619 Introduction to OO Design and Development. Design by Contract. Fall 2012
Why Design by Contract What s the difference with Testing? CS 619 Introduction to OO Design and Development Design by Contract Fall 2012 Testing tries to diagnose (and cure) defects after the facts. Design
More informationObject Design II: Design Patterns
Object-Oriented Software Engineering Using UML, Patterns, and Java Object Design II: Design Patterns Bernd Bruegge Applied Software Engineering Technische Universitaet Muenchen A Game: Get-15 The game
More informationTop Down Design vs. Modularization
6.170 Quiz Review Topics: 1. Decoupling 2. 3. AF & RI 4. Iteration Abstraction & Iterators 5. OMs and Invariants 6. Equality, Copying, Views 7. 8. Design Patterns 9. Subtyping 10. Case Studies Decomposition
More informationChapter 5, Object Modeling
Chapter 5, Object Modeling Using UML, Patterns, and Java Object-Oriented Software Engineering Where we are, where we are going problem statement Requirements elicitation Requirements Specification nonfunctional
More informationAssertions. Assertions - Example
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationPage 1. Chapter 8, Object Design: Design Patterns II. Recall: Why reusable Designs? Definitions. A Taxonomy of Design Patterns
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 8, Object Design: Design Patterns II Recall: Why reusable Designs? A design enables flexibility to change (reusability) minimizes
More informationChapter 11: Data Management Layer Design
Systems Analysis and Design With UML 2.0 An Object-Oriented Oriented Approach, Second Edition Chapter 11: Data Management Layer Design Alan Dennis, Barbara Wixom, and David Tegarden 2005 John Wiley & Sons,
More informationInheritance and Polymorphism
Object Oriented Programming Designed and Presented by Dr. Ayman Elshenawy Elsefy Dept. of Systems & Computer Eng.. Al-Azhar University Website: eaymanelshenawy.wordpress.com Email : eaymanelshenawy@azhar.edu.eg
More informationSoftware Engineering (CSC 4350/6350) Rao Casturi
Software Engineering (CSC 4350/6350) Rao Casturi Testing Software Engineering -CSC4350/6350 - Rao Casturi 2 Testing What is testing? Process of finding the divergence between the expected behavior of the
More informationIn this Lecture you will Learn: Object Design. Information Sources for Object Design. Class Specification: Attributes
In this Lecture you will Learn: Object Design Chapter 14 How to apply criteria for good design How to design associations The impact of integrity constraints on design How to design operations The role
More informationInheritance and Interfaces
Inheritance and Interfaces Object Orientated Programming in Java Benjamin Kenwright Outline Review What is Inheritance? Why we need Inheritance? Syntax, Formatting,.. What is an Interface? Today s Practical
More informationChapter 11, Testing, Part 2: Integration and System Testing
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 11, Testing, Part 2: Integration and System Testing Overview Integration testing Big bang Bottom up Top down Sandwich System testing
More informationCONTENTS. PART 1 Structured Programming 1. 1 Getting started 3. 2 Basic programming elements 17
List of Programs xxv List of Figures xxix List of Tables xxxiii Preface to second version xxxv PART 1 Structured Programming 1 1 Getting started 3 1.1 Programming 3 1.2 Editing source code 5 Source code
More informationChapter 2, lecture 2 Modeling with UML
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 2, lecture 2 Modeling with UML Overview: More detail on modeling with UML Use case diagrams Class diagrams Sequence diagrams Activity
More informationSoftware Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 09/29/2015
Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 09/29/2015 http://cs.gsu.edu/~ncasturi1 Class Announcements Grading is done for the Deliverable #2 (Requirement Elicitation)
More informationTutorial 02: Writing Source Code
Tutorial 02: Writing Source Code Contents: 1. Generating a constructor. 2. Generating getters and setters. 3. Renaming a method. 4. Extracting a superclass. 5. Using other refactor menu items. 6. Using
More informationType Hierarchy. Lecture 6: OOP, autumn 2003
Type Hierarchy Lecture 6: OOP, autumn 2003 The idea Many types have common behavior => type families share common behavior organized into a hierarchy Most common on the top - supertypes Most specific at
More informationProducts of Requirements elicitation and analysis. Chapter 6: System design: decomposing the system
Products of Requirements elicitation and analysis Chapter 6: System design: decomposing the system Requirements! elicitation! Requirements! Specification! nonfunctional! requirements! functional! model!
More informationHighlights of Previous Lecture
Highlights of Previous Lecture Final Project Goals 1. Set up collections of Flights 2. Maintain information about reservation availability on flights 3. Respond to reservation requests 4. Set up collections
More informationGoals of design. satisfies problem requirements, usable error free, resistant to incorrect input. readable, not purposefully cryptic.
OOP design revisited design revisited 1 Goals of design usable software robust implementable understandable reusable generalizable extendable solves the problem, satisfies problem requirements, usable
More informationChapter 10 Object-Oriented Design Principles
Chapter 10 Object-Oriented Design Principles Dr. Supakit Nootyaskool Faculty of Information Technology King Mongkut s Institute of Technology Ladkrabang Outline Object-oriented design: bridging from analysis
More informationReview sheet for Final Exam (List of objectives for this course)
Review sheet for Final Exam (List of objectives for this course) Please be sure to see other review sheets for this semester Please be sure to review tests from this semester Week 1 Introduction Chapter
More informationBCS Higher Education Qualifications. Diploma in IT. Object Oriented Programming Syllabus
BCS Higher Education Qualifications Diploma in IT Object Oriented Programming Syllabus Version 3.0 December 2016 This is a United Kingdom government regulated qualification which is administered and approved
More informationMore on Inheritance. Interfaces & Abstract Classes
More on Inheritance Interfaces & Abstract Classes Java interfaces A Java interface is used to specify minimal functionality that a client requires of a server. A Java interface contains: method specifications
More informationCS61BL Summer 2013 Midterm 2
CS61BL Summer 2013 Midterm 2 Sample Solutions + Common Mistakes Question 0: Each of the following cost you.5 on this problem: you earned some credit on a problem and did not put your five digit on the
More informationChapter 2, Modeling with UML, Part 2
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 2, Modeling with UML, Part 2 Outline of this Class What is UML? A more detailed view on Use case diagrams Class diagrams Sequence
More informationChapter 7, System Design: II Addressing Design Goals
Chapter 7, System Design: II Addressing Design Goals Overview System Design I 0. Overview of System Design 1. Design Goals 2. Subsystem Decomposition Architectural Styles System Design II 3. Concurrency
More informationC++ Important Questions with Answers
1. Name the operators that cannot be overloaded. sizeof,.,.*,.->, ::,? 2. What is inheritance? Inheritance is property such that a parent (or super) class passes the characteristics of itself to children
More informationPROCESS DEVELOPMENT METHODOLOGY The development process of an API fits the most fundamental iterative code development
INTRODUCING API DESIGN PRINCIPLES IN CS2 Jaime Niño Computer Science, University of New Orleans New Orleans, LA 70148 504-280-7362 jaime@cs.uno.edu ABSTRACT CS2 provides a great opportunity to teach an
More informationBCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT OBJECT ORIENTED PROGRAMMING
BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 5 Diploma in IT OBJECT ORIENTED PROGRAMMING Wednesady 23 rd March 2016 Afternoon Answer any FOUR questions out of SIX. All
More informationATTENTION TO COME/ISE 491/492 STUDENT
ATTENTION TO COME/ISE 491/492 STUDENT 151 As a part of your requirement analysis section in your final report, you should write a requirement analysis document (RAD). The details of the document, and a
More informationChapter 5, Analysis: Dynamic Modeling
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 5, Analysis: Dynamic Modeling ü Requirements Elicitation (Ch.4) ü Introduction (Ch 1-3) OOSE- Galaxy ü Nonfunctional Requirements
More informationClasses, interfaces, & documentation. Review of basic building blocks
Classes, interfaces, & documentation Review of basic building blocks Objects Data structures literally, storage containers for data constitute object knowledge or state Operations an object can perform
More informationObject Oriented Features. Inheritance. Inheritance. CS257 Computer Science I Kevin Sahr, PhD. Lecture 10: Inheritance
CS257 Computer Science I Kevin Sahr, PhD Lecture 10: Inheritance 1 Object Oriented Features For a programming language to be called object oriented it should support the following features: 1. objects:
More informationCO Java SE 8: Fundamentals
CO-83527 Java SE 8: Fundamentals Summary Duration 5 Days Audience Application Developer, Developer, Project Manager, Systems Administrator, Technical Administrator, Technical Consultant and Web Administrator
More informationUML class diagrams. Giuseppe Lipari June 8, Scuola Superiore Sant Anna Pisa
UML class diagrams Giuseppe Lipari http://retis.sssup.it Scuola Superiore Sant Anna Pisa June 8, 2009 Using UML Goal: Be able to reason about a design i.e., understand designer s intent Critique/improve
More informationECE 122. Engineering Problem Solving with Java
ECE 122 Engineering Problem Solving with Java Lecture 17 Inheritance Overview Problem: Can we create bigger classes from smaller ones without having to repeat information? Subclasses: a class inherits
More informationObject-Oriented Software Engineering Conquering Complex and Changing Systems. Chapter 6, System Design Lecture 1
Object-Oriented Software Engineering Conquering Complex and Changing Systems Chapter 6, System Design Lecture 1 Design There are two ways of constructing a software design: One way is to make it so simple
More informationITI Introduction to Computing II
ITI 1121. Introduction to Computing II Marcel Turcotte School of Electrical Engineering and Computer Science Inheritance Introduction Generalization/specialization Version of January 20, 2014 Abstract
More informationReferences: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationIntroduction to Software Engineering: Object Design I Reuse & Patterns
Introduction to Software Engineering: Object Design I Reuse & Patterns John T. Bell Department of Computer Science University of Illinois, Chicago Based on materials from Bruegge & DuToit 3e, Chapter 8,
More informationA - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models
CS 494 Object-Oriented Analysis & Design UML Class Models Overview How class models are used? Perspectives Classes: attributes and operations Associations Multiplicity Generalization and Inheritance Aggregation
More informationOutline. Subtype Polymorphism, Subtyping vs. Subclassing, Liskov Substitution Principle. Benefits of Subtype Polymorphism. Subtype Polymorphism
Subtype, Subtyping vs. Subclassing, Liskov Substitution Principle Outline Subtype polymorphism Subtyping vs. subclassing Liskov Substitution Principle (LSP) Function subtyping Java subtyping Composition:
More informationCourse "Softwaretechnik" Book Chapter 2 Modeling with UML
Course "Softwaretechnik" Book Chapter 2 Modeling with UML Lutz Prechelt, Bernd Bruegge, Allen H. Dutoit Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ Modeling,
More informationCHAPTER 11 Refactoring
CHAPTER 11 Refactoring Introduction When, Why, What? Which Refactoring Tools? Demonstration: Internet Banking Iterative Development Life-cycle Prototype Consolidation: design review Expansion: concurrent
More informationn HW5 out, due Tuesday October 30 th n Part 1: Questions on material we ll cover today n Part 2: BFS using your graph from HW4
Subtype, Subtyping vs. Subclassing, Liskov Substitution Principle Announcements n HW5 out, due Tuesday October 30 th n Part 1: Questions on material we ll cover today n Part 2: BFS using your graph from
More informationPractice Questions for Final Exam: Advanced Java Concepts + Additional Questions from Earlier Parts of the Course
: Advanced Java Concepts + Additional Questions from Earlier Parts of the Course 1. Given the following hierarchy: class Alpha {... class Beta extends Alpha {... class Gamma extends Beta {... In what order
More informationObject-Oriented Software Engineering Practical Software Development using UML and Java
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical
More informationProgram Correctness and Efficiency. Chapter 2
Program Correctness and Efficiency Chapter 2 Chapter Objectives To understand the differences between the three categories of program errors To understand the effect of an uncaught exception and why you
More informationSoftware Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/10/2015
Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/10/2015 http://cs.gsu.edu/~ncasturi1 Class announcements Final Exam date - Dec 1 st. Final Presentations Dec 3 rd. And
More informationChapter 13 Abstract Classes and Interfaces
Chapter 13 Abstract Classes and Interfaces 1 Abstract Classes Abstraction is to extract common behaviors/properties into a higher level in the class hierarch so that they are shared (implemented) by subclasses
More informationChapter 5 Object-Oriented Programming
Chapter 5 Object-Oriented Programming Develop code that implements tight encapsulation, loose coupling, and high cohesion Develop code that demonstrates the use of polymorphism Develop code that declares
More informationITI Introduction to Computing II
ITI 1121. Introduction to Computing II Marcel Turcotte School of Electrical Engineering and Computer Science Inheritance Introduction Generalization/specialization Version of January 21, 2013 Abstract
More informationWeek. Lecture Topic day (including assignment/test) 1 st 1 st Introduction to Module 1 st. Practical
Name of faculty: Gaurav Gambhir Discipline: Computer Science Semester: 6 th Subject: CSE 304 N - Essentials of Information Technology Lesson Plan Duration: 15 Weeks (from January, 2018 to April, 2018)
More informationComputer Science 2 Lecture 4 Inheritance: Trinidad Fruit Stand 02/15/2014 Revision : 1.7
Computer Science 2 Lecture 4 Inheritance: Trinidad Fruit Stand 02/15/2014 Revision : 1.7 1 Problem Ralph owns the Trinidad Fruit Stand that sells its fruit on the street, and he wants to use a computer
More informationBuilding Java Programs
Building Java Programs A Back to Basics Approach Stuart Reges I Marty Stepp University ofwashington Preface 3 Chapter 1 Introduction to Java Programming 25 1.1 Basic Computing Concepts 26 Why Programming?
More informationSoftware Engineering Fall 2014
Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 11/10/2014 Final Exam date - Dec 10 th? Class announcements Final Presentations Dec 3 rd. And Dec 8 th. Ability
More informationChapter 7, System Design: Addressing Design Goals
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 7, System Design: Addressing Design Goals Overview System Design I ü 0. Overview of System Design ü 1. Design Goals ü 2. Subsystem
More informationCMSC 132: Object-Oriented Programming II
CMSC 132: Object-Oriented Programming II Java Support for OOP Department of Computer Science University of Maryland, College Park Object Oriented Programming (OOP) OO Principles Abstraction Encapsulation
More information