Cours

1
Ingénierie des Modèles Logiciels Cours 2 Sur
l'intégration, l'interopérabilitéles espaces
technologiqueset les modèles Jean
BézivinJean.Bezivin_at_irin.univ-nantes.fr Equipe
ATLAS (INRIA IRIN), Nantes
2
Plan du cours 1

• La problématique générale de lintégration
• Les modèles
• Les espaces technologiques

3
Aspects de l'intégration

• Intégration

4
Intégration

• Intégrer
• Faire fonctionner ensemble, dans un tout
  répondant à un objectif précis, des éléments qui
  n'ont pas été conçus spécifiquement pour réaliser
  cet objectif.
• Exemple
• Enterprise Application Integration (EAI)
• The process of adapting a system to make
  applications work together when they would
  otherwise be incompatible.
• Dictionary Of Database And Related Technology

5
Intégration

• integration ?inti'grei??nnoun1  the act of
  combining or adding parts to make a unified
  whole2  the act of amalgamating a racial or
  religious group with an existing community3  the
  combination of previously racially segregated
  social facilities into a nonsegregated system4 
  (Psychol)  organization into a unified pattern,
  esp. of different aspects of the personality into
  a hierarchical system of functions5  the
  assimilation of nutritive material by the body
  during the process of anabolism6  (Maths)  an
  operation used in calculus in which the integral
  of a function or variable is determined the
  inverse of differentiation"inte'grationist noun

6
Intégration de systèmes

• system integration The progressive linking and
  testing of system components to merge their
  functional and technical characteristics into a
  comprehensive, interoperable system.
• Note Integration of data systems allows data
  existing on disparate systems to be shared or
  accessed across functional or system boundaries.

7
Intégration la définition de "WhatIs"

• Integration (from the Latin integer, meaning
  whole or entire) generally means combining parts
  so that they work together or form a whole. In
  information technology, there are several common
  usages
• 1) Integration during product development is a
  process in which separately produced components
  or subsystems are combined and problems in their
  interactions are addressed.
• 2) Integration is an activity by companies that
  specialize in bringing different manufacturers'
  products together into a smoothly working system.
  
• 3) In marketing usage, products or components
  said to be integrated appear to meet one or more
  of the following conditions
• A) They share a common purpose or set of
  objectives. (This is the loosest form of
  integration.)
• B) They all observe the same standard or set of
  standard protocol or they share a mediating
  capability, such the Object Request Broker (ORB)
  in the Common Object Request Broker Architecture
  (CORBA).
• C) They were all designed together at the same
  time with a unifying purpose and/or architecture.
  (They may be sold as piece-parts but they were
  designed with the same larger objectives and/or
  architecture.)
• D) They share some of the same programming code.
• E) They share some special knowledge of code
  (such as a lower-level program interface) that
  may or may not be publicly available. (If not
  publicly available, companies have been known to
  sue to make it available in order to make
  competition fair.)
• In describing its Internet Information Manager
  (IIS), Microsoft says that it is "tightly
  integrated," apparently meaning that it meets
  conditions (A), (B), to some extent (C), possibly
  a bit of (D), and, if any, an unstated amount of
  (E).

8
Différentes formes d'intégration

• Il y a différentes formes d'intégration
• Intégration de systèmes
• Intégration de produits
• Intégration de code
• Intégration de services
• Intégration d'applications
• Intégration de données
• etc.
• L'intégration de modèles
• recouvre une grande partie de ces préoccupations
• organise de façon homogène de nombreuses
  techniques utilisées dans ces différents domaines
• permet des transferts de techniques

9
OMG le bus logiciel et le bus de code.
OMA
Java
CORBA, IDL, IIOP, ...
Cobol
MDA
UML
CWMI
MOF, UML, XML, ...
Workflow
Software Process
De l'interopérabilité de code à
l'interopérabilité de modèles
10
OMG

• Il n'y aura jamais de système unique, de langage
  unique, de système unique, de SGBD unique, de
  réseau unique, etc.
• La seule caractéristique dont on soit certain
  c'est l'hétérogénéité
• La recherche de l'interopérabilité est une
  activité qui ne peut devenir que de plus en plus
  importante.

11
Deux formes d'intégration

• Intégration dans l'espace
• Exemple CORBA
• Double intégration
• Distribution Géographique
• Hétérogénéité des langages
• Mais aussi
• Hétérogénéité des machines
• Hétérogénéité des systèmes
• Hetérogénéité des réseaux
• Intégration dans le temps
• Création en juin 2003 du WG legacy transformation
  à Paris
• Différentes façons de faire interopérer des
  applications du passé, du présent et du futur

12
La modélisation

• Modèles

13
Sur la modélisation

• 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.
• "The Nature of Modeling."
• Jeff Rothenberg
• in Artificial Intelligence, Simulation, and
  Modeling,
• L.E. William, K.A. Loparo, N.R. Nelson, eds.
• New York, John Wiley and Sons, Inc., 1989, pp.
  75-92

http//poweredge.stanford.edu/BioinformaticsArchiv
e/PrimarySite/NIHpanelModeling/RothenbergNatureMod
eling.pdf
14
Ne pas confondre le modèle et le système

• La pipe de Magritte
• L'image de la pipe ne permet pas de fumer
• L'image de la pipe permet de raisonner sur la
  pipe (design, constitution, etc.) au niveau de
  l'instance ou du concept.

modelOf
15
La mappemonde est un modèle de la terre
modelOf
16
La mappemonde est un modèle de la terre

• Permettant de poser certaines questions

• mais pas d'autres.

17
Une histoire de moutons et de cailloux
18
Une histoire de moutons et de cailloux

• Once upon a time, in a deep valley of Sicily, the
  shepherd Antonio lived in a small house, in front
  of a bridge. He was in charge of an important
  herd of sheep. The bridge crossing the river was
  the only possibility to go from one bank to the
  opposite one. The sheep could freely move from
  the south bank to the north bank, but it was
  difficult to keep track of how many animals were
  on one side of the river at a given time. Antonio
  was a very wise and well-organized person and he
  decided to keep two heaps of black pebbles on
  each side of his cabin's door, a place from where
  he could survey any traffic on the bridge. For
  each sheep crossing from north to south, he
  transferred a stone from the left heap to the
  right heap, and vice versa.

19
Une histoire de moutons et de cailloux

• When asked how many animals were on the south
  bank, Antonio had not to go finding them on the
  ground and counting them, but he just counted the
  number of stones in the right heap and could
  immediately give the answer.

20
Une histoire de moutons et de cailloux

• Year after year Antonio managed his small
  business in a much more reactive way than his
  cousin Alfonso, a few valleys away. He
  progressively learnt how to adapt to small
  changes in the day-to-day operations of sheep
  breeding. When a sheep died or was sold, a stone
  was simply withdrawn from the corresponding heap.
  In the spring, Antonio similarly recorded all
  newborn lambs by adding stones to the
  corresponding heap.
• But times were hard in these ages for the small
  farmer and Antonio decided an important business
  change growing cattle in addition to sheep. To
  handle this, he went to the big town of Palermo
  to get advice on the best way to extend his
  business. He consulted many knowledgeable people
  and was proposed a number of different solutions
  like the Greek Salamis tablet, the Etruscan
  tablet, the roman hand abacus, the Japanese
  Soroban, the Chinese Suan Pan, the Russian cët
  and many reckoning boards and counting tables. .
  
• The learning curve to switch to these new
  technologies was rather steep, although all
  consultants kindly proposed to help for a very
  reasonable fee. Antonio was not sure however the
  return on investment of moving to these
  fashionable technologies would be guaranteed and
  he decided to stick with his old stone-oriented
  technology and he became persuaded that this was
  sufficiently extensible to handle his business
  evolution. He found in the river some white
  pebbles and he decided to use them to represent
  cattle. He kept black pebbles to represent sheep,
  so the migration to his new management system was
  quite easy.

21
Une histoire de moutons et de cailloux
22
Une histoire de moutons et de cailloux

• The mental process that led Antonio to imagine
  this organization is rather complex and consists
  of these three phases
• a) make a clear and concise model of his business
  (sheep, herd, etc.) ,
• b) make a clear and concise model of the resource
  space that could help him manage the business
  (stones, heaps, etc.) ,
• c) make a precise correspondence between the
  domain space (a) and the resource space (b).
• Building a correspondence between the domain
  space and the resource space (c) is particularly
  difficult. For each event occurring in the domain
  space (for example a sheep crossing from North
  bank to South bank), a corresponding action
  should be defined in the resource space (a stone
  moved from the left to the right heap).

23
Une histoire de moutons et de cailloux

• What is beginning to appear is that Antonio has
  been building three different models
• a model of the herds,
• a model of the heaps
• and a model of the mapping between the heaps and
  the herds.
• This situation may be globally represented as in
  next slide. In the upper part of we find these
  three models. In the lower part we find the three
  parts of the real world that are the sources of
  these models.

24
Une histoire de moutons et de cailloux

• In the previous slide the distinction is made
  clear between the model of the coupling and the
  actual coupling itself. Antonio watching the
  bridge and detecting a sheep crossing and then
  taking the initiative of moving a stone from one
  heap to another one realizes the coupling itself.
  This is rather naïve and oversimplified. For
  example what happens when Antonio go to sleep?
  One possibility would be to guarantee that no
  sheep crossing occurs during these periods, for
  example by temporarily closing the bridge.
  Another solution could be to hire a helper that
  would handle the task whenever Antonio is not
  available.

25
Une histoire de moutons et de cailloux

• Several centuries later, a descendant of Antonio
  is handling a highly automated farm. All animals
  have a Java chip grafted under the skin that
  records their alimentation, their history, their
  vaccines, their medical record, etc. The move
  from one place to another place of each
  individual animal is automatically tracked by the
  computer system. Total traceability is nearly
  achieved. However the grand-grand-son of Antonio
  is still asking the same problems
• a)       How to make the business model more
  accurate?
• b)       How to cope with ever-changing
  technologies?
• c)       How to map the business model on the
  resource model?
• The Windows or the Linux resource space that is
  now used to drive high performance Pentium 5
  computers are much more complex than the old heap
  of stones. However the principle of mapping
  (coupling) the model of a sheep with a model of
  main memory bytes or rotating disk sectors
  follows similar principles. The business model
  (domain) has not much changed in nature compared
  to the resource model.

26
Le cycle de vie des modèles

• Model construction is not instantaneous. Let us
  take an example to illustrate this.
• Suppose you are arriving for the first time in a
  given town, for example Seattle, Wa., to attend a
  conference. The downtown hotel where you are
  staying gives you some indications on how to go
  to the conference, where to go shopping or dining
  out in the evening, etc.
• All the actions that you will undertake like
  going to visit a museum may be carried out
  successfully and expediently if preceded by a
  planning phase where a model will be built (map
  of downtown).
• In the absence of such a model or with a too
  imprecise or even wrong model, the walk to a
  particular place may take a very long time.

27
Le cycle de vie des modèles

• As your stay in Seattle goes on, your model of
  the area become more and more precise and your
  travels to interesting spots take less time.
• Your knowledge of the town is being progressively
  enriched and updated. The corresponding mental
  model you have built is composed of entities (the
  Convention Center, the Financial District, the
  Space Center, your Hotel, the Art Museum, Pine
  Street, 1st Avenue, etc.).
• It is also composed of facts that you are
  constantly adding, assessing and using like the
  observation that 3rd Avenue is parallel to 1st
  Avenue and perpendicular to Pine street, that
  Pine street lead to Pike Place Market and that
  your hotel is near the intersection of Pine
  street and 7th Avenue.

28
Le cycle de vie des modèles

• At some time you may buy a downtown-walking map.
  This is a model of previous experience by other
  people and you are buying this experience to
  validate and to enrich your own knowledge.
• As you continue to visit the town, you may get a
  map of the public transportation (buses, monorail
  and underground). This data will also contribute
  to enrich you operational knowledge.
• What is interesting is that you will weave the
  information contained in different maps (walking
  map and public transportation map) by connecting
  joint points in the different models.
• Of course this is made possible because the
  different maps are models of the same system (the
  city of Seattle). At some time you may even use a
  bike and find convenient to use a specialized map
  indicating recommended routes.

29
Le cycle de vie des modèles

• In the left bottom part of the bike route map,
  there is a rectangle area providing the "legend".
  
• This is what we'll call later a meta-model since
  it defines the meaning of the various icons
  appearing in the model (the map). It's the key to
  interpreting the map as a description of the real
  territory.
• Answering a question about the time it will take
  to walk or bike from the Space Needle to Pike
  Place Market requires the legend information that
  four centimeters on the map corresponds to 500
  meters on the ground. Applying a shortest path
  algorithm to the map is then easy and will lead
  to the requested answer.
• Building a company business information system is
  a progressive operation, similar to building a
  personal map of Seattle.

30
Le cycle de vie des modèles résumé

• The example maps taken in the previous section
  may help us illustrating some key points on
  modeling. Let us summarize and generalize here
  some observations just made that could apply to
  general models as well as to maps.
• The first idea is that a map is a graphical model
  of a given territory. Graphics artifacts may ease
  cognitive tasks by using elements and spatial
  relations among them to re present abstract or
  concrete facts about a specific portion of the
  real or imagined world.
• Another idea is that here are several kinds of
  maps (walking, public transportation, road map,
  etc.). Each map has a specific intended usage and
  is build for some specific purpose.
• The (graphical) language of a map is defined by a
  legend, which is attached to the map (loosing the
  legend may render the map quite useless). The
  legend is itself written in a graphical language
  that is left implicit (lines and boxes mainly).
• Another finding is that maps may be progressively
  elaborated. At some time a map may be wrong
  (Christopher Columbus used wrong maps that he
  helped to correct). Maps may be considered as
  assets that may help to transfer expertise
  between different people and different contexts.
• Usually original models like maps may not be
  elaborated automatically, but automatic means may
  help to build them. An aerial photograph does not
  make a good map, but it may help to elaborate it.
  
• One common idea is that more a map is precise,
  more useful it is. This may bear some truth but
  should be taken with caution. The writer Jorge
  Luis Borges records the following story. Two
  competing teams of geographer were competing in
  building more and more accurate maps of a given
  country. At one time one of the team won by
  providing maps with the exact dimension of the
  territory, on a scale of one to one. At the exact
  time these maps achieved maximum precision they
  also lost any practical utility.
• A map represents a given territory but a map is
  different from the territory. It is a model of a
  system.

31
Le modèle d'un modèle
Carte routière au 1/50 000 de la région de Seattle
Région de Seattle
modelOf
repOf
/modelOf
Carte routière au 1/100 000 de la région de
Seattle

• A map may represent a given territory with a
  certain perspective.
• It has a certain scale, for example the map A of
  the Seattle area at 1/50 000.
• If we take a map of the same area at a different
  scale, this may be considered either
• as a map B of the same Seattle territory or
  alternatively as a model of map A.
• As illustrated, a model of a model may be thus
  apparently be a model.

32
Opérations plus complexes
33
La légende de la carte
34
Différentes sortes de modèles
modèle
La carte est un modèle statique d'un système
statique. Autre exemple, un recensement.
système
35
Les espaces technologiques

• Espacestechnologiques

36
les espaces technologiques

• Un espace technologique (ET) correspond à
• Un contexte de travail
• Un ensemble de concepts
• Un ensemble de méthodes
• Un ensemble d'outils
• Un savoir et un savoir-faire partagés
• Un ET est en général associé à une certaine
  communauté possédant une expertise commune, des
  pratiques communes et éventuellement des
  problématiques de recherche partagées
• Pourquoi traiter ici des ET ?
• Parce qu'il va y avoir des transformations
  intra-espace et extra-espace
• Parce qu'il est nécessaire de disposer d'un cadre
  global clair pour travailler efficacement
• Parce que l'on aura à répondre de l'intérêt de
  faire certaines transformations dans l'espace MDA
  alors que l'on aurait pu utiliser d'autres
  transformateurs disponibles dans d'autres
  espaces.
• etc.

37
Exemples d'espaces technologiques

• On peut considérer cinq espaces importants
• Syntaxes concrètes et abstraites des langages de
  programmation,
• Ingénierie ontologique,
• Ingénierie des document (XML),
• SGBD,
• MDA.
• D'autres ET existent

38
Espaces composites les technologies sont
structurées

• Les technologies sont structurées,
• Sous-familles composites ou alternatives

Programming languages
Logic
Object Oriented
Middleware Platforms
Java EJB
CORBA
XSLT
Operating Systems
XLINK
XML
XPATH
etc.
39
Similarité des ET

• Un ET est organisé autour d'un ensemble de
  concepts
• Les ET sont reliés par des ponts
• Les ET sont organisés structurellement de façon
  assez similaire.

40
Comparaison des espaces technologiques
Technologie 2 (MOF OCL)
Technologie 3 (XML Meta-Language)
Technologie 4 (Ontology engineering)
Technologie 1 (formal grammars attribute
grammars, etc.)
M3
A XML DTD Or Schema
EBNF
Upper Level Ontologies
MOF
M2
Pascal Language Grammar
The UML meta-Model
A XML document
A XML DTD or Schema
KIF Theories
Description Logics Conceptual Graphs etc.
M1
A specific Pascal Program
A XML document
A Specific UML Model
Xpath, XSLT RDF, OIL, DAML etc.
A specific execution of a Pascal program
A Specific phenomenon corresponding to a UML Model
SGBD
41
Exemple d'un méta-modèle Java élémentaire
42
Exemple de pont Java/JavaML

• import java.applet.
• import java.awt.
• public class FirstApplet extends Applet
• public void paint(Graphics g)
• g.drawString("FirstApplet", 25, 50)

Java source code
1 lt?xml version"1.0" encoding"UTF-8"?gt 2
lt!DOCTYPE java-source-program SYSTEM
"java-ml.dtd"gt 4 ltjava-source-program
name"FirstApplet.java"gt 5 ltimport
module"java.applet."/gt 6 ltimport
module"java.awt."/gt 7 ltclass
name"FirstApplet" visibility"public"gt 8
ltsuperclass class"Applet"/gt 9 ltmethod
name"paint" visibility"public" id"meth-15"gt
10 lttype name"void" primitive"true"/gt 11
ltformal-argumentsgt 12 ltformal-argument
name"g" id"frmarg-13"gt 13 lttype
name"Graphics"/gtlt/formal-argumentgt 14
lt/formal-argumentsgt .
JavaML document
43
JavaML

• Classes et méthodes sont des éléments XML.
• Structure représentée par l imbrication des
  éléments.
• Java -gt JavaML
• Développé à partir du IBM Jikes Compiler
  Framework.
• Ajout de méthodes à chaque nud de l AST.
• JavaML -gt Java
• Feuille de style XSLT.

44
Recoder Un exemple de transformateur de l'ET
Java

• RECODER is a Java framework for source code
  metaprogramming aimed to deliver a sophisticated
  infrastructure for many kinds of Java analysis
  and transformation tools.
• RECODER allows to transform code. Another toy
  program illustrates this. When applied to the
  example program,this obfuscator produces a very
  interesting result. Note that the modified
  program compiles and behaves as before.
• Transformation of Java sources RECODER contains
  a library of small analyses, code snippet
  generators and frequently used transformations.
• Possible applications Preprocessors for language
  extensions, semantic macros, aspect weavers,
  source code obfuscation tools, compilers

45
Trois ET en parallèle
MDA TS
Program TS
XML TS
Outil interne
Recoder
XSLT
MIA
XSLT
Outil externe
Jikes
46
Velocity untransformateur de l'ET syntaxique

• Velocity est un moteur de substitution, basé sur
  Java. Il permet aux concepteurs de pages web de
  faire référence à des méthodes définies dans du
  code Java. Les concepteurs de pages peuvent
  travailler en équipe avec des programmeurs Java
  pour développer des sites web dans l'architecture
  MVC (Modèle-Vue-Contrôleur), ce qui signifie que
  les infographistes peuvent se concentrer sur la
  création d'un site au désign attractif et les
  programmeurs peuvent se consacrer entièrement à
  l'écriture de code de qualité. Velocity sépare le
  code Java des pages web, ce qui rend le site plus
  facile à maintenir dans le long terme et fournit
  une alternative réaliste aux Java Server Pages
  (JSPs) ou à PHP.
• Velocity peut être utilisé pour générer des pages
  web, du SQL, du Postcript et tout ce qui peut
  être généré à partir d'un gabarit. Vous pouvez
  l'utiliser comme un utilitaire indépendant pour
  générer du code source ou des états imprimés, ou
  bien comme un composant intégré dans d'autres
  systèmes. A terme, Velocity fournira les services
  d'inclusion pour le framework d'applications web
  Turbine. Velocity et Turbine fournissent un
  service d'inclusion qui permettra de développer
  des applications WEB dans une véritable
  architecture MVC.

47
Exemple Velocity

• ltHTMLgt
• ltBODYgt
• Hello customer.Name!
• lttablegt
• foreach( mud in mudsOnSpecial )
• if ( customer.hasPurchased(mud) )
• lttrgt
• lttdgt
• flogger.getPromo( mud )
• lt/tdgt
• lt/trgt
• end
• end
• lt/tablegt

48
Velocity vs. XSLT
49
Un exemple de transformation dans l'espace Prolog
XIV ? 14

• Arabe2Romain(U,W) -
• tr(U,?,M,D,C,L,X,V,I, W).
• tr(, S, ).
• tr(U o 0, S o V,I, W) -
• dif(0 o U, U o 0), tr(U, S, W).
• tr(U o 1, S o V,I, W o I) - tr(U, S, W).
• tr(U o 2, S o V,I, W o I,I) - tr(U, S, W).
• tr(U o 3, S o V,I, W o I,I,I) - tr(U, S,
  W).
• tr(U o 4, S o V,I, W o I,V) - tr(U, S, W).
• tr(U o 5, S o V,I, W o V) - tr(U, S, W).
• tr(U o 6, S o V,I, W o V,I) - tr(U, S, W).
• tr(U o 7, S o V,I, W o V,I,I) - tr(U, S,
  W).
• tr(U o 8, S o V,I, W o V,I,I,I) - tr(U, S,
  W).
• tr(U o 9, S o X,V,I, W o I,X) - tr(U, S o
  X, W).
• U ? 1,2,3,4
• Arabe2Romain(U,W).
• W M,C,C,X,X,X,I,V.

50
Comparaison des espaces
(NB évaluations indicatives)
51
Traitement des aspects dans les ET

• Les systèmes se complexifient rapidement (volume,
  évolutivité, hétérogénéité)
• La séparation et la combinaison des
  préoccupations est l'outil essentiel de maîtrise
  de la complexité
• Dealing uniformously with a variety of aspects is
  key to being able to manage complex systems
  (separation, weaving)
• Each technology is addressing this problem, with
  variable success.

DBMS
MDA
Aspect-Oriented Software Development
AOSD
Ontology
XML
Progr. languages
52
Tisser des aspects en XML
Carte de géographie résultats de vote
ltgmllocationgt ltgmlPointgt
ltgmlcoordgt ltgmlXgt1.0lt/gmlXgt
ltgmlYgt1.0lt/gmlYgt
lt/gmlcoordgt lt/gmlPointgt lt/gmllocationgt
ltgmlPolygon gid"810"gt ltgmlouterBounderyIsgt
ltgmlLinearRinggt
ltgmlcoordinatesgt0.0,0.0 100.0,0.0 50.0,100.0
0.0,0.0lt/gmlcoordinatesgt
lt/gmlLinearRinggt lt/gmlouterBoundaryIsgt lt/g
mlPolygongt
ltBureaudevotegt ltnumgt810lt/numgt ltNbInscritsgt870lt/N
bInscritsgt ltNbVotantsgt507lt/NbVotantsgt ltAyraultgt
70.72lt/Ayraultgt ltHarousseaugt20.44lt/Harousseaugt
lt/Bureaudevotegt
political map
53
Le tissage de modèles
54
Le tissage des aspects dans les différents ET

• Exemple tissage des informations géographiques
  et politiques dans un scrutin électoral
• Plusieurs façons de le faire dans les espaces XML
  ou UML
• Possibilité de projection
• Prise en compte de l'exécutabilité
• Le tissage d'aspect se retrouve dans de nombreux
  ET avec des propriétés et possibilités différentes

geographical
political
55
Exemple Maintenance du logiciel
MS/JUMP Java User Migration Path
56
Exemple compilation vers XSLT
MDA TS
Mb
Ma
XML TS
Mb/xmi
Ma/xmi
57
Les notes un exemple élémentaire

• Commentaire attaché à un ou plusieurs éléments de
  modélisation
• Appartient à la vue, pas au modèle
• Peut être stéréotypée en contrainte

58
Les notes un exemple élémentaire

• Relation sémantique quelconque entre éléments de
  modélisation
• Exprimée en OCL (Object Constraint Language) ou
  en langage naturel
• contrainte, inv, pre-, post-condition

59
Tout ET est basé sur un MM
60
(No Transcript)
61
ET La carte des influences

• Aucune technologie n'est une île
• Aucune technologie n'est uniformément supérieure
  aux autres
• Les technologies sont vivantes et évolutives
• Même si certaines peuvent rester stables ou
  inertes pour de longues périodes (ex. Systèmes
  experts)
• Les technologies ne meurent jamais elles
  restent cachées dans les couches profondes des
  systèmes logiciels
• e.g. GAP, Cobol, etc.
• Les technologies innovantes d'aujourd'hui sont le
  "legacy" de demain
• Les technologies s'influencent mutuellement

62
Conclusion

• L'attitude "ma technologie est meilleure que la
  tienne" est en général contre-productive
• La technologie à utiliser pour résoudre un
  problème est de moins en moins pré-déterminée
• Il est important d'avoir une vision globale des
  différents ET et de leurs possibilités
• Certaines technologies ont de meilleures
  capacités d'intégration que d'autres
• Par exemple la technologie des Web services est
  supérieure à la technologie des objets et des
  composants en ce qui concerne l'intégration
  d'applications
• Dans le passé, les progrès technologiques ont
  souvent été réalisés à la frontière de plusieurs
  technologies (e.g. WEB, Semantic Web etc.)
• Les technologies se développent plus en
  coopération qu'en compétition. Chacune cherche à
  trouver sa niche naturelle en s'appuyant sur les
  autres.

63
Conclusion une vue unificatrice

• By model we mean a complex structure that
  represents a design artifact, such as a
  relational schema, object-oriented interface, UML
  model, XML DTD, web-site schema, semantic
  network, complex document, or software
  configuration. Many uses of models involve
  managing changes in models and transformations of
  data from one model into another. These uses
  require an explicit representation of mappings
  between models. We propose to make database
  systems easier to use for these applications by
  making model and model mapping first-class
  objects with special operations that simplify
  their use. We call this capacity model management
• P.A. Bernstein, A.L. Levy R.A. Pottinger
• MSR-TR-2000-53

64
Fin du cours

• Merci
• Questions ?
• Commentaires ?

• Jean Bézivin
• Jean.Bezivin_at_irin.univ-nantes.fr
• Equipe ATLAS, INRIA IRIN, Nantes