1. CSCE 606: From Models to Implementation
Some material from Bruegge, Dutoit

2. CSCE 606 Interfaces and Contracts
Outline
From Object Model to Code
Mapping models to code
Operations on the object model:
Optimizations to address performance requirements
Implementation of class model components
Realization of associations
Realization of operation contracts
From Object Model to Persistent Data
Summary
11/11/2018
CSCE 606 Interfaces and Contracts

3. Development Activities
Improve modularity and performance
Transform associations into references, because programming languages do not support associations
Relations to functions
If the programming language does not support contracts, write code for detecting and handling contract violations (or leave as documentation)
11/11/2018
CSCE 606 Interfaces and Contracts

4. Model-Driven Engineering (MDE)
Vision
Object model realizes the use case, which directly maps to implementation (model-driven engineering)
Maybe implementation even generated
Reality
Model and code out of sync
Examples:
A new parameter added to an operation, only added to the source code, but not to the object model
Additional attributes are added to an entity object, but the data base table is not updated (as a result, the new attributes are not persistent)
11/11/2018
CSCE 606 Interfaces and Contracts

5. Object Model  Code; Issues
No direct language construct for UML associations
Transformed into collections of object references
Most languages do not support contracts (invariants, pre and post conditions)
Contracts manually transformed to error detection and handling code, asserts, etc. (or ignored)
If a model changes, effecting the same change in code is a manual process
11/11/2018
CSCE 606 Interfaces and Contracts

6. CSCE 606 Interfaces and Contracts
Transformations
11/11/2018
CSCE 606 Interfaces and Contracts

7. CSCE 606 Interfaces and Contracts
Model Transformation
Takes as input a model conforming to a meta model (for example the MOF metamodel) and produces as output another model conforming to the metamodel
Model transformations are used in MDA (Model Driven Architecture)
11/11/2018
CSCE 606 Interfaces and Contracts

8. Model Transformation Example
Object design model before transformation:
Object design model after transformation:
11/11/2018
CSCE 606 Interfaces and Contracts

9. Same Transformation in Code: Refactoring: 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 {
11/11/2018
CSCE 606 Interfaces and Contracts

10. 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 ) { public class Advertiser extends User{ public Advertiser(String ) {
public class User { public User(String ) { this. = ; } public class Player extends User { public Player(String ) { super( ); public class LeagueOwner extends User { public LeagueOwner(String ) { public class Advertiser extends User { public Advertiser(String ) {
11/11/2018
CSCE 606 Interfaces and Contracts

11. CSCE 606 Interfaces and Contracts
Refactoring
Refactorings cataloged the same was ay design patterns
Many language IDEs offer powerful refactoring tools
11/11/2018
CSCE 606 Interfaces and Contracts

12. Forward Engineering Example
11/11/2018
CSCE 606 Interfaces and Contracts

13. More Forward Engineering Examples
Goal: Implementing the object design model in a programming language
Mapping inheritance
Mapping associations
Mapping contracts to exceptions
Mapping object models to tables
11/11/2018
CSCE 606 Interfaces and Contracts

14. Reverse Engineering Example
Javadoc, Doxygen, …
Extract documentation from source code comments
Doxygen is open source, based on Oracle Javadoc
Roundtrip engineering
Move between a UML view and code at will
11/11/2018
CSCE 606 Interfaces and Contracts

15. CSCE 606 Interfaces and Contracts
Object Design Areas
Service specification
Describes precisely each class interface
Component selection
Identify off-the-shelf components and additional solution objects
Object model restructuring
Transforms the object design model to improve its understandability and extensibility
Object model optimization
Transforms the object design model to address performance criteria such as response time or memory utilization
11/11/2018
CSCE 606 Interfaces and Contracts

16. CSCE 606 Interfaces and Contracts
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:
Add redundant associations to minimize access cost
What are the most frequent operations? ( Sensor data lookup?)
How often is the operation called? (30 times/mo, every 50 ms)
As an object designer you must strike a balance between efficiency and clarity
Optimizations will make your models more obscure
11/11/2018
CSCE 606 Interfaces and Contracts

17. Object Design Optimizations (cont.)
Store derived attributes
Example: Define new classes to store information locally (database cache, proxy pattern)
Problem with derived attributes:
Derived attributes must be updated when base values change
3 ways to deal with the update problem:
Explicit code: Implementer 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 the active value is changed (observer pattern, data trigger)
11/11/2018
CSCE 606 Interfaces and Contracts

18. Model Transformations for Efficiency - Examples
Optimizing access paths
Possibly include redundant access paths
From “many” to “one” association through qualifications
Re-position attributes
Fold “uninteresting” attributes to calling class
Collapse objects (turn into attributes)
Delay expensive computations
Cache computation results
11/11/2018
CSCE 606 Interfaces and Contracts

19. CSCE 606 Interfaces and Contracts
Collapsing Objects
Object design model before transformation:
Object design model after transformation:
Turning an object into an attribute of another object is usually done if the object does not have any interesting dynamic behavior (only get/set operations)
11/11/2018
CSCE 606 Interfaces and Contracts

20. Delaying Expensive Operations
Object design model before transformation:
Object design model after transformation:
Proxy Pattern
11/11/2018
CSCE 606 Interfaces and Contracts

21. Forward Engineering: Mapping UML Model to Source Code
Goal: Translate UML-Model with inheritance - want to translate it into source code
Solution space: E.g. Java provides following mechanisms:
Overwriting of methods (default in Java)
Final classes
Final methods
Abstract methods
Abstract classes
Interfaces
11/11/2018
CSCE 606 Interfaces and Contracts

22. CSCE 606 Interfaces and Contracts
Mapping Associations
Unidirectional one-to-one association
Bidirectional one-to-one association
Bidirectional one-to-many association
Bidirectional many-to-many association
Bidirectional qualified association
11/11/2018
CSCE 606 Interfaces and Contracts

23. Unidirectional 1:1 Association
11/11/2018
CSCE 606 Interfaces and Contracts

24. Bidirectional 1:1 Association
11/11/2018
CSCE 606 Interfaces and Contracts

25. Bidirectional 1:N Association
11/11/2018
CSCE 606 Interfaces and Contracts

26. Bidirectional N:N Association
11/11/2018
CSCE 606 Interfaces and Contracts

27. Bidirectional Qualified Association
11/11/2018
CSCE 606 Interfaces and Contracts

28. Bidirectional Qualified Association (2)
11/11/2018
CSCE 606 Interfaces and Contracts

29. Summary: Implementing Associations
Strategy for implementing associations:
Be as uniform as possible
Individual decision for each association
Example of uniform implementation
1:1 association:
Role names are treated like attributes in the classes and translate to references
1:N association:
“Ordered many” : Translate to Vector
“Unordered many” : Translate to Set
Qualified association:
Translate to Hash table
11/11/2018
CSCE 606 Interfaces and Contracts

30. Model-Driven Engineering (MDE)
MDE refers to a range of development approaches based on the use of SW modeling as a primary form of expression. Sometimes models are constructed to a certain level of detail, and then code is written by hand in a separate step.
Sometimes complete models are built including executable actions. Code can be generated from the models, ranging from system skeletons to complete, deployable products.
With the introduction of UML, MDE has become very popular today with a wide body of practitioners and supporting tools. More advanced types of MDE have expanded to permit industry standards which allow for consistent application and results. The continued evolution of MDE has added an increased focus on architecture and automation.
MDE technologies with a greater focus on architecture and corresponding automation yield higher levels of abstraction in SW development. This abstraction promotes simpler models with a greater focus on problem space. Combined with executable semantics this elevates the total level of automation possible.
OMG has developed a set of standards called model-driven architecture (MDA), building a foundation for this advanced architecture-focused approach.
11/11/2018
CSCE 606 Interfaces and Contracts

31. CSCE 606 Interfaces and Contracts
MDE Historical View
First tools to support MDE were Computer-Aided Software Engineering (CASE) tools developed in 1980s
Companies like Integrated Development Environments (IDE - StP), Higher Order Software (now Hamilton Technologies, Inc., HTI), Cadre Technologies, Bachman Information Systems, and Logicworks (BP-Win and ER-Win) were pioneers
The government got involved in the modeling definitions creating the IDEF specifications.
New modeling languages (Booch, Rumbaugh, Jacobson, Ganes, Sarson, Harel, Shlaer, Mellor, others) led to Unified Modeling Language (UML)
Rational Rose was first dominant UML product, from Rational, now IBM
CASE had same problem that current MDA/MDE tools have today: model gets out of sync with source code
11/11/2018
CSCE 606 Interfaces and Contracts

32. CSCE 606 Interfaces and Contracts
Terminology Review
Roundtrip Engineering
Forward Engineering + reverse engineering
Inventory Analysis: determine  between object model and code
Together-J, Rationale,… provide tools for reverse engineering
Reengineering
Used in context of project management:
Providing new functionality (additional customer needs) in context of new technology (technology enablers)
11/11/2018
CSCE 606 Interfaces and Contracts

33. Implementing Contract Violations
Many OO languages do not have built-in support for contracts
Can use their exception mechanisms for signaling and handling contract violations
In Java we use the try-throw-catch mechanism
Example:
Assume acceptPlayer() operation of TournamentControl is invoked with a player who is already part of the Tournament
In this case acceptPlayer() in TournamentControl should throw an exception of type KnownPlayer
11/11/2018
CSCE 606 Interfaces and Contracts

34. Implementing a Contract
Check each pre-condition:
Check the pre-condition at beginning of method
Raise an exception if the pre-condition is false
Check each post-condition:
Check post-condition at end of method
Raise an exception if the post-condition is false. If more than one post-condition is false, raise an exception only for the first violation
Check each invariant:
Check invariants when checking pre- and post- conditions
Deal with inheritance:
Add the checking code for pre- and post-conditions into methods that can be called from the class
11/11/2018
CSCE 606 Interfaces and Contracts

35. Mapping Contracts to Exceptions
Checking code slows down your program
If too slow, omit the checking code for private and protected methods
If still too slow, focus on components with the longest life
Omit checking code for post-conditions and invariants for all other components
11/11/2018
CSCE 606 Interfaces and Contracts

36. CSCE 606 Interfaces and Contracts
Outline
From Object Model to Code
Mapping models to code
Operations on the object model:
Optimizations to address performance requirements
Implementation of class model components
Realization of associations
Realization of operation contracts
From Object Model to Persistent Data
Summary
11/11/2018
CSCE 606 Interfaces and Contracts

37. From Models to Persistent Data
Random complaint from somewhere:
“UML Overemphasizes programming jargon, ignores databases”
However, UML models can also be used for generating a schema for a relational database
Schema derivable from class diagrams
Relational database only has a single entity type: table
Some of UML class diagrams’ richer structure lost
Tools offer automation (to both directions)
11/11/2018
CSCE 606 Interfaces and Contracts

38. From Class Diagrams to Tables
Basics of the mapping
class mapped to a table
class attribute mapped to a column of a table
instance of a class is a row of a table
1:1 association mapped to a foreign key
or two classes coalesced to one table
1:N association mapped to a foreign key
N:N association mapped to a table of its own
No counterpart for methods
Object identity implicitly serves as a unique “key” in UML class diagrams
It may be necessary to add an explicit identity attribute to a table corresponding to a class
11/11/2018
CSCE 606 Interfaces and Contracts

39. Example: Class to Table
This table might be OK w/o an ID attribute
Name seldom changes
OTOH, refs from other tables need to use the (relatively long) NAME
Decisions on representing data must be made
Constraints in the model, and eventually code, need to be updated to reflect the decisions
11/11/2018
CSCE 606 Interfaces and Contracts

40. CSCE 606 Interfaces and Contracts
1:N Association
Implemented as foreign key
11/11/2018
CSCE 606 Interfaces and Contracts

41. CSCE 606 Interfaces and Contracts
Reminder: Keys
Candidate Key A set of attributes that uniquely identifies a row of a table Primary Key One of the candidate keys selected to be used as the key of the table Foreign Key Set of attributes that references the primary key of another table
11/11/2018
CSCE 606 Interfaces and Contracts

42. CSCE 606 Interfaces and Contracts
Example: Keys
11/11/2018
CSCE 606 Interfaces and Contracts

43. CSCE 606 Interfaces and Contracts
Example: 1:N
Probably okay
11/11/2018
CSCE 606 Interfaces and Contracts

44. CSCE 606 Interfaces and Contracts
1:1 Associations
11/11/2018
CSCE 606 Interfaces and Contracts

45. Foreign Key Can be Placed in Either Table
11/11/2018
CSCE 606 Interfaces and Contracts

46. CSCE 606 Interfaces and Contracts
Navigation
Previous tables corresponded to diagram on left
(Fast) navigability in both directions may require indices
11/11/2018
CSCE 606 Interfaces and Contracts

47. 1:1: Possible to Represent as One Table
11/11/2018
CSCE 606 Interfaces and Contracts

48. CSCE 606 Interfaces and Contracts
N:N Associations
11/11/2018
CSCE 606 Interfaces and Contracts

49. CSCE 606 Interfaces and Contracts
Inheritance
No construct that would correspond to inheritance in relational databases
Two common approaches for mapping an inheritance association to a database schema
Vertical Mapping
Different tables for superclass and subclass attributes
If n subclasses, n + 1 tables
Horizontal Mapping
Subclass tables contain base attributes
No table for the base class
11/11/2018
CSCE 606 Interfaces and Contracts

50. Example Inheritance Hierarchy
11/11/2018
CSCE 606 Interfaces and Contracts

51. CSCE 606 Interfaces and Contracts
Vertical Mapping
11/11/2018
CSCE 606 Interfaces and Contracts

52. CSCE 606 Interfaces and Contracts
Horizontal Mapping
11/11/2018
CSCE 606 Interfaces and Contracts

53. CSCE 606 Interfaces and Contracts
Comparison
Trade-off between modifiability and response time
Are changes likely in the superclass?
Performance requirements for queries?
Vertical mapping
Adding attributes to superclass easy
Accessing all attributes of employee or manager requires a join
Horizontal mapping
Changes to superclass result in more complex schema modifications
Objects not fragmented across several tables  faster queries
11/11/2018
CSCE 606 Interfaces and Contracts

54. CSCE 606 Interfaces and Contracts
OODBMS, NoSQL, …
Alternatives to Relational Database
May offer a more direct mapping between a model and persistent data
Joins not needed (nor offered)
Access through pointers
Navigability fixed
OODBMS:
Programming language and database schema use the same type definitions
11/11/2018
CSCE 606 Interfaces and Contracts

55. Thoughts About Model-Code-DB Mappings
Consistency important
Codify the process, always do in the same way
Use tools
Avoiding replicating information is beneficial
Edited in one space, generated to other spaces
If lots of replication, information will get out of sync
11/11/2018
CSCE 606 Interfaces and Contracts

56. CSCE 606 Interfaces and Contracts
Outline
From Object Model to Code
Mapping models to code
Operations on the object model:
Optimizations to address performance requirements
Implementation of class model components
Realization of associations
Realization of operation contracts
From Object Model to Persistent Data
Summary
11/11/2018
CSCE 606 Interfaces and Contracts

57. CSCE 606 Interfaces and Contracts
Summary
Four mapping concepts
Model transformations
Improve the compliance of the object design model with a design goal
Forward engineering
Consistent transformation of models to code
Refactoring
“Preserve semantics, improve readability/modifiability”
Reverse engineering
“Extract design from code”
Model transformations and forward engineering techniques
“Optimizing” within the class model
Mapping associations to collections
Mapping contracts to exceptions
Mapping class model to storage schemas
11/11/2018
CSCE 606 Interfaces and Contracts