introduction to language engineeringbaroglio/summerschool06/slides/gb...introduction to language...

1

© Giuseppe Berio, 2006

Introduction to Language Engineering

. - 1 -

Introduction to Introduction to Language Language EngineeringEngineering

Torino Torino Chambery Doctoral Chambery Doctoral SchoolSchoolAugust 2006August 2006

Giuseppe [email protected]



. - 2 -

Objectives

• The main focus of this talk is about the emerging area of language engineering

• Why?• Because, it is opinion of several researchers

(including myself) that success of model-driven technologies and approaches for the developmentof modern software, where the most known in MDA (Model Driven Architecture), is closely related to the notion of modelling language

• Modelling language used for building models can be categorized in: enterprise modelling language, requirement modelling language and software modelling language

2



. - 3 -

Examples of modelling languages

• Enterprise modeling languages (CIMOSA, GRAI, etc.)

• Software requirements modeling languages (GRL, KAOS, etc.)

• Software modeling language (UML)



. - 4 -

Context of this work

• The present material is elaborated on the extensive work developed in the INTEROP project (http://www.interop-noe.org/) and especially by the DEM team

• I would like to thank you to our DEM team and especially to Andrea Opdahl, John Krogstie, Patrick Heymans, Raimundas Matulevicius, Michael Petit, Victor Anaya, Mounira Harzallah, Kurt Kosanke, Hervé Panetto and Frank Walter Jaekel

• Co-funded by the European Commission, the INTEROP project involves 50 partners from 13 European countries. INTEROP aims to improve software interoperability by introducing a global approach taking into account enterprise needs, model driven software technologies and ontology based techniques

3



. - 5 -

Presentation Schedule

• Part 1 : Background Models and Languages• What is a model and its purpose?• What is a metamodel or a “modelling” language? (language

engineering problems and foundations)• What is a metametamodel?

• Part 2 : Background on MDA™• MDA basics• Glossary of direct and related acronyms• The 3+1 OMG modeling stack• Quick introduction to UML 2.0 and MOF 2.0• Model transformations QVT 2.0• Language engineering problems in MDA

• Part 3: Language engineering in UEML (Unified Enterprise Modeling Language)



. - 6 -

Separating the platform dependent and independent parts of systems

We don't want anymore to pay such a high price for simply moving our information system to a new middleware platform (COM, CORBA, Java, HTML, XML, DotNet, etc.) when our business system stays stable.We are prepared to pay a last price for building the abstract models of our business and services that will guarantee us against technological obsolescence.From there, any platform provider will also have to provide the mapping solutions from standard business models before we buy.

The ori

gins of

MDA

4



. - 7 -

Storing models and their relationships

• Old needs and new trends for modern software engineering:

• Traceability• Evolvibility (including innovation)• Configurability• Portability• Reuse• Integration• Independency and autonomy (Interoperability)

• To provide effective answers to these needs and trends, storing several types of models and their relationships is needed



. - 8 -

A global view of software engineering evolution I

proceduraltechnology

componenttechnology

objecttechnology

Objects,Classes,

Smalltalk, C++,...

Procedures,Pascal,

C,...

Packages,Frameworks,

Patterns,…

1980 1995 2000

proceduralrefinement

model technology

Models,Metamodels,

UML, OCL, MOF,XMI, SPEM, CWM

…

objectcomposition and inheritance

modeltransformation

5



. - 9 -

Where objects have failed?

• Patterns are not objects• Aspects are not objects• Applications are not objects• Services are not objects• Concurrency is not adequately represented• Objects alone do not allow to achieve simple code• Evolution (throuough inheritance) is not a reality• Integration in a global sense cannot be achieve by only using

objects• Objects and databases are not a reality• The WEB is not based on objects



. - 10 -

From Objects to Models: explaining models from software development perspective

• Object technology realized some promises but failed to achieve others • Stopping the search for generality by unification may be one of the causes

for this • MDA is making many promises today

• Will it be able to deliver correspondingly? • Sticking with the principle that "everything is a model" seems a good way

to make progresses

Objects

MDA Models

1980 2000 2020Promises

Delivery Evaluation Promises

Delivery Evaluation

6



. - 11 -

Modeling is essential: explaining modeling in general context

• Modeling is essential to human activity because every action is preceded by the construction (implicit or explicit) of a model

• In engineering, models are used to plan activities, to verify properties, to validate solutions and to explain phenomena and situations

• In engineering, models can be reused several times as they are or modified



. - 12 -

Modeling in system engineering not only in software engineering

7



. - 13 -

Model benefits for system engineering



. - 14 -

Want an advice about modeling in software?

"Modeling is the future …

And the promise here is that you write a lot less code, that you have a model of the business process … So, modeling is pretty magic stuff, whether it's management problems or business customization problems or work-flow problems, visual modeling …

It's probably the biggest thing going on …"

Bill Gates[What Is Bill Gates Thinking? Interview, eWEEK.com, 3/30/2004]

8



. - 15 -

Definitions

• A model is the simplified image of a system• This short definition should be completed

• What is a system ?• "A system is a set of elements in interaction " (von Bertalanffy)

• However this distinction is becoming loose because, for instance, lower level models can be directly executed on some programmableinfrastructure and some systems are fully automated. This is especially true when one model is used to generate automaticallythe system (i.e. that model contains all the information required to generate the system).

• Anyway a difference between model (for design and re-design of a system) and the system seems to be useful for practical reason: i.e. do not confuse the system and its models

• The same difference is recognized when talking about design timeand run time as well

ModelrepOfSystem



. - 16 -

What is a model?

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/BioinformaticsArchive/PrimarySite/NIHpanelModeling/RothenbergNatureModeling.pdf

And the reality is known througouth models

9



. - 17 -

Model: multiple definitions

mod·el [módd’l] noun (plural mod·els)

1. copy of an object: a copy of an object, especially one made on a smaller scale than the original ( often used before a noun ) 2. particular version of manufactured article: a particular version of a manufactured article

had traded in her car for the latest model3. something copied: something that is copied or used as the basis for a related idea, process, or system4. somebody paid to wear clothes: somebody who is paid to wear clothes and demonstrate merchandise as a profession, for example, in fashion shows and photographs for magazines and catalogues5. simplified version: a simplified version of something complex used, for example, to analyze and solve problems or make predictions a financial model

6. perfect example: an excellent example that deserves to be imitated7. artist’s subject: somebody who poses for a painter, sculptor, photographer, or other artist8. zoology animal copied by another animal: an animal species repellent to predators which another animal mimics for protection9. logic interpretation: an interpretation of a theory arrived at by assigning referents in such a way as to make the theory true10. U.K. fashion exclusive garment: the first sewn example of a couturier’s or clothing manufacturer’s design, from which a new line of garments is produced

MSN Encarta



. - 18 -

There are still a number of models to build especially models of existing natural systems

Magellan, Christophe Colomb, Marco Polo

Vasco de Gama, Pizarre, etc.

Models of the earth,galaxy and space

Models of the brain

Models of Genetic legacy(Human genome map)

(localization of the main functions)

10



. - 19 -

The globe is a model of the earth

repOf

(Principle of limited substitutability).A model M is said to be a representation of a system Sfor a given set of questions Q if, for each question of this set Q,the model M will provide exactly the same answerthat the system S would have provided in answering the same question.



. - 20 -

The globe is a model of the earth

• Allowing to ask certain questions …

• But (strictly) not others What is thetemperature

at the bottomif I dig a

100 km deep holeat the surface of

the earth ?

Could I travel fromParis to Anchorage

without using a boat?

That is an advantage of models: too complex models

are not really usable

11



. - 21 -

Businesssystem

Applicationrequirements

Executionplatform

Different kinds of models

• Numerous examples • Mathematical models • Hydrological models • Biological models • Ecological models • Economical models • Meteorological models • Simulation models • Descriptive or predictive models • etc.

• Software systems are built on models:• But a model of what?

• Of the organization where it is supposed to function?• Of the architecture (hardware/software platform ) on top of which it is supposed to

function?• Data models?• Of the applicative requirements it is supposed to satisfy ?• Of the team that elaborated the software?

• Expressed in which language?• Until now software has been mainly written in so-called programming languages like

C# or Java • … but things are rapidly changing (code-centric to model-centric, DSLs)

Softwaresystem



. - 22 -

Businesssystem

Applicationrequirements

Executionplatform

What we want from the enterprise

What we want from the software for

supporting the enterprise

How the software should be built

Businesssystem

Enterprisesystem

Is the enterprise rentable?

How the enterprise should be organised

and behave

Models in software engineering

Businesssystem

Is the contract satisifed?

12



. - 23 -

Multiples views (or aspects) and coordinated DSLs

Carpenter'sview

Mason'sview

Plumber'sview

Architect'sview

Landlord'sview

Renter'sview

InteriorDesigner's

view

TaxCollector's

view

Electrician'sview

Each view is often expressed in a given domain language (DSL).Vocabularies of different corporations are different;However they allow talking about a common building. Consistency between these views is a major issue (for instance, Plumber should take into account Eletrician for not crossing electric cables)

ModelrepOfSystem



. - 24 -

Hierarchy of systems (systems of systems)

ModelrepOf

System

Sub-system

Interface Models,Internal Models

repOf

13



. - 25 -

Aspects (views etc.) of a system represented by models

A given system may have plenty of different models.

Each model represents a given aspect of the system.

MaMa

SS

isRepresentedBy

MbMb McMc



. - 26 -

Distinct aspects are organized horizontally and vertically (and more)

Last layer

…

Models of sub-system

Models of sub-system requirements

Models of a system

Aspects, views, concerns

Laye

rs (also

dom

ains

of m

odellin

g)

Architecture

ModelrepOfSystem

II ModelsrepOfSub-System

Syst

em

Run

time

Des

ign

time

Deployment (making the system as designed)Human Artifical

14



. - 27 -

Examples of layers, domains

• Zachman’s enterprise architecture (see next slide)

• CIMOSA an example of three dimensional organization

• Three layers architecture for softwareUser Interface

Application logics

Data access, organisation and management



. - 28 -

15



. - 29 -

Aspects (views etc.) of a system represented by models

• Precise models (complete as required)• Approximate models (incomplete)• Formal models • Informal models• Consistency when using several models• Agreed models• Executability

And more generally the quality of models to control all the difficulties raising during the modelling process, and especially the informality

Early: approximate, informal, agreed

Detailed: precise, formal, agreed



. - 30 -

Executable models

• Executable models are an important category of models that are essentially associated to an operational semantics

• Executable models may occur in various phases of software engineering from early to detailed (for instance the Executable UML)

• The advantages of executable models is to prototype the behavior of the system

• Some executable models are directly used to program a platform for making the final system (deployment)

16



. - 31 -

Executable models should include explicit decisions on executions

• Executability is a decisions about how this executability should be achieved (distributed vs centralised)

ClerckShipment

What/who decide which shipment should be charged on the track?

Track



. - 32 -

Aspects (views etc.) of a system represented by models: patterns for combining models of aspects

Model3

Model1: View1 Model2: View2

Model3

Model1: View1

Model2: View2

For instance, an existing class diagram in object-oriented can be improved by using functions or scenarios

A process can be described by looking at only critical activities

A process can be describe by looking activities performed by one actor

Mapping problems: relations and transformations between models should be specified and traced

17



. - 33 -

How are models expressed?

• Models are expressed in languages, possibly specialized languages (i.e. we are not talking about physical models)

• Talking about models, languages called modeling languages

• Languages usually distinguish between syntax controlled by grammars (what can be written and what cannot) and semantics (what is understood what has been written, for acting)

• However, syntax and semantics need to be expressed in some other languages that are therefore used to making models of them; to distinguish between languages and languages for expressing languages, we are talking models, meta models and meta meta models (and so on)



. - 34 -

Quality of models

•Some information used for making models are only needed forsome operations on some models (usage efficiency and economyof representation)•For instance:

•An attribute X in a OO class corresponding to the State of an Order does not need to be specified in possible values for execution purposes; however, this specification is required for manipulating the class Order and evolving/modifying it•However, some of these information can be included in the class implementation if the compiler makes efficient code and these information are used for static analysis or the interpretation is very efficient

•How to achieve and to assess efficiency and economy? Some issues are not related to models but to languages used for modelling --- writing directly in JAVA does not allow to allow to make an economic representation of business processes

Bad modelling Bad or not adapted modelling language

Non quality of models

18



. - 35 -

Approaching bad modelling

• Making better methodologies

• Situational method engineering (suggesting which models should be built in specific situations)



. - 36 -

Example about the model quality assessment

Knowledge externalizabilityappropriateness /Participant languageknowledge appropriateness

Technical actorinterpretation

appropriateness

Comprehensibilityappropriateness

Modelexternalization

M

Socialactor

interpretationI

Technicalactor

interpretationT

Modelingdomain

D

Languageextension

L

Participantknowledge

K

Domain appropriateness

Goals ofModelling

G

Organisationalappropriateness

• Physical quality: The basic quality goals on the physical level are externalization, that the knowledge K of the domain D has been externalized, and internalizeability, that the externalized model Mis available.• Empirical quality deals with predicable error frequencies when a model is read users, coding and HCI-ergonomics for documentation and modelling-tools.• Syntactic quality is the correspondence between the model Mand the language extension L. • Semantic quality is the correspondence between the model Mand the domain D. This includes validity and completeness.• Perceived semantic quality is the similar correspondence between the audience interpretation I of a model M and his or hers current knowledge K of the domain D.• Pragmatic quality is the correspondence between the model Mand the audience's interpretation of it (I). We differentiate between social pragmatic quality (to what extent people understand the models) and technical pragmatic quality (to what extent tools can be made that interpret the models). • The goal defined for social quality is agreement among audience members’ interpretations I.• The organizational quality of the model relates to that all statements in the model contribute to fulfilling the goals of modelling (organizational goal validity), and that all the goals of modelling are addressed through the model (organizational goal completeness).

19



. - 37 -

Models: their structure and their semantics

F = m*aThe physical interpretation Mathematics Language

(meta model)Conform toSemantics

(ontology)

Semantics of the expression a=b*c

Structure of an expression

Class OrderThe physical interpretation UML (meta model)

Conform toSemantics (ontology)

Semantics of the class

Structure of a class



. - 38 -

Models: their structure and their semantics

Class OrderThe physical interpretation UML (meta model)



Class CommandThe physical interpretation UML (meta model)



Question:

How to decide if Command and Order are used to represent the same parts of the system? Normally, semantics is required but which one?

Answer:

It is the physical interpretation that should suggest if they are or not. However, the other semantics can be used to better (or formally) verify the hypotheses (modelling errors are always possible); i.e. both are required

20



. - 39 -

Making more models and relating them

Class CommandEnterprise meta model UML (meta model)

Conform to

Semantic relation


Inf. Command

Conform to

Semantics of the Information

The class Command is in software modelling domain and is the best way to represent for software design purposethe information Command; therefore,

the physical interpretation is not direct (while possible)



. - 40 -

Typical situational method engineering questions while methodologists try to answer them in a general way

Difficulties in the modelling process: questions and meta questions

• What should be represented in a model and what should not

• What aspect is better to represent before• Which languages should be employed for modelling

aspects• How to validate a model according to the existing system

or the system to be built• How to manage the model once built• How to make effective modelling decisions

21



. - 41 -

Meta models• Meta models are a convenient way to represent languages

and to provide ways for making models conform to these meta models; the meta modelling process is the foundation of the language engineering

• However, meta-models are often used to prototype languages made of constructs; this prototyping is often difficult even more than building models (and the difficulties in the meta modelling process are the same as in the modelling process and language quality frameworks are needed)

• For instance, even basic decisions such as what are the constructs and if a construct should be represented as a concept or a relationship may be difficult

• But additional problems are in the essential nature of meta models and how to clearly distinguish between two well known language related elements: syntax and semantics, often mixed in uncontrolled meta models

• Uncontrolled meta models (used for years in the past) isthe main reason of unsuccess of meta modeling.



. - 42 -

Every map has a legend (implicit or explicit)

The legend

Same visual notation,different context,different meaning(Thick reddotted linesfor bicycle lanes)

is the meta model

µ

22



. - 43 -

The legend in the map is a meta model

basedOn

The town The map

The legend



. - 44 -

Assisted Drawing Tools (e.g. MS/Visio)

Conform toMetamodel Model

µ

µ

A library of stencils

23



. - 45 -

Flowcharting DSL in the 60's

µ

Model

Metamodel

Conform to



. - 46 -

Flowcharting DSL in the 60's

Many templates for severalcorporations and usages

24



. - 47 -

Typical Situations (only some)

Visio Stencil

Visio Drawing

c2

Form definition

Form content

c2

XML Schema

XML Document

c2

Legend

Map

c2

File Structure

File content

c2

UML MM

UML Model

c2

Music notation

Music sheet

c2

Grammar

Program

c2

DB Schema

DB Content

c2

Type

Value

c2



. - 48 -

Meta models and semantics

• Usually, meta models used to describe modelling languagesare used for representing concrete domains; therefore the semantics of meta models should be represented in term of what these meta models should represent in the concrete domains (i.e. an ontology of the domain)

• The way in which the semantics is represented is another issue; however, the semantics of the language should be expressed throughout an appropriate representation mapping from one abstract syntax (i.e. the modelling constructs) to an ontology, both made explicit

• This point of view is consistent with theory where often the semantics of a (programming) language L is expressed throughout a function Sem(L) like:

Sem(L): Abstract Syntax(L) Semantic Domain

25



. - 49 -

What meta models can describe for a language

• Notations

• Abstract syntax (most typical usage and understanding of meta models)

• Semantic domain (ontology)

• Representation mappings (semantics)

But these artifacts are usually not modularized and each of them can be described in distinct way and in a partial form



. - 50 -

Distinct notations (concrete syntax) but similar meanings(semantics)

decision decision

make a decision is…

Why semantics

Notation (concrete syntax)

decision

objective

Decision (..objective..)

Decision

Objective

And a relation

Why abstract syntax (the first step towards semantics)

Notation (concrete syntax)

Notation(s), abstract syntax and semantics should be clearly distinct in any meta model, then related through appropriate relations (such as the representation mapping)

26



. - 51 -

More on notations: the frontier between abstract and concrete syntax

• The layout problem (SADT)Position in the box should be coded in the abstract syntax?

Position of the boxes should be coded in the abstract syntax?

Similar to writing programs following specific writing guidelines; but in the first case, position is also related to meaning of flows while not in the second (the latter case may reduce the quality of the models)



. - 52 -

More on abstract syntax: from notation to abstract syntax

Activity

Activity Flow

Activity FlowPin

Notation

Abstract syntax (concept/relation)

input

output

input

output

flowdecomposition

Pin may be an hidden construct used to improve some quality types of the language

27



. - 53 -

Meta models are used for making models in different domains (and layers)

• Usually, meta models are made based on the experience or theory for a specific domain (for instance, UML for software modelling)

• The tendency is however to use existing meta models for making models in other domains (layers); this is for several reasons but one of the most preminent is because building models may starts from other models and the former are built from the latter by identity or refinement within the same meta model

• This is however a risky way of working and originates the need to assess much more precisely to what extent a language defined for a scope can be used for other scopes (language quality frameworks)

UMLSoftware

requirement models

Software models

same meta model



. - 54 -

Quality frameworks for meta models I

28



. - 55 -

Quality frameworks for meta models II

Knowledge externalizabilityappropriateness /Participant languageknowledge appropriateness

Technical actorinterpretation

appropriateness

Comprehensibilityappropriateness

Modelexternalization

M

Socialactor

interpretationI

Technicalactor

interpretationT

Modelingdomain

D

Languageextension

L

Participantknowledge

K

Domain appropriateness

Goals ofModelling

G

Organisationalappropriateness

• Physical quality: The basic quality goals on the physical level are externalization, that the knowledge K of the domain D has been externalized, and internalizeability, that the externalized model Mis available.• Empirical quality deals with predicable error frequencies when a model is read users, coding and HCI-ergonomics for documentation and modelling-tools.• Syntactic quality is the correspondence between the model Mand the language extension L. • Semantic quality is the correspondence between the model Mand the domain D. This includes validity and completeness.• Perceived semantic quality is the similar correspondence between the audience interpretation I of a model M and his or hers current knowledge K of the domain D.• Pragmatic quality is the correspondence between the model Mand the audience's interpretation of it (I). We differentiate between social pragmatic quality (to what extent people understand the models) and technical pragmatic quality (to what extent tools can be made that interpret the models). • The goal defined for social quality is agreement among audience members’ interpretations I.• The organizational quality of the model relates to that all statements in the model contribute to fulfilling the goals of modelling (organizational goal validity), and that all the goals of modelling are addressed through the model (organizational goal completeness).

An abstract quality framework Types of quality



. - 56 -

Quality frameworks for meta models IIIWorkflow patterns

Note: meta models built for some domains can be used for other domains

Quality evaluation

Prob

lem:

How

are

pat

tern

s st

ated

?

29



. - 57 -

Quality frameworks for meta models IVa

A more abstract meta model focusing on business process modeling domain



. - 58 -

Quality frameworks for meta models IVb

Note: meta models built for some domains can be used for other domains

30



. - 59 -

An ontology for concrete domains: BWW (Bunge Weber Wand)

Quality frameworks for meta models Va



. - 60 -

Representation mapping between UML and BWW

Quality frameworks for meta models Vb

No corresponding ontological concept

Problem: how to state the representation mapping?

When used for modelling

31



. - 61 -

Quality language frameworks

• Slide III is an example of some ontological evaluation in the software domain and especially focusing on domain appropriatness for the workflow software domain

• Slides IVa and IVb are examples of some ontological evaluation in business process domain and especially focusing on domain appropriatness

• Slides Va and Vb show other more abstract ontological evaluations based on the representation mapping again focusing on the domain appropriateness

Most of them are based on abstract and concrete syntax, the reprentation mapping and a semantic domain (ontology)



. - 62 -

How to use language quality frameworks for meta modelling

• Broadly comparing meta models according to some quality types

• Assessing some quality types of existing meta models selection

• Tight meta models for specific purposes and eventually to perform meta model improvement; in this case, however, most of the works are difficult to be used and reused because the representation mapping is not modeled

complexity

32



. - 63 -

Multiple meta models for the same system



. - 64 -

Modelling in system engineering: reusing UML

33



. - 65 -

Hypotheses on the origin of UML: combining several meta models

ObjectStructure Interaction

Structure of object-oriented programming Method behaviors

Integration of meta models

scenarios

Similar scenarios



. - 66 -

Origin of a new language for system engineering

34



. - 67 -

Several related models are required



. - 68 -

Origin of a new language for system engineering

• Analysing requirements for the new language (modelling needs)

• Comparing and selectively reusing existingmeta models for making a new meta model or extending the existing ones into a new meta model

• Finalising and proposing• Evolution and change

All these steps are often informally performed

35



. - 69 -

Three levels for reusing meta models

• Distinct concrete syntax, same abstract syntax, same semantic domain

• Distinct concrete syntax and distinct abstract syntax, same semantic domain

• Distinct concrete syntax and distinct abstract syntax, distinct semantic domain



. - 70 -

Overloaded and overlapping constructs

• Overlapping constructs: association and association class (construct redundancy)

• Overloaded constructs: activity (of a resource and by a resource)

• Both ones lead to difficulties in making a decision during the modelling process because overloaded and overlapping constructs are used for representing similar situations while not correct

• Two possibilities: (i) clarify the meaning and make constructs distinct, (ii) redesign the constructs

36



. - 71 -

A generic way to specify meta models is a meta meta model

representation ofsystem S Model M

metamodelMM

Conform to

metametamodelMMM Conform to



. - 72 -

Different meta meta models for different models but for the same system

JavaMLDTD

JavaMLDocument

JavaUML Metamodel

JavaModel

JavaGrammar

JavaProgram

BNF MOF XMLMeta meta model of the program code

37



. - 73 -

Different meta meta models for different models but for the same system

Method

1

*

+extends

*

1

Class

FirstApplet paint

Applet

extends

1 <?xml version="1.0" encoding="UTF-8"?> 2 <!DOCTYPE java-source-program SYSTEM "java-ml.dtd"> 4 <java-source-program name="FirstApplet.java"> 5 <import module="java.applet.*"/> 6 <import module="java.awt.*"/> 7 <class name="FirstApplet" visibility="public"> 8 <superclass class="Applet"/> 9 <method name="paint" visibility="public" id="meth-15"> 10 <type name="void" primitive="true"/> 11 <formal-arguments> 12 <formal-argument name="g" id="frmarg-13"> 13 <type name="Graphics"/></formal-argument> 14 </formal-arguments> …….

1 import java.applet.*;2 import java.awt.*;34 public class FirstApplet extends Applet {5 public void paint(Graphics g) {6 g.drawString("FirstApplet", 25, 50);7 }8 }

Javasourcecode

JavaMLdocument

Each of these models may be more convenientto perform some operations on the program.

[2]

[3]

[1]



. - 74 -

Conclusion I part

•A model is a representation of a (even not existing) system; building models as a help to understanding or to building systems is an old activity, still very useful.

•A model is written in the language of its unique meta model; models are constrained by the language in which they are written; meta models are the central tool to define these languages.

•A meta model is written in the language of its unique meta meta model

•A model may have a visual graphical representation (sometimes)

38



. - 75 -

Conclusions I part

• Modelling and models are very useful in engineering software based solutions

• However, both modelling and meta modelling are difficult activities that should be strongly controlled

• The produced models and meta models should be precisely related as much as possible

• Meta models should be related because the risk is to produce several time similar unrelated constructs

• Models should be related because of consistency and management are essential to make working systems

• Models and their relationships can be also implemented in the system to increase its manageability in an evolving and changing world (interoperability)



. - 76 -

Models Everywhere

BusinessmodelBusiness

processesBusiness

rules

Workflowmodel

Testmodel

Usermodel

Costmodel

Developmentprocessmodel

Designmodel

Classmodel Object

model

Dynamicmodel

UseCasemodel

InteractionmodelResource

model

Agentmodel

etc.

Performancemodel

Businessobjects

39



. - 77 -





• Part 3: Language engineering in UEML (Unified Enterprise Modeling Language)



. - 78 -

• New orientation for OMG activities• New step beyond the Object

Management Architecture (OMA)

• Models are centric!• Target middleware is not important!

• Focus on Platform Independent Models (PIM)• Without middleware details

• Abstract Platform Specific Models (PSM)• Including all middleware details

• Define PIM to PSM transformations

• Preserving PIM when new middleware appears!

Model Driven Architecture

40



. - 79 -

Middleware vs Modelware: from OMA to MDA

OMA MDA

IDL UML

(from codeto model)

Lannion, 2 juillet 2001 Réunion Groupe META

Object Request BrokerObject Request Broker

Application Objects CORBA Facilities

CORBA Services

LifecycleEventsNamingPersistenceTransactionsConcurrency

ExternalizationSecurityTimePropertiesQueryLicensing

Compound DocsObject LinkingHelp FacilitiesUser InterfaceDesktop MgmtVertical Markets

Not initially standardized by OMG;Scope is single application or vendor



. - 80 -

MDA picture explained

UML

MOF

CWM

41



. - 81 -

Key MDA modelling standards

MOF

QVTSPEMUM

L

UML MM : description of OO software artifactsSPEM MM: how to use and produce themQVT MM: how to generate models from other modelsMOF MMM: how to generate meta models



. - 82 -

MDA vision and model transformations

42



. - 83 -

Effective usage of models to generate systems

+Applicant()+ApplicantInfo()+MakeApplication()

-companyName : CString-experience : CString-reference1 : CString-reference2 : CString-reference3 : CString

Applicant

+Person()+PersonInfo()

-personID : unsigned long-surname : CString-givenName : CString-middleInitial : char-streetAddress : CString-postCode : CString-countryname : CString-eMailAddress : CString

Person

-is taught by

1

-teaches

0..*+CourseSession()+CourseSessionInfo()

-courseSessionID : unsigned long-courseDate : unsigned long-courseID : unsigned long-courseLocation : CString

CourseSession

+AppStatus()+AppStatusInfo()

-statusCode : char-statusName : CString

AppStatus

+CourseRegistration()+CourseRegistrationInfo()

-registrationDate : unsigned long-completionFlag : bool-confirmedDate : unsigned long

CourseRegistration

+Test()+TestInfo()

-testScore : unsigned longTest

+Application()+ApplicationInfo()

-productNr : unsigned long-certificationLevel : unsigned long-applicationDate : unsigned long

Application

+PermittedStatusChange()+StatusChangeInfo()

-fromStatus : char-toStatus : char

PermittedStatusChange

+ExamSession()+ExamSessionInfo()

-examSession : unsigned long-examlocation : CString-examDate : unsigned long

ExamSession

-gives0..*

-is achieved1

-is made by

1

-makes

0..*

-allows change in

0..*

-has a

1..*

-is taken by1

-takes0..*

-is made by a1

-made a1..*

-is in1

-is filled by0..*

-uses

1

-is used in

0..*

-applies to a0..*

-is for a1

+Exam()+ExamInfo()

-examID : unsigned long-certificationLevel : unsigned long

Exam

+Employee()+GetCurrentAge()+EmployeeInfo()

-jobType : CString-roomNr : unsigned long-department : CString-division : CString-jobTitle : CString-manager : unsigned long-headsDept : CString-headsDivision : CString-mobileNr : CString-birthDate : unsigned long

Employee

+registrationform()

RegistrationForm

-uses**

ApplicantApplicantList PersonList

findApplicant()

ApplicationRegForm

Applicant()

findPerson()

addPerson()

addApplication()

Application()

MakeApplication()

ApplicationList

class

sequence

JavaCode

"from human-readable to computer-understandable"

XMI XMI

Past usage of models: design patterns, guidelines

MDA



. - 84 -

Models and their relationships

ModelUMLVehicle

Truck

Model Java

Vehicle

Truck

comesFrom

comesFrom

comesFromspecializes extends

Problem:

Need like traceability, evolvibility require essentially to precisely state therelationships between models. However, we are talking about the result but not about why and when state these relationships. For the latter purpose, possible relationships between possible models have to be stated between meta models.

43



. - 85 -

PIMs and PSMs

•Kinds of models in MDA

•PIM: Platform Independent Model•Neutral specification of a system aspect leaving out all the

implementation details •Example: behavior of an ordering management system in

UML •PSM: Platform Specific Model

•Specific model taking into account the platform model and are usually built from UML profiles built for the specific platform (PDM)

•Example : behavior of an ordering management system in "UML profile for CORBA"

•Models of the platform (PDM)•Example: UML profiles of CCM, C#, EJB, EDOC, etc.



. - 86 -

Write once, run everywhereModel once, Generate everywhere

CORBA

Java/EJBC#/DotNet

Web/XML/SOAP

PIM

etc.

Platform-Independent-ModelMulti-targetcode generation

+ SVG, GML, Delphi, ASP, MySQL, PHP, etc.

data grid computingpervasive computingcluster computing

SMIL/Flash

44



. - 87 -

Design time and run time

UML/MOF

XML/SOAP

XMI/XSLTprojection

CORBA

IDLJava/EJB

JSR #40Java UserCommunity

(Sun)

C#/DotNet

ModelingSpace

ExecutionSpaces



. - 88 -

Forward and reverse engineering in MDA

PIM

PSM PSM

Platformsof yesterday

Platformsof tomorrow

Platformsof today

Legacy,Cobol, ADA, etc.

Java, EJB, J2EE, etc. ????

Grid, Cluster,P2P architectures

45



. - 89 -

Software development considered as a chain of model transformations

PIM PSM Codemodel

1 3 6

52

4 7

Analysis Design Code

M1 M2 M3 M4 M5



. - 90 -

CIM

• MDA also provides the definition of Computation Independent Models (CIM) which are normally used for software requirements or even for enterprise modelling

• However, no evidence of CIM application is currently provided in MDA and all meta models and UML profiles are for PSM and PIM

46



. - 91 -

Acronyms

• MDE Model Driven Engineering• ME Model Engineering• MDA Model Driven Architecture• MDD Model Driven Development• MDSD Model Driven Software

Development• MDSE Model Driven Software

Engineering• MM Model Management• MDDE Model Driven Data

Engineering• ADM Architecture Driven

Modernization• MDRE Model Driven Reverse

Engineering• DSL Domain Specific Language• DSM Domain Specific Modeling

• MDE is a generic term; ME ~ MDE• MDA™ and MDD™ are OMG

trademarks; MDD is a protection trademark (no use as of today/justreserved by OMG for future use)

• MDSD like MDSE is sometimes used instead of MDD when onedoes not wish to be associated to OMG-only technology, vocabulary and vision.

• ADM is another standard intended to be the reverse of MDA: MDAcovering forward engineering while ADM covers backward engineering. ADM ~ MDRE

• MM ~ MDDE• DSM is more Microsoft marked but

of increasing use by the academic and research community

• And Language Engineering as well



. - 92 -

Some OMG Trademarks (http://www.omg.org/legal/tm_list.htm)

• OMG's Registered Trademarks Include:• MDA®• Model Driven

Architecture®• UML® • CORBA®• CORBA Academy®• XMI®

• OMG's Trademarks Include:• CWM™ • Model Based Application Development™ • MDD™• Model Based Development™

Model Based Management™ • Model Based Programming™ • Model Driven Application Development™ • Model Driven Development™ • Model Driven Programming™ • Model Driven Systems™ • OMG Interface Definition Language

(IDL)™ • Unified Modeling Language™ • <<UML>>™

47



. - 93 -

CORBA

•CORBA is a foundation of this new architecture. As the only vendor and languageindependent middleware, it is a vital and necessary part of the MDA superstructure; software bridges would be hard to build without it. Extending this superstructure, the MDA is expressed completely in terms of modeling concepts, moving the reuse equation up one level.



. - 94 -

CORBA IDL

interface Account {attribute short number;attribute float balance;

};

JAVA C++

Standard Mappings of interfaces and types to compatible JAVA, C++

constructs (not raising run-time errors)

Call in JAVA the method M

Execute the method M with method-body written in C++

ORB

48



. - 95 -

UML (+OCL) vs. IDL

- -E n g l i s h

-- n u m b e r m u st b e b e tw e e n 1 0 0 0 a n d 9 9 9 9

--O C L

i n v :

n u m b e r > = 1 0 0 0 a n d n u m b e r < = 9 9 9 9

A c c o u n t

< < C O R B A I n te r f a c e > >

n u m b e r : s h o r t

b a l a n c e : f l o a t

interface Account {attribute short number;attribute float balance;

};

IDL: simple definition based on hidded assumptions

UML: hidden assumptionsbecome explicit in PSM



. - 96 -

the UML MetaModel

Class Attribute*1

a UML Model

Client

Name : String

The OMG/MDA initial modelling stack

M2

M1

the MOF

Class Associationsource

destination

M3

Conform to

Conform to

Conform to

µµ µ

µµ

meta model

model

meta-metamodel

The MOF

The UML meta model

Some UML Models

Various usagesof these modelsM0

M1

M2

M3

µ

µ

49



. - 97 -

MDA History: meta-models evolutions



. - 98 -

More on UML 2.0 Infrastructure

50



. - 99 -

Some questions on the UML 2.0 Infrastructure: moving model artifacts between modelling layers

Where to place the object :video?

A set of videos of the specific structure

A structure of any video

Any class structure

A set of set of objects with a

specific structure

A structure of anyvideo

Any class structure

A video

Moving up a video

Powertype/or type partition



. - 100 -

UML 2.0 infrastructure and superstructure

• Infrastructure focusing on reusability for both UML and MOF (no information concerning actions and activity, and object interactions)

• Superstructure focusing on modelling constructs and especially on actions and activity, and object interactions

51



. - 101 -

UML features of key constructs



. - 102 -


52



. - 103 -




. - 104 -

MOF and UML

infrastructure

superstructure

UML infrastructure

53



. - 105 -

MOF key abstractions



. - 106 -

MOF features of key abstractions

54



. - 107 -

MOF features of key abstractionsEvery named element, and therefore class and instance are subclasses of object



. - 108 -

How MOF has been originated

• By looking at MOF, its structure is essentially generated by abstracting typical structures of object-oriented languages

• Class, (or other) can be generalised/specialised and composed of private several other artifacts (features) such as attributes and operations

• Therefore, MOF is essentially a way for storing structures of meta models; MOF specific usages are coded by using IDL (and XMI) and not uniformely represented in MOF itself

55



. - 109 -

MOF and its concrete representation



. - 110 -

Making meta models in MDA: two possible approaches with poor guidelines

• UML profiles• A simple way for extending UML based on stereotypes• Based on inheritance and therefore not too much suitable

for any situation

• MOF model • A way to introduce new languages• More general and it might import from other existing meta

models

56



. - 111 -

EDOC – ECA - CCA



. - 112 -

ECA (package) structure

57



. - 113 -

Information view meta model



. - 114 -

ECA PIM and PDM

58



. - 115 -

Several other profiles and meta models

• Meta models:• ODM, BMM, BPM, CWM, SPEM

• UML Profiles• SysML (PIM), EDOC (PIM), CORBA (PDM), and

other not standardised EJB (PDM), JAVA(PDM), ebXML (PIM), OWL (PDM)



. - 116 -

QVT (Query View and Transformation) 2.0

• The MDA way for transforming and relating models by using transformations specified on meta model (types)

59



. - 117 -

Example : UML2Java

Meta-model UML

Meta-model Java

Transformations are usually complex; however, it is much more complex to justify a transformation than to represent it.



. - 118 -

Simplified Java in MOF (not standard)

60



. - 119 -

Simplified UML in MOF



. - 120 -

module UML2JAVA; create OUT : JAVA from IN : UML; helper context UML!ModelElement def: isPublic() : Boolean = self.visibility = #vk_public; helper context UML!Feature def: isStatic() : Boolean = self.ownerScope = #sk_static; helper context UML!Attribute def: isFinal() : Boolean = self.changeability = #ck_frozen; helper context UML!Namespace def: getExtendedName() : String = if self.namespace.oclIsUndefined() then '' else if self.namespace.oclIsKindOf(UML!Model) then '' else self.namespace.getExtendedName() + '.' endif endif + self.name; rule P2P { from e : UML!Package (e.oclIsTypeOf(UML!Package)) to out : JAVA!Package ( name <- e.getExtendedName() ) } rule C2C { from e : UML!Class to out : JAVA!JavaClass ( name <- e.name, isAbstract <- e.isAbstract, isPublic <- e.isPublic(), package <- e.namespace ) } rule D2P { from e : UML!DataType to out : JAVA!PrimitiveType ( name <- e.name, package <- e.namespace ) } rule A2F { from e : UML!Attribute to out : JAVA!Field ( name <- e.name, isStatic <- e.isStatic(), isPublic <- e.isPublic(), isFinal <- e.isFinal(), owner <- e.owner, type <- e.type ) } rule O2M { from e : UML!Operation to out : JAVA!Method ( name <- e.name, isStatic <- e.isStatic(),

Explicit simple transformation based on the UML informal meaning

61



. - 121 -

UML to RDBMS



. - 122 -

UML to RDBMS

62



. - 123 -

UML to RDBMS

Graphical Notation Textual Notation

Not standard



. - 124 -

Relations are used to trace transformations

TraceClass which include p and s as attributes

63



. - 125 -

RDBMS: logical to physical models

• Some transformations do not involve distinct meta models but only one meta model

• However, models can be eventually transformed because to distinct levels of abstraction, adding details



. - 126 -

QVT (Query, View and Transformation) 2.0 structure

Declarative package based on the pattern matching

Imperative package based on operations on MOF models

Transformations are specified as MOF models to which is associated a specific meaning

Specifying model transformation is made by using meta models (i.e. MOF models as input and output, and transformation)

64



. - 127 -

Some QVT (Query, View and Transformation) 2.0 issues

• The reason for a transformation holds is not described in QVT: QVT is only a way to specify what/how to transform and not why

• For instance UML to RDBMS is based on experiences collected and described in methodological guidelines

• Should QVT be completed accordingly? If yes, a better representation of language semantics should be achieved; if not the risk is to make a powerful programming language (declarative and imperative) for transforming models but not developing models of these transformations

• Examples of QVT transformations usually deal with transforming models (of a type, i.e. conform to meta models) by specifying the transformations on meta models; this corresponds to work at design time only; but if the models are associate to objects (as in databases, what should happen?)



. - 128 -

Summary

• MDA is ready for prime time in software engineering

• MDA is based on: • A four level architecture (3+1)• A unique meta-meta-model (MOF),

• with transfer and exchange mechanisms (XMI)• with transformation mechanisms (QVT)• with operationalization mechanisms (e.g. round-trip engineering)

• A grawing collection of specialized meta-models • Object meta-models (Java, CLR, etc.)• Legacy meta-models (Relational, CWM)• Enterprise meta-models : business objects, process & rules• Process meta-models (e.g. workflow, RUP)

• An simplified extension mechanism (profile).• Efficient representation engines.• Middleware integration schemes (DotNet, CORBA, Java).

65



. - 129 -

Adaptive, Inc. Interactive Objects Software; ArcStylerAonix's Ameos Kabira Technologies, IncARTiSAN's Real-Time Studio KnowGravity's CASSANDRAb+m ArchitectureWare Kennedy Carter Ltd: iUML and iCCGBITPlan GmbH smartGenerator LIANTIS XCoderThe Borland Approach to MDA M2VP's MDA Consulting ServicesCalKey Technologies' Caboom MASTER ProjectCalytrix Technologies' SIMplicity Mentor Graphics' EDGE UML Suite

Codagen Technologies; Codagen Architect 3.2 MetaMatrix Commitment

Codeless Technology's Codeless Metamaxim's modelscopeConsortium for Business Object Promotion MID's Innovator

Consyst's REP ++ Studio The MOD Group's MDA Services

Compuware OptimalJ Neosight Technologies' BoldExpress StudioData Access Technologies (DAT) Provides MDA Services OCI's MDA Services

David Frankel Consulting ObjectFrontier's FrontierSuiteDomain Solutions' CodeGenie Outline Systems Inc.'s PowerRADDot Net Builders' Constructor Pathfinder Solutions PathMATEEDCubed's TET Plastic Software's Agora Plastic 2005E2E Bridge realMethods Framework

Gentastic's e-GEN Select Business Solutions' Select Component Factory

M1 Global Solutions' MDE Mia-Software's Model-In-ActionHendryx & Associates Softaris Pty. Ltd.: MetaBoss

Herzum Software SoftMetaWare's Generative Model Transformer project

IBM's Rational Software Architect Softeam and Objecteering/UMLAn MDA CASE Tool

IKV++ GmbH; m2c(tm) CARE Technologies S.A. / SOSY Inc's OlivaNova Model Execution System

I-Logix' Rhapsody Tata Consultancy Services: MasterCraftinnoQ's iQgen Telelogic's TAU Generation2

TechOne's ACE

MDA tools list (from OMG site)



. - 130 -

This definition is compatible with OMG view

Object Reference Model SubCommittee (ORMSC )"The MDA guide"

66



. - 131 -

MDA concepts



. - 132 -

Transformation trace

67



. - 133 -

Some language engineering problems in MDA• UML was designed based on experience of researchers and practicioners: it

was essentially based on the integration of several modelling languages historically used to several activities of software engineering (a unifying view)

• CORBA was designed to integrate several technologies but no winner in its market segment has been recognised since its introduction; therefore, new meta models for new middlewares will be required

• MDA is designed for accomodating several meta-models and to specify transformations between models and meta-models but:

• No guidelines for making meta-models: they are essentially based participants to their definition; stability of these meta-models can be questionable; OMG is a centralized administrative organisation that limits its activities to coordinate and to mediate among proposals issued from requirements but as all the standardisation organisations lacks in taking into account foundations

• MOF 2.0 is essentially an object-based representation of a storage format for meta-models; in the early stage of OMG activities it was enough because essentially only one meta-model (i.e. the UML) was defined and required; MOF is very simple and semanticsof modelling languages is difficult to be coded in MOF (and not explicit)

• Transformations are not fully integrated with MOF (i.e. they are not a primitive element of MOF) and cannot be explained within MOF

• MDA is highly focused on software; meta-models used in business/enterprise and software requirements are not really addressed while mentioned



. - 134 -

Our proposal

• To review the meta meta level and found it on stronger foundations

• To introduce a way for precise modelling modelling languages based on these foundations towards unique and stable meta-models

• To broadly cover specialised modelling languages issued from specific communities of experts

• To address the question of quality of meta-models• To overcome to the centralised standard

organisations dealing with languages; on top of the difficulties generated by agreement, the need to coordinate across standards is recognized as a big issue

Emerging trends?: open source modelling languages or a web of languages

68



. - 135 -





• Part 3: Language engineering in UEML (Unified Enterprise Modeling Language) 2.0



. - 136 -

Context

Enterprise modelling

Software requirements modelling

Software modelling

WHY

WHAT

HOW

Enterprise Architectures

Software A

rchitectures

69



. - 137 -

Three main axis

• Modelling modelling languages• Meta meta models based on BWW and on the general language

structure (notation, abstract syntax, semantic domain and representation mapping)

• Quality of modelling languages• Development of an Extended Quality Framework (EQF) for

selection of languages and modelling constructs

• Correspondences between distinct modelling languages• Definition of correspondences between modelling constructs



. - 138 -

WEB of Languages

Models

Represented models accordingto languages

Relationships (Mappings) between models

Languages

Represented languages accordingto a meta meta model

Correspondences between languages

High Quality Languages

Core Languages ???

High Quality Models

70



. - 139 -

WEB of languages

Under development

Under refinement

MM model

PresentationModel Ontology Model

Representation Model

* *

Ontology

«instance»

RepresentedConstructs Object

Diagram

«instance»

Language MetaModels

LanguageDocumentation

«refines» «refines»

BWWOntology

CorrespondencesMM Model

«derived»

«import»

«import»

Quality MMModel

RequirementsCollection Model

QualityFramework

«import»«import»

QualityAssessment

Methods

«import»

«uses»

«uses»

«instance»

Statistic models

«uses»



. - 140 -

Short introduction to BWW

71



. - 141 -



. - 142 -

72



. - 143 -



. - 144 -

How UEML 2.0 works

Language1/ Construct1

Revealed classes/properties/s

tates/eventsinstantiating the

meta meta-model

UEML CoreTo reveal To generate

The UEML construct template

revealed UEML ontology

LanguageN/ ConstructN

Several categories of

correspondencesTo find

revealed correspondences

The Extended Quality Framework

Appropriateness Quality

criterion

Requirements

Case: Requirements focusing on Enterprise Modelling for Interoperability

Quality MMModel

MM model

73



. - 145 -

UEML 2.0 Meta-Meta-model V1 (origin)

Opdahl&Henderson-Sellers,2004&2005

Abstract Syntaxt

Semantic domain

Representation mapping



. - 146 -

UEML 2.0 meta meta-model V2

74



. - 147 -

UEML 2.0 Meta-Meta-model V2



. - 148 -

How the UEML 2.0 meta meta model is originated• Describing the ontology structure based on existing

ontologies; in modelling languages the most known is BWW (Bunge Weber Wand), being Weber and Wand having shown in the past to what extent BWW covers most of the information systems modelling language constructs

• Till now, most of the research works on BWW have been used to describe in papers (i.e. in text) construct of modelling languages to evaluate quality aspects (such as completeness), limiting the discussion to research; introducing a BWW based meta meta model and implementing it in a tool, provides the sound base to effectively use all these representations of modelling constructs, enabling comparison (correspondences), reuse, improvement and finally supporting agreement process

• Distilling the BWW ontology and providing a set of concepts that allows to describe any modelling construct i.e. class of things, thing/type, property of things, state and event (now transformation)

• Using these concepts to describe modelling constructs, by possibly reusing BWW concepts again

75



.

KAOS/GRL work



. - 150 -

Outline

• Research method• Selection of GRL constructs• Selection of KAOS constructs• Modelling modelling constructs

• Correspondences of GRL and KAOS constructs• Common ontology

76



. - 151 -

Research method

•GRL• (ITU, 2003)

•KAOS• (Letier, 2001)• (van Lamsweerde,

2003)



. - 152 -

GRL metamodel

• GRL metamodel• 11 constructs

77



. - 153 -

KAOS metamodel

• KAOS meta model for goal model• 25 constructs



. - 154 -

UEML 2.0 Meta-Meta-model V1

Opdahl&Henderson-Sellers,2004&2005

78



. - 155 -

GRL construct into UEML 2.0 meta meta model and BWW



. - 156 -

KAOS construct into UEML 2.0 meta meta model and BWW

79



. - 157 -

Simplified representation of constructs



. - 158 -

Meaning of Goal

• Goal in GRL

80



. - 159 -

Meaning of Goal (cont.)

• Goal in KAOS



. - 160 -

Meaning of Goal (cont.)

81



. - 161 -

Open question

• How to state the correspondences between constructs?

• In the example, some hypotheses are formulated and then they are verified throughout the ontology

• Is there any other approach? Is the ontology made too much general?



. - 162 -

Open question

• What should be a correspondence in UEML?

• Two constructs should correspond if they can be used for representing the same classes, properties, transformations and states according to the ontology

• More complex correspondences are possible (i.e. more constructs to more constructs but they might be approached in other ways eventually)

82



. - 163 -

Research Questions: a RoadmapR

oadm

ap d

imen

sion

s



. - 164 -

Conclusions

• Meta modelling or language engineering is the key way for achieving objectives of MDE

• Laenguage engineering is however a new field that requires research for understanding

• Language engineering also needs understanding of correspondences between distinct languages for both improving the meta modeling and for assessing the correspondences between models

83



. - 165 -

Main References on UEML 2.0 work• Deliverable DEM 1 at www.interop-noe.org (public)• Berio G. UEML 1.0 and UEML 2.0: benefits, problems and comparison. In

Proceedings of the Workshop on Enterprises and Networked Enterprises Interoperability (ENEI05) - Workshop ENEI joint with BPM05 -International Conference on Business Process Management 2005 - Nancy, France, September 2005. LNCS 3812.

• Opdahl A.L. The UEML Approach to Modelling Construct Description. In Proceedings of I-ESA 2006, Bordeaux, France, Springer.

• Opdahl A.L. Berio G., A Roadmap for UEML. In Proceedings of I-ESA 2006, Bordeaux, France, Springer.

• Opdahl A.L. Berio G., Interoperable Language and Model Management Using the UEML Approach. In Proceeding of the Intl. Workshop on Global Integrated Model Management (GaMMA06) joint with ICSE 2006, Shanghai, China, May 2006.

• Berio G., Petit, M., “Enterprise Modelling and the UML: (sometimes) a conflict without a case”. In Proceedings of the Concurrent Engineering Conference, 26-30 July 2003, Madeira, Portugal.

• Matulevičius, R. Heymans P. and Opdahl A.L. Comparison of Goal-oriented Languages using the UEML Approach. In Proceedings of Workshop EI2N 2006, joint with I-ESA 2006, Bordeaux, France, Springer.

introduction to language engineeringbaroglio/summerschool06/slides/gb...introduction to language...

Documents