Oriented Design 2. Contract Aware Components

Model-Driven Engineering with Contracts, Patterns, and Aspects*
Prof. Jean-Marc Jézéquel
(Univ. Rennes 1 & INRIA) Triskell Team @ IRISA
Campus de Beaulieu F-35042 Rennes Cedex Tel : +33 299 847 192 Fax : +33 299 847 171 e-mail : jezequel@irisa.fr http://www.irisa.fr/prive/jezequel
*This
work has been partially funded by the European IST project QCCS (IST 1999 20122)
Irisa / Triskell
http://www.irisa.fr/triskell
IST domain, public lab ? 5 sites ? 2100 Persons ? 100 teams
Rennes
Triskell Team (20 people):
OO Modeling (UML), MDA ? CBSE, Design by Contract ?AOD ? V&V
2
? J.-M. Jézéquel, 2003

Tutorial Outline
1. UML & Model Driven Architecture
4. Aspect Oriented Design 3. Design Patterns
2. Contract Aware Components
? J.-M. Jézéquel, 2003
3
I. Model Driven Engineering
–Context: modeling component-based systems –UML through one example –Modeling is Aspect-Oriented (by definition) –OMG’s Model Driven Architecture as a limited version of AOM

Modern Software Problems
n
Importance of non-functional properties
– distributed systems, parallel & asynchronous – quality of service : reliability, latency, performance...
n
Flexibility of functional aspects
– notion of product lines (space, time)
Versions (Time)
1.4 1.3 1.2 1.1 1.0
1.4 1.3 1.2 1.1 1.0
1.2
1.4 1.3
1.4 1.3 1.2 1.1 1.0
1.4 1.3 1.2 1.1 1.0
1.1
1.2 1.1
Time to Market!
1.0
1.0
? J.-M. Jézéquel, 2003
Variants (Fonctionalities)
5
OO approach: Models and Components
n
frameworks
? Changeable software, from distributed/unconnected sources even after delivery, by the end user ? Guarantees ?
Functional , synchronization, performance, QoS
? J.-M. Jézéquel, 2003
6

From the Object-Oriented Unification…
n n
From the object as the only one concept
– As e.g. in Smalltalk
To a multitude of concepts
– – – – – Collaborations Design patterns Components Middleware Aspects
? J.-M. Jézéquel, 2003
7
Collaborations
n n
Objects should be as simple as possible
– To enable modular understanding
But then where is the complexity?
– It is in the way objects interact! – Cf. Collaborations as a standalone diagram in UML
(T. Reenskaug’s works)
? J.-M. Jézéquel, 2003
8

Design Patterns
n
Embody architectural know-how of experts n As much about problems as about solutions
– pairs problem/solution in a context
n n
About non-functional forces
– reusability, portability, and extensibility…
Not about classes & objects but collaborations
– Actually, design pattern applications are parameterized collaborations
? J.-M. Jézéquel, 2003
9
It's difficult -- in fact, next to impossible – for a large enterprise to standardize on a single middleware platform. (R. Soley) COM+ DCOM HTTP HTML
Sun’s Java & EJB Microsoft C# & .Net
Middleware or Middle War?
z No clear winner until now z And probably not in the near future z Migration is expensive and disruptive
CORBA IIOP XML SOAP
Proprietary Middleware (eg. automotive)
z The OMG tried to send in the ‘’blue helmets’’ with the MDA initiative
+ until the next ultimate
? J.-M. Jézéquel, 2003
middleware platform (~2005)
11

Aspect Oriented Programming
n n
Kiczales et al., ECOOP’97
– MIT’s one of 10 key technologies for 2010
Encapsulation of cross-cutting concerns in OO programs
– Persistence, contract checking, etc.
n
Weaving at some specific points (join points) in the program execution
– Hence more than macros on steroids
n n
AspectJ for AOP in Java
– Some clumsiness in describing dynamic join points
What about Aspect Oriented Design ?
12
? J.-M. Jézéquel, 2003
Why modeling: master complexity
n
Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality.
n
Jeff Rothenberg.
? J.-M. Jézéquel, 2003
13

The World and the Model
A Model is a simplified representation of a subset of the World Consider modeling both the machine & its environment (M. Jackson)
<> Operator Device controls 1 start() 0..* stop() : Operator start( ) stop( )
: Device
M1
(modeling space)
Class diagram
Sequence diagram
ControllingSite TCP/IP RemoteSite : Device
: Operator
: Operator
UseCase diagram
Is represented by
Implementation diagram
M0
? J.-M. Jézéquel, 2003
(the world)
14
UML paved the way…
From Object-Oriented Programming to Model-Based Software Engineering
Model Driven Engineering
UML/MOF
OMT
SA/RT ERD
SADT
DFD JSD
? J.-M. Jézéquel, 2003
Merise
etc.
15
(From J. Bézivin)

UML: one model, 4 main dimensions, multiple views
: Device
<> Operator 1
Device controls start() 0..* stop()
: Operator start( ) stop( )
Class diagram
Sequence diagram
ControllingSite TCP/IP RemoteSite
: Device
: Operator
: Operator
UseCase diagram
? J.-M. Jézéquel, 2003
Implementation diagram
16
The 9 diagrams of UML
n
Modeling along 4 main viewpoints:
– Static Aspect (Who?)
? Describes objects and their relationships ? Structuring with packages
– User view (What?)
? Use cases
– Dynamic Aspects (When?)
? ? ? ? Sequence Diagram Collaboration Diagram State Diagram Activity Diagram
– Implementation Aspects (Where?)
? Component Diagram & deployment diagram
? J.-M. Jézéquel, 2003
17

Example
n
Modeling a (simplified) GPS device
– Get position, heading and speed
? by receiving signals from a set of satellites
– Notion of Estimated Position Error (EPE)
? Receive from more satellites to get EPE down
– User may choose a trade-off between EPE & saving power
? Best effort mode ? Best route (adapt to speed/variations in heading) ? PowerSave
? J.-M. Jézéquel, 2003
(Case Study borrowed from N. Plouzeau, K. Macedo & JP. Thibault. Big thanks to them)
18
Modeling a (simplified) GPS device
n
Use case diagram
GPS
switchON/OFF ?extends? setPrecision ?extends? getSpeed getPosition
User getInfo
?extends? getHeading
? J.-M. Jézéquel, 2003
19

Modeling a (simplified) GPS device
n
Class diagram
Satellite -Channel : int -Number : int -OrbitalCoordinates : Orbit +UpdateOrbit() 1 32
knows
PowerManagement -BatteryLevel : int -MainSupply : bool +GetLevel() : int +IsOnMainSupply() : bool 1 1 LocationComputer
Clock +GetTime() : Date +SetTime(in date : Date) 1
1
Receiver +SetChannel(in Channel : int) +GetData() : Data +DataReady() : bool 1 1
readsFrom
-Position : 3DPoint -EDE : double -/ Speed : double -/ Heading : double -Precision:{BestEffort, BestTrack, PowerSave } +SetEstimatePosition(in point : 3DPoint) +ConfigureDecoders() +GetPosition() : 3DPoint 1 1 {ordered} *
Decoder -SatTTime : Data -SatPosition : 3DPoint -SatDistance : double -DistancePrecision : double -IsActive : bool +ListenTo(in Channel : int) +Activate(in value : bool) +GetData() : Data +DataReady() : bool
route
12
3DPoint
? J.-M. Jézéquel, 2003
20
Modeling a (simplified) GPS device
n
Sequence diagram: configuring decoders
: LocationComputer : Decoder : Receiver
ConfigureDecoders() ListenTo(Channel) SetChannel(Channel)
? J.-M. Jézéquel, 2003
21

Modeling a (simplified) GPS device
n
Sequence diagram: interrupt driven architecture
: Decoder : Receiver
: LocationComputer
DataReady GetData return Data DataReady:=DataReady()
n
Many more sequence diagrams needed…
22
? J.-M. Jézéquel, 2003
Modeling a (simplified) GPS device
n
Targeting multiple products with the same (business) model
– – – – Hand held autonomous device Plug-in device for PalmTop Plug-in device for laptop (PCMCIA) May need to change part of the software after deployment
n
We choose a component based delivery of the software
? J.-M. Jézéquel, 2003
23

Modeling a (simplified) GPS device
n
Component diagram
<> <> <> <>
Receiver
?provided interfaces>> ReceiverI DataI
Decoder
?provided interfaces>> DecoderI DataI ? required interfaces? ReceiverI DataI
LocationComputer
?provided interfaces>> ComputerI ? required interfaces? PowerManagementI ClockI DecoderI DataI
Management
?provided interfaces>> PowerManagementI ClockI
ReceiverI
DecoderI
DataI
<> Decoder
DataI
Required port
? J.-M. Jézéquel, 2003
Provided Port
24
Modeling a (simplified) GPS device
n
Deployment diagram
?component? receiver1 : Receiver
ReceiverI, DataI
?component? Decoder1 : Decoder
DecoderI, DataI
?component? Receiver2 : Receiver
ReceiverI, DataI
?component? decoder2 : Decoder
DecoderI, DataI
?component? lc : LocationComputer
ComputerI
?component? receiver3 : Receiver
ReceiverI, DataI
?component? decoder3 : Decoder
ClockI, PowerManagementI DecoderI, DataI
?component? manager : Management
? J.-M. Jézéquel, 2003
25

Models: from contemplative to productive
Person -personID : unsigned long -surname : CString -givenName : CString -middleInitial : char -streetAddress : CString -postCode : CString -countryname : CString -eMailAddress : CString +Person() +PersonInfo()
class
Employee -jobType : CString -roomNr : unsigned long -department : CString -division : CString -jobTitle : CString -manager : unsigned long -headsDept : CString -headsDivision : CString -mobileNr : CString -birthDate : unsigned long +Employee() +GetCurrentAge() +EmployeeInfo() 1
CourseSession -courseSessionID : unsigned long -courseDate : unsigned long -courseID : unsigned long -courseLocation : CString +CourseSession() +CourseSessionInfo() 1 -is in
-teaches -is taught by
0..*
0..*
-is filled by
Applicant -companyName : CString -experience : CString -reference1 : CString -reference2 : CString -reference3 : CString +Applicant() +ApplicantInfo() +MakeApplication() 1 -is made by a-uses * 1 -is taken by -is made by
CourseRegistration -makes -registrationDate : unsigned long -completionFlag : bool -confirmedDate : unsigned long +CourseRegistration() +CourseRegistrationInfo()
1 RegistrationForm +registrationform() *
0..*
0..*
-takes
sequence
1..*
Test -made a Application -allows change in -has a -testScore : unsigned long +Test() +TestInfo() 0..* -gives
PermittedStatusChange -fromStatus : char -toStatus : char +PermittedStatusChange() +StatusChangeInfo()
Code Java
-productNr : unsigned long -certificationLevel : unsigned long -applicationDate : unsigned long +Application() +ApplicationInfo() 0..* Applicant
0..*
1..*
RegForm
ApplicantList
PersonList
-applies to a Application
ApplicationList
1 -is achieved
1
-is for a Exam -examID : unsigned long -certificationLevel : unsigned long +Exam() +ExamInfo() -uses -is used in
ExamSession -examSession : unsigned long -examlocation : CString -examDate : unsigned long +ExamSession() +ExamSessionInfo()
findApplicant()
AppStatus -statusCode : char -statusName : CString +AppStatus() +AppStatusInfo()
findPerson()
1
0..*
Applicant()
MakeApplication()
Application()
addApplication()
addPerson()
"from human-readable to computer-understandable"
? J.-M. Jézéquel, 2003
From J. Bézivin
26
Assigning Meaning to Models
n
If a UML model is no longer just
– fancy pictures to decorate your room – a graphical syntax for C++/Java/C#/Eiffel...
n
Then tools must be able to manipulate models
Contains ModelElement
+constrainedElement Constrains 0..*
– Let’s make a model of what a model is! – => meta-modeling
? & meta-meta-modeling..
0..1 +container {ordered} +containedElement
0..*
1.. *
Namespace
Feature
Constraint
+subtype Generalizes 0..* +supertype GeneralizableElement BehavioralFeature Struc turalFeature
{ordered} 0..* Package
Classifier
Operation
Reference 0..*
MofAttribute +referent
RefersTo Dat aType Class Association 1 +referencedEnd
AssociationEnd
? J.-M. Jézéquel, 2003
27

Modeling techniques at OMG: 3 steps
MOF
MOF
UML
UML
UML
SPEM
Workflow
etc.
aModel
aModel
UML_for_CORBA
Common Warehouse Metadata
aModel
Action language
1995
? J.-M. Jézéquel, 2003
1998
2001
28
Comparing Abstract Syntax Systems
Technology #1 Technology #2 (formal grammars (MOF + OCL) attribute grammars, etc.) Technology #3 (XML Meta-Language) Technology #4 (Ontology engineering)
M3 M2 M1
EBNF
MOF
A XML DTD Or Schema
Upper Level Ontologies
Pascal Language Grammar
The UML meta-Model
A XML document
A XML DTD or Schema
KIF Theories
A specific Pascal Program
A Specific UML Model
A XML document
A specific execution of a Pascal program
? J.-M. Jézéquel, 2003
A Specific phenomenon corresponding to a UML Model
+ Xlink, Xpath, XSLT + RDF, OIL, DAML + etc.
+Description Logics +Conceptual Graphs +etc.
[XMI=MOF+XML+OCL]
29
(From J. Bézivin)

MDA: the OMG new vision
"OMG is in the ideal position to provide the modelbased standards that are necessary to extend integration beyond the middleware approach… Now is the time to put this plan into effect. Now is the time for the Model Driven Architecture." Richard Soley & OMG staff, MDA Whitepaper Draft 3.2 November 27, 2000
? J.-M. Jézéquel, 2003
30
Mappings to multiple and evolving platforms
Platform neutral models based on UML & MOF
COM+ DCOM CORBA
Java EJB C# .Net
HTTP HTML XML SOAP
z MOF & UML as the core z Organization assets expressed as models z Model transformations to map to technology specific platforms
? J.-M. Jézéquel, 2003
31

The core idea of MDA: PIMs & PSMs
n
MDA models
– PIM: Platform Independent Model
? Business Model of a system abstracting away the implementation details of a system ? Example: the UML model of the GPS system
– PSM: Platform Specific Model
? Operational model including platform specific aspects ? Example: the UML model of the GPS system on .NET
n
Possibly expressed with a UML profile (.NET profile for UML)
– Not so clear about platform models
? Reusable model at various levels of abstraction
n
CCM, C#, EJB, EDOC, …
32
? J.-M. Jézéquel, 2003
A PSM for our GPS
n
Here, the platform is .NET
? J.-M. Jézéquel, 2003
33

How to go From PIM to PSM?
"just" weave the platform aspect ! n How can I do that?
n
– Through Model transformations – Now hot topic at OMG with RFP Q/V/T
? Query/View/Transformation
? J.-M. Jézéquel, 2003
34
Weaving aspects into UML Models?
n
It’s what Model Driven Architecture is about!
Modeling point of views Endomorphic Transformations Exomorphic Transformations Outside UML scope Proofs, QoS Analysis, Simulation Technical Aspects Business Aspects PIM PIM
Formal Models
Formal Models
PIM=Platform Independent Model PSM= Platform Specific Model
PIM
PSM Code Tests
PIM
PSM
Text (e.g. XML)
Doc
Doc
Doc
Doc
Doc
Doc Lifecycle
Requirements
Analysis
Architectural Design
Detailed Design
Implementation
Validation
? J.-M. Jézéquel, 2003
35

But many more dimensions in modeling!
n n
Beyond Design Model
– where UML is arguably good…
Business model n GUI model n Development process model n Performance & Resource model n Deployment model n Test model n Etc.
? J.-M. Jézéquel, 2003
36
How to take these dimensions into account?
Within UML, use built-in extension mechanisms to link with other semantic domains n Weave all these aspects into a design model
n
Domain model Service model Resource model
? J.-M. Jézéquel, 2003
Test model Design Model Installation model
37

Embedding implicit semantics into a model
Design pattern application (parametric collaboration)
invoker
Command pattern
receiver
S erviceProvider Interpreter execute() 1 +invoker 1..* 1..*
< > action_1() < > action_2() < > action_3()
Element stereotype
0..*
<

> History
…and also Tagged values & Contracts
? J.-M. Jézéquel, 2003
cmd_executed : string last_command() : string
38
…and the result we want...
ServiceProvider Interpreter
+commands ServiceProvider_Command +cmdTarget <> action_1() <> action_2() <> action_3()
execute() 0..* 1
1..*
do()
0..*
1
0..*
<> History
cmd_executed : string last_command() : string
action_1_cmd do()
action_2_cmd do()
action_3_cmd do()
+proxy
History_StorageProxy
load_last_command() : string store_last_command(cmd : string)
? J.-M. Jézéquel, 2003
39

How To: Automatic Model Transformations
ServiceProvider Interpreter execute() 1
0..* 1..* ServiceProvider_Command do() 0..* 1
<> action_1() <> action_2() <> action_3()
0..*
<> History
c m d_executed : str ing last_comm and() : string
action_1_cmd do()
action_2_cmd do()
action_3_cmd do()
Command pattern implementation
History_StorageProxy
load_last_comm and() : string store_last_command(cmd : string)
Persitence implementation
In some domains (e.g.; RT systems) transformations can get more complex than initial model! => must be managed with sound SE principles
40
? J.-M. Jézéquel, 2003
UML & Model Driven Architecture: Summary
n n n
Modeling to master complexity
– Multi-dimensional and aspect oriented by definition
Models: from contemplative to productive
– Meta-modeling tools
Model Driven Engineering
– Weaving aspects into a design model
? E.g. Platform Specificities
n
Model Driven Architecture (PIM / PSM): just a special case of Aspect Oriented Design
41
? J.-M. Jézéquel, 2003