CSCE 606:
From Models to
Implementation
Some material from Bruegge, Dutoit
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
10/3/2015
CSCE 606 Interfaces and Contracts
2
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)
10/3/2015
CSCE 606 Interfaces and Contracts
3
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)
10/3/2015
CSCE 606 Interfaces and Contracts
4
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
10/3/2015
CSCE 606 Interfaces and Contracts
5
Transformations
10/3/2015
CSCE 606 Interfaces and Contracts
6
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)
10/3/2015
CSCE 606 Interfaces and Contracts
7
Model Transformation
Example
• Object design model before transformation:
• Object design model after transformation:
10/3/2015
CSCE 606 Interfaces and Contracts
8
Same Transformation in Code:
Refactoring: Pull Up Field
public class Player {
public class User {
private String email;
private String email;
//...
}
}
public class Player extends User {
public class LeagueOwner {
//...
private String eMail;
}
//...
public class LeagueOwner extends User {
}
//...
public class Advertiser {
}
private String email_address;
public class Advertiser extends User {
//...
}
//...
}
10/3/2015
CSCE 606 Interfaces and Contracts
9
Refactoring Example: Pull Up
Constructor Body
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;
}
}
10/3/2015
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);
}
}
CSCE 606 Interfaces and Contracts
10
Refactoring
• Refactorings cataloged the same was ay
design patterns
• http://refactoring.com/catalog/index.html
• Many language IDEs offer powerful refactoring
tools
10/3/2015
CSCE 606 Interfaces and Contracts
11
Forward Engineering Example
10/3/2015
CSCE 606 Interfaces and Contracts
12
More Forward Engineering
Examples
• Forward Engineering
• Goal: Implementing the object design model in a
programming language
• Mapping inheritance
• Mapping associations
• Mapping contracts to exceptions
• Mapping object models to tables
10/3/2015
CSCE 606 Interfaces and Contracts
13
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
10/3/2015
CSCE 606 Interfaces and Contracts
14
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
10/3/2015
CSCE 606 Interfaces and Contracts
15
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
10/3/2015
CSCE 606 Interfaces and Contracts
16
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)
10/3/2015
CSCE 606 Interfaces and Contracts
17
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
10/3/2015
CSCE 606 Interfaces and Contracts
18
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)
10/3/2015
CSCE 606 Interfaces and Contracts
19
Delaying Expensive Operations
• Object design model before transformation:
• Object design model after transformation:
Proxy Pattern
10/3/2015
CSCE 606 Interfaces and Contracts
20
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:
•
•
•
•
•
•
10/3/2015
Overwriting of methods (default in Java)
Final classes
Final methods
Abstract methods
Abstract classes
Interfaces
CSCE 606 Interfaces and Contracts
21
Mapping Associations
1.
2.
3.
4.
5.
Unidirectional one-to-one association
Bidirectional one-to-one association
Bidirectional one-to-many association
Bidirectional many-to-many association
Bidirectional qualified association
10/3/2015
CSCE 606 Interfaces and Contracts
22
Unidirectional 1:1 Association
10/3/2015
CSCE 606 Interfaces and Contracts
23
Bidirectional 1:1 Association
10/3/2015
CSCE 606 Interfaces and Contracts
24
Bidirectional 1:N Association
10/3/2015
CSCE 606 Interfaces and Contracts
25
Bidirectional N:N Association
10/3/2015
CSCE 606 Interfaces and Contracts
26
Bidirectional Qualified
Association
10/3/2015
CSCE 606 Interfaces and Contracts
27
Bidirectional Qualified
Association (2)
10/3/2015
CSCE 606 Interfaces and Contracts
28
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
10/3/2015
CSCE 606 Interfaces and Contracts
29
Model-Driven Engineering (MDE)
• http://en.wikipedia.org/wiki/Model_Driven_Engineering
• 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.
10/3/2015
CSCE 606 Interfaces and Contracts
30
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
10/3/2015
CSCE 606 Interfaces and Contracts
31
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)
10/3/2015
CSCE 606 Interfaces and Contracts
32
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
10/3/2015
CSCE 606 Interfaces and Contracts
33
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 postconditions
• Deal with inheritance:
• Add the checking code for pre- and post-conditions into
methods that can be called from the class
10/3/2015
CSCE 606 Interfaces and Contracts
34
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
10/3/2015
CSCE 606 Interfaces and Contracts
35
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
10/3/2015
CSCE 606 Interfaces and Contracts
36
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)
10/3/2015
CSCE 606 Interfaces and Contracts
37
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
10/3/2015
CSCE 606 Interfaces and Contracts
38
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
10/3/2015
CSCE 606 Interfaces and Contracts
39
1:N Association
• Implemented as foreign key
10/3/2015
CSCE 606 Interfaces and Contracts
40
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
10/3/2015
CSCE 606 Interfaces and Contracts
41
Example: Keys
10/3/2015
CSCE 606 Interfaces and Contracts
42
Example: 1:N
Probably
okay
10/3/2015
CSCE 606 Interfaces and Contracts
43
1:1 Associations
10/3/2015
CSCE 606 Interfaces and Contracts
44
Foreign Key Can be Placed in
Either Table
10/3/2015
CSCE 606 Interfaces and Contracts
45
Navigation
• Previous tables corresponded to diagram on left
• (Fast) navigability in both directions may require
indices
10/3/2015
CSCE 606 Interfaces and Contracts
46
1:1: Possible to Represent as
One Table
10/3/2015
CSCE 606 Interfaces and Contracts
47
N:N Associations
10/3/2015
CSCE 606 Interfaces and Contracts
48
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
10/3/2015
CSCE 606 Interfaces and Contracts
49
Example Inheritance Hierarchy
10/3/2015
CSCE 606 Interfaces and Contracts
50
Vertical Mapping
10/3/2015
CSCE 606 Interfaces and Contracts
51
Horizontal Mapping
10/3/2015
CSCE 606 Interfaces and Contracts
52
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
10/3/2015
CSCE 606 Interfaces and Contracts
53
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
10/3/2015
CSCE 606 Interfaces and Contracts
54
Thoughts About Model-CodeDB 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
10/3/2015
CSCE 606 Interfaces and Contracts
55
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
10/3/2015
CSCE 606 Interfaces and Contracts
56
Summary
• Four mapping concepts
1. Model transformations
• Improve the compliance of the object design model with a design goal
2. Forward engineering
• Consistent transformation of models to code
3. Refactoring
• “Preserve semantics, improve readability/modifiability”
4. 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
10/3/2015
CSCE 606 Interfaces and Contracts
57
Descargar

Document