Lecture 12 Model Driven Architecture and Other Special

Lecture 12: Model Driven Architecture and Other Special Topics 1

1. System Development Evolution 2

System Development Evolution (1) Initial Generation Developer Machine Language Programs Executable System 3

System Development Evolution (2) In the early days, programmers had to use machine language They had to know the instruction set and architecture details for each machine and all connected peripherals Since architectures were simple, this was a manageable approach (Embedded systems might impose similar requirements today. . . ) 4

System Development Evolution (3) Second Generation High-Level Language Programs Developer Compiler Object Code Executable System 5

System Development Evolution (4) Early compiler-based languages (FORTRAN, ALGOL, . . . ) provided n n n Fundamental arithmetic and logical operators A simple type system Rudimentary I/O and formatting operations Some extensions through mathematical, statistical and simple graphics libraries Everything else had to be explicitly programmed (= re-invented!) 6

System Development Evolution (5) Third Generation Object-Oriented Language Programs Class Libraries Compiler Object Code Executable System 7

System Development Evolution (6) Today’s compiler-based languages (C++, Java, Modula-3, . . . ) provide n n n More elaborate arithmetic and logical operators Object-oriented concepts and strong typing Type-safe I/O and formatting operations through special objects and methods Some languages (in particular C++) provide a formal concept for language extensions 8

System Development Evolution (7) Most importantly: Today’s language are complemented with Class Libraries, which provide: n An extensive set of new, complex data types (List, Set, Map, Vector, Iterator, graphic elements. . . ) n An extensive set of new control constructs (Thread, Mutex, Semaphore, Event, . . . ) n n Implementations of design pattern Component models The idea is to replace re-invention by re-use 9

System Development Evolution Next Generation (MDA) (8) Platform. Independent System Model Provides Model Library Developers use Modeling Language Class Libraries Code Generator MOF Compiler Object Code Executable System 10

System Development Evolution (9) In the future, designs will be formulated as Platform Independent Models (PIM) using a modeling language (i. e. UML) Other models might be included or referenced (similar like a library) The PIM contains the pure problem solution, unencumbered by platform specific details The PIM preserves this knowledge even if the platform changes 11

System Development Evolution (10) The PIM is transformed or mapped into a set of Platform Specific Models (PSM), using platform specific mappings. Each PSM is transformed into “normal” programming language code using code generation and component libraries This code is compiled and linked, using normal compilers, class libraries and regular libraries 12

And the Benefit is. . . ? Models are more intuitive and a better approximation of the creative thinking Models focus on the solution itself, not on tiny implementation details Good PIMs may survive multiple evolutions of the underlying platform with no or only little need for modification Mature code generators will reduce the number of coding errors drastically 13

Does it really work. . . ? Yes. . . but. . . To solve the “general problem”, further development of the technology is needed Under certain constraints, the technology will be available rather in months than in years For very special cases the technology has been successfully demonstrated (e. g. UMTS base station controller software) 14

Under Certain Constraints. . . If the code generation is mostly limited to component collaboration If the modeling language is constraint to component collaboration, and associated data flow and process modeling problems This may require he definition of a new modeling language. . . 15

UML Family of Languages To ensure consistency, the language definition must be standardized This can be achieved through a consistent set of metamodels for the family of languages And that can be achieved through a common meta-metamodel for the family of languages This is why the Meta Object Facility (MOF) plays an important role in this new system development technology 16

EDOC CCA A very interesting example is the “Component Collaboration Architecture (CCA) It defines the static, dynamic and global interaction between components Originally intended for “Enterprise Components”, but widely applicable beyond that Defined in the OMG specification “UML Profile for Enterprise Distributed Object Computing” (EDOC) 17

EDOC-based Process Modeling 18

Component Notation (i. e. Activity) Port name Choreography (~ Control Flow) Data Flow Event Channel input group output group 19

2. A Gentle Introduction into the Fun of Metamodeling 20

Even here: “Hello World”… One of the most famous programs ever developed is the “Hello World” program, introduced by Brian Kernighan and Dennis Ritchie in the early 70 -ies to demonstrate a simple C program. Let’s see how we can abuse this program for a gentle introduction into the land of metamodeling… 21

First try… Very silly Very inflexible But legal… main(argc, argv[]) { putchar(‘”’); putchar(‘H’); putchar(‘e’); putchar(‘l’); putchar(‘o’); putchar(‘W’); putchar(‘o’); putchar(‘r’); putchar(‘l’); putchar(‘d’); putchar(‘!’); putchar(‘”’); putchar(‘n’); } 22

Direct Instance Programming The presented program is an example of direct instance programming This is a very un-economic style: n n n Single solution only – no reuse possible Every little change requires programming Hard to read and understand 23

Second try… main(argc, argv[]) { char text[15] = ””Hello World!””; printf(“%c%c%c%c%c%c%cn”, text); } Better… But still very inflexible 24

Using a “Format” The format string (“%c…n”) represents metadata n n that is data describing other data, or data directing the processing of other data However, the selected form does not take advantage of available type information 25

Third try… main(argc, argv[]) { char text[15] = ””Hello World!””; printf(“%sn”, text); } Even better… But still inflexible (restricted to strings) 26

Taking Advantage of Type Info The previous format string (“%c…n”) had a fixed size format The new format string (“%sn”) takes advantage of type information” n n C strings can have arbitrary length C strings have a built-in end delimiter Now our metadata describes any string 27

Fourth try… main(argc, argv[]) { char format[4] = ”%sn”; char text[15] = ””Hello World!””; printf(format, text); } Improved flexibility (format is now variable) 28

Variable Metadata Variable metadata makes run-time adaptation possible Variable metadata allows the design of generic function elements Any (format) change involves just the change of metadata 29

Now, let’s close the loop… If metadata can successfully describe data then we can use other metadata to describe this metadata èWe call these “meta-metadata” Meta-metadata is typically more uniform than metadata or (instance-)data 30

This means for our Program: The (instance-)data (“text” in our program) can actually have any form and type combination It is described by the meatadata (“format”), which is a string Therefore, meta-metadata needs only the capability to describe a string 31

With Meta-Metadata … main(argc, argv[]) {. . . char format[80]; char text[15] = ””Hello World!””; sscanf(format, “%s”, x, y, z); printf(format, text); } In this case, meta-metadata is a constant! 32

Summary … Data can be described by other data, called metadata A change in data type and/or composition requires only a regular data change at metalevel This concept can be applied recursively We will eventually reach a level where metainformation is constant 33

Conclusion The use of recursive meta-data allows a fixed implementation to handle virtually all kind of information Any adaptation can be accommodated by change of metadata. No, or only minimal programming is required However, this kind of systems tend to be complex 34

3. The Famous 4 -Level Meta-Architecture 35

Number of Meta-Levels (1) At least two levels required No upper limit for the number of meta-levels by theory Practice has shown that four meta-levels are sufficient for almost all cases 36

Number of Meta-Levels (2) “meta-…. ” usually confusing Therefore introduction of a meta-level numbering scheme: n n n M 0 is the bottom, the instance level M 1 is the first meta-level M 2. . . 37

The 4 -Level Meta-Architecture M 3 M 2 Meta-Meta-Data or Meta-Model Level M 1 Meta-Data or Model Level M 0 Instance Level 38

The Meta Object Facility (MOF) (1) The de-facto standard for metamodel management Developed at the OMG Has close relationship with UML Implements the 4 -level meta-architecture Has a M 3 implementation (“MOF Model”) Incorporates a repository 39

The Meta Object Facility (MOF) (2) The MOF Model relies heavily on reflection (means its model elements are defined by themselves – like a reflection in a mirror) The basic MOF elements are: § Type § Class § Property § Operation § Relationship § Annotation § Package 40

The Meta Object Facility (MOF) (3) The “usual” MOF Model contains much more elements, defined through the basic elements Many of these elements are abstract and exist only for modeling convenience The real elements define a modeling language “MOF Language” which can be used on its own or to define other languages 41

The MOF Model (M 3) 42

The MOF Model (M 3) Model. Element /Depends On Constrains 0. . * 1. . * Contains Attaches. To 0. . * Namespace Import Tag 0. . * {ordered} 0. . * Typed. Element Constraint Aliases 0. . * +typed. Element Is. Of. Type Generalizable. Element Feature Parameter Structure. Field Constant Generalizes +type Package 1 Classifier Behavioural. Feature Structural. Feature Association. End /Exposes 1 1 Referes. To 0. . * Association Class Data. Type Exception Operation Attribute Reference Can. Raise 0. . * Primitive. Type Structure. Type 0. . * {ordered} Enumeration. Type Collection. Type Alias. Type 43

Relationship to UML (1) The UML Metamodel is a M 2 model Your model using UML is a M 1 model The instantiations of your UML classes (UML Objects) are at M 0 The (M 3) MOF Model is used to define the UML Metamodel 44

Relationship to UML (2) M 3 MOF Model M 2 UML Meta-Model M 1 (Your) UML Model M 0 (Your) UML Objects 45

Summary Four meta-levels are typically enough The MOF implements by default all four metalevels (but is not limited to four) UML fits nicely into this meta-architecture UML V 2 and MOF V 2 even share a common core model 46

4. A Small Meta-Modeling Example 47

Simple Relational M 2 Model (1) Tables and Columns are named Each Table has at least one Column Each Column belongs to only one Table Columns are ordered inside the Table The existence of Columns depends on the hosting Table No inheritance 48

Simple Relational M 2 Model (2) 49

Simple Relational M 2 Model (3) Instances of MOF Class 50

Simple Relational M 2 Model (4) Instance of MOF Generalizes 51

Simple Relational M 2 Model (5) Instance of MOF Association 52

Simple Relational M 2 Model (6) Instances of MOF Association. End 53

From M 2 to M 1 (and to M 0) The M 2 meta-model defines a language to create (M 1) models The M 2 constructs are in turn defined by the (M 3) MOF language M 1 models are “normal” user-created models expressed in a language defined by M 2 Instantiations of M 1 classes are the (M 0) “runtime objects” 54

Resulting Relational M 1 Model (1) 55

Resulting Relational M 1 Model (2) The shown M 1 classes are instances of M 2 classes However, on M 1 level these classes are “normal” classes These classes can be instantiated by M 0 instances 56

Final Relational M 0 Data Number 014876 017839 019496 020253 Name John Smith Herta Bauer Eric Mayer Lin Chin Fu Address 110 Main Street Some. Town 1900 1 st Avenue Super. City 13 Bunny Trail Microville 110 Lane 3 China. Town 57

How to Use MOF Technology The MOF plays an important role for: Model management n we have just seen this… Model transformation n we need to specify the transformations Automated implementation generation n we need implementation generators 58

Make the Transition. . . Third Generation Object-Oriented Language Programs Class Libraries Compiler Object Code Executable System 59

. . . into the Future ! Next Generation (MDA) Platform. Independent System Model Provides Model Library Developers use Modeling Language Class Libraries Code Generator MOF Compiler Object Code Executable System 60

More about MDA. . . Lecture ISY G 280 “Model Driven Approach to Component Based Software Systems” Spring Semester, Mondays 6 pm – 9. 30 pm (1800 – 2130) (Also on the network. . . ) 61

Thank You. . 62