The ―Theory‖ and Practice of Modeling Language Design (for Model-Based Software Engineering) Bran Selić Malina Software Corp. Zeligsoft (2009) Ltd. Simula Research Labs, Norway University of Toronto, Carleton University [email protected] © Copyright Malina Software A Programming Language Sample

SC_MODULE(producer) SC_CTOR(consumer) { { sc_outmaster out1; SC_SLAVE(accumulate, in1); sc_in start; // kick-start sum = 0; // initialize }; void generate_data () SC_MODULE(top) // container { { for(int i =0; i <10; i++) { producer *A1; out1 =i ; //to invoke slave;} consumer *B1; } sc_link_mp link1; SC_CTOR(producer) SC_CTOR(top) { { SC_METHOD(generate_data); A1 = new producer(“A1”); sensitive << start;}}; A1.out1(link1); SC_MODULE(consumer) B1 = new consumer(“B1”); { B1.in1(link1);}}; sc_inslave in1; int sum; // state variable void accumulate (){ sum += in1; }

2 © Copyright Malina Software …and its Model

«sc_method» «sc_link_mp» «sc_slave» A1:producer link1 B1:consumer start out1 in1

3 © Copyright Malina Software Spot the Difference…

SC_MODULE(producer) SC_CTOR(consumer) { { sc_outmaster out1; SC_SLAVE(accumulate, in1); sc_in start; // kick-start sum = 0; // initialize }; void generate_data () SC_MODULE(top) // container { { for(int i =0; i <10; i++) { producer *A1; out1 =i ; //to invoke slave;} consumer *B1; } sc_link_mp link1; SC_CTOR(producer) SC_CTOR(top) { { SC_METHOD(generate_data); A1 = new producer(“A1”); sensitive << start;}}; A1.out1(link1); SC_MODULE(consumer) B1 = new consumer(“B1”); { B1.in1(link1);}}; sc_inslave in1; int sum; // state variable void accumulate (){ sum += in1; «sc_link_mp» } «sc_method» «sc_slave» A1:producer B1:consumer start out1 link1 in1

4 © Copyright Malina Software Tutorial Outline

 Models: What and Why

 Modeling Language Design

 Modeling Language Specification

 Model Transformations

 Summary

5 © Copyright Malina Software Why is Software so Problematic?

 COMPLEXITY! . The machines we construct with computer software are often required to realize complex functionality . ...and it has to interact with a physically complex world (including the hardware that runs it)  A useful distinction to keep in mind:  Essential complexity . Immanent to the problem  Cannot be eliminated by technology or method  Accidental complexity . Usually due to technology or methods used . This is the one we can fix

6 © Copyright Malina Software Coping with Complexity  ABSTRACTION: Selective reduction of information of a system which preserves its salient properties relative to a given set of concerns . Often, our only coping mechanism

SYSTEM

7 © Copyright Malina Software Models = Outcomes of Abstraction

 A model is a set of ―statements‖ about a system under study [Seidewitz]*  Involves three core elements:

Interpretation (Abstraction)

System under study Model(s)

* E. Seidewitz, “What models mean”, IEEE Software, Sept./Oct. 2003 8 © Copyright Malina Software Engineering Models

 ENGINEERING MODEL: A selective representation of some system that captures accurately and concisely all of its essential properties of interest for a given set of concerns • We don‘t see everything at once • What we do see is adjusted to human understanding

9 © Copyright Malina Software Why Do Engineers Build Models?

 To understand . ...problems and solutions . Knowledge acquisition  To communicate . ...understanding and design intent . Knowledge transfer  To predict . ...the interesting characteristics of system under study . Models as surrogates  To specify . ...the implementation of the system . Models as ―blueprints‖

10 © Copyright Malina Software Types of Engineering Models

 Descriptive: models for understanding, communicating, and predicting . E.g., scale models, mathematical models, qualitative models, documents, etc. . Tend to be highly abstract (detail removed)  Prescriptive: models as specifications . E.g., architectural blueprints, circuit schematics, state machines, pseudocode, etc. . Tend to be detailed so that the specification can be implemented

Q: Is it useful to have models that can serve both kinds of purposes?

11 © Copyright Malina Software Characteristics of Useful Engineering Models

 Purposeful: . Constructed to address a specific set of concerns/audience  Abstract . Emphasize important aspects while removing irrelevant ones  Understandable . Expressed in a form that is readily understood by observers  Accurate . Faithfully represents the modeled system  Predictive . Can be used to answer questions about the modeled system  Cost effective . Should be much cheaper and faster to construct than actual system To be useful, engineering models must satisfy at least these characteristics!

12 © Copyright Malina Software Modeling Software

13 © Copyright Malina Software What‘s a Software Model?

 SOFTWARE MODEL: An engineering model of a software system from one or more viewpoints specified using one or more modeling languages . E.g.:

left:B right:B

B m1

0..* 0..* m2 A B «import» m3 0..1 a : A 0..* C m4 left:B right:B c : C

Structural Execution (design-time) (run-time) view view

18 © Copyright Malina Software Classical SW Modeling: SA/SD

PH reached X start

Monitor Control Current PH PH PH

stop Raise PH Q: What does this Input valve ―bubble‖ really mean? control Q: How is it implemented in code? ―…bubbles and arrows, as opposed to programs, …never crash‖ Modeling languages -- B. Meyer have yet to ―UML: The Positive Spin‖ recover from this American Programmer, 1997 ―debacle‖

19 © Copyright Malina Software ―Classical‖ Modeling Languages

 Flow charts, SA/SD, 90‘s OO notations (Booch, OMT, OOSE, UML 1)  Most of them were intended exclusively for constructing descriptive models . Informal ―sketching‖ [M. Fowler]* . No perceived need for precision . Languages are ambiguous and open to interpretation  source of undetected miscommunication

*http://martinfowler.com/bliki/UmlAsSketch.html

21 © Copyright Malina Software New Generation of Modeling Languages

 Formal languages designed for modeling  Support for both descriptive and prescriptive models . ...sometimes in the same language  Key objectives: . Well-understood and precise semantic foundations . Can be formally (i.e., mathematically) analyzed (qualitative and quantitative analyses) . And yet, can still be used informally (―sketching‖) if desired

22 © Copyright Malina Software Modeling vs Programming Languages

 The primary purpose and focus of programming languages is implementation . The ultimate form of prescription  Implementation requires total precision and ―full‖ detail  Takes precedence over description requirements  To be useful, a modeling language must support description . I.e., communication, prediction, and understanding . These generally require omission of ―irrelevant‖ detail such as details of the underlying computing technology used to implement the software

23 © Copyright Malina Software Computer Languages

 Much of the evolution of computer languages is motivated by the need to be more human-centric Degree of Application (computing specific technology) abstraction

Modeling languages

Classical (3G) programming languages Can we do the same here ? Computing Assemblers (2G), technology machine Compiler specific languages (1G) filled detail Implementation level

24 © Copyright Malina Software Components of a Modeling Language

 The definition of a modeling language consists of:

. Set of language concepts/constructs (―ontology‖)

• e.g., Account, Customer, Class, Association, Attribute, Package . Rules for combining language concepts (well-formedness

rules)

SYNTAX ABSTRACT • e.g., ―each end of an association must be connected to a class‖ . CONCRETE SYNTAX (notation/representation) • e.g., keywords, graphical symbols for concepts • Mapping to abstract syntax concepts . SEMANTICS: the meaning of the language concepts • Comprises: Semantic Domain and Semantic Mapping (concepts to domain)

25 © Copyright Malina Software Elements of a Modeling Language

Modeling Language

0..1

0..* 1 Concrete Semantics Syntax Mapping Mapping 1 0..* 1..* 0..* 1 Concrete Abstract 0..* 1..* Semantics Syntax Syntax Domain

Semantics

26 © Copyright Malina Software Model-Based Engineering (MBE)

 An approach to system and software development in which software models play an indispensable role  Based on two time-proven ideas:

(1) ABSTRACTION (2) AUTOMATION

S1 e3/action3 S1 e3/action3

S3 S3 Realm of Realm of e1/action1 e1/action1 modeling e2/action2 e2/action2 tools languages S2 S2

switch (state) { switch (state) { case„1:action1; case„1:action1; newState(„2‟); newState(„2‟); break; break; case„2:action2; case„2:action2; newState(„3‟); newState(„3‟); break; break; case‟3:action3; case‟3:action3; newState(„1‟); newState(„1‟); break;} break;}

27 © Copyright Malina Software Model-Driven Architecture (MDA)™

 In recognition of the increasing importance of MBE, the Object Management Group (OMG) is developing a set of supporting industry standards

(1) ABSTRACTION (2) AUTOMATION

(3) INDUSTRY STANDARDS • UML 2 • OCL • MOF • SysML http://www.omg.org/mda/ • SPEM • …etc.

28 © Copyright Malina Software Tutorial Outline

 Models: What and Why

 Modeling Language Design

 Modeling Language Specification

 Model Transformations

 Summary

29 © Copyright Malina Software Primary Language Design Concerns

 Who are the primary end users? . Authors / readers? (i.e., primary use cases)  What kind of models do they want? . Descriptive, prescriptive, or both?  What is the domain? . What is the application domain and what are its salient technical characteristics?

30 © Copyright Malina Software Sidebar: Feature Diagram Essentials

Mutually exclusive alternatives (exclusive or) Feature or concept PC Purchase Mandatory Configuration sub-feature Optional sub-feature

1 GB 3 GB Windows 7 Linux Extras RAM RAM OS OS

Inclusive-or alternatives (but, at least 1) DVD Display Printer drive Screen

31 © Copyright Malina Software Key Language Design Choices

Modeling Language Features

Scope Specification

Abstraction Extension Range

Concrete Precision Syntax Level Model Model of Type Computation

Some choices are inter-dependent

32 © Copyright Malina Software Selecting Language Scope

 A common opinion: ―Surely it is better to design a small language that is highly expressive, because it focuses on a specific narrow domain, as opposed to a large and cumbersome language that is not well-suited to any domain?‖  Which suggests:

Scope

But, this may be an Domain- General Specific Purpose oversimplification

33 © Copyright Malina Software Scope: How General/Specific?

 Generality often comes at the expense of expressiveness . Expressiveness: the ability to specify concisely yet accurately a desired system or property . Example: • UML does not have a concept that specifies mutual exclusion devices (e.g. semaphore)  to represent such a concept in our model, we would need to combine a number of general UML concepts in a particular way (e.g., classes, constraints, interactions) . ...which may(?) be precise, but not very concise  It also comes at the cost of detail that is necessary to: . Execute models . Generate complete implementations

34 © Copyright Malina Software Specialization: Inevitable Trend

 Constant branching of application domains into ever- more specialized sub-domains . As our knowledge and experience increase, domain concepts become more and more refined • E.g., simple concept of computer memory → ROM, RAM, DRAM, cache, virtual memory, persistent memory, etc.  One of the core principles of MBE is raising the level of abstraction of specifications to move them closer to the problem domain

• This seems to imply that domain-specific languages are invariably the preferred solution • But, there are some serious hurdles here...

35 © Copyright Malina Software The Case of Programming Languages

 Literally hundreds of domain-specific programming languages have been defined over the past 50 years . Fortran: for scientific applications . COBOL for ―data processing‖ applications . Lisp for AI applications . etc.  Some relevant trends . Many of the original languages are still around . More often than not, highly-specialized domains still tend to use general-purpose languages with specialized domain-specific program libraries and frameworks instead of domain-specific programming languages . In fact, the trend towards defining new domain-specific programming languages seems to be diminishing  Why is this happening?

36 © Copyright Malina Software Success* Criteria for a Language (1)

 Technical validity: absence of major design flaws and constraints . Ease of writing correct programs  Expressiveness  Simplicity: absence of gratuitous/accidental complexity . Ease of learning  Run-time efficiency: speed and (memory) space  Familiarity: proximity to widely-available skills . E.g., syntax

* ―Success‖  language is adopted by a substantive development community and used with good effect for real-world applications

37 © Copyright Malina Software Success Criteria for a Language (2)

 Language Support & Infrastructure: . Availability of necessary tooling . Effectiveness of tools (reliability, quality, usability, customizability, interworking ability) . Availability of skilled practitioners . Availability of teaching material and training courses . Availability of program libraries . Capacity for evolution and maintenance (e.g., standardization)

38 © Copyright Malina Software Sidebar: Basic Tooling Capabilities

 Essential  Useful (to Essential) . Model Authoring . Code generation . Model validation . Model simulation/debug/trace (syntax, semantics) . Model transformation . Model export/import . Model review/inspection . Document generation . Collaborative . Version management development support . Model compare/merge . Language customization support . Test generation . Test execution . Traceability

39 © Copyright Malina Software Language Size

 How complex (simple) should a language be to make it effective?

limited expressive simple complex

Turing C Java PL/I C++ Java + machine Basic Java libs + language Java-based frameworks . The art of computer language design lies in finding the right balance between expressiveness and simplicity – Need to minimize accidental complexity while recognizing and respecting essential complexity – Small languages solve small problems – No successful language has ever gotten smaller

40 © Copyright Malina Software Practical Issues of Scope

 Practical systems often involve multiple heterogeneous domains . Each with its own ontology and semantic and dedicated specialists  Example: a telecom network node system . Basic bandwidth management . Equipment and resource management . Routing . Operations, administration, and systems management . Accounting (customer resource usage) . Computing platform (OS, supporting services)

41 © Copyright Malina Software The Fragmentation Problem  FRAGMENTATION PROBLEM: combining overlapping independently specified domain-specific subsystems, specified using different DSLs, into a coherent and consistent whole (i.e., single implementation)

Network Node Call Processing System

Comm. Channel Resource Mgmt. System Bandwidth Mgmt. System

Sadly, there are no generic composition (weaving) rules – each case has to be handled individually

42 © Copyright Malina Software Approach to Dealing with Fragmentation

 Having a common syntactic and semantic foundations for the different DSLs seems as if it should facilitate specifying the formal interdependencies between different DSMLs

DSL1 Class Library DSL2 Class Library . . .etc. DSL1 Refinements DSL2 Refinements

Common Abstract Syntax and Semantic Foundation

 NB: Same divide and conquer approach can be used to modularize complex languages  Core language base + independent sub-languages (e.g., UML)

43 © Copyright Malina Software Selecting An Abstraction Range

Modeling Language Features

Scope Specification

Extension

Concrete Precision Syntax Abstraction Level Model Model of Range Type Computation

Executable

 This decomposes into two separate questions: . What is a suitable level of abstraction of the language? . How much (implementation-level) detail should the language concepts include?  The answers depend on other design choices

44 © Copyright Malina Software Abstraction Range of Computer Languages

Normally determined by How far up the type and level of do we go? description desired Application domain specific

Modeling language concepts

Normally determined by How much the type and level of detail do we prescription desired provide? Computing technology specific

45 © Copyright Malina Software Selecting a Precision Level

Modeling Language Features

Scope Specification

Abstraction Extension Range

Concrete Syntax Model Model of Precision Type Computation Level

Informal Formal

Ad Hoc Codified Precise Executable Implementation

46 © Copyright Malina Software Formality

 Based on a well understood mathematical theory with existing analysis tools . E.g., automata theory, abstract state machines, Petri nets, temporal logic, process calculi, queueing theory, Horne clause logic . NB: precise does not necessarily mean detailed  Formality provides a foundation for automated validation of models . Model checking (symbolic execution) . Theorem proving . However, the value of these is constrained due to scalability issues (―the curse of dimensionality‖)  It can also help validate the language definition  But, it often comes at the expense of expressiveness . Only phenomena recognized by the formalism can be expressed accurately

47 © Copyright Malina Software Precision vs. Detail

 A specification can be precise but still leave out detail: . E.g., we can identify a set very precisely without necessarily specifying the details associated with its members

Adults We state very precisely as to what Karl constitutes the set of Adults of some Bob population (age  21) Jill without being specific Fred about details such as names or genders of its members Alice Peggy back

48 © Copyright Malina Software Ad Hoc ―Languages‖

 Mostly notations created for specific cases (not intended for reuse)  Used exclusively for descriptive purposes  No systematic and comprehensive specification of syntax or semantics . Appeal to intuition Caster Poster Memory Messages CStack Manager Sockets BStack

Services Layer

File Print Log

RUF Core

49 © Copyright Malina Software Codified Languages

 Example: UML 1.x, OMT, SysML, ...  Characteristics: . Defined: An application-independent language specification exists . Some aspects of the language are fully defined (usually: concrete syntax, semantics) . Semantics usually based on natural language and other informal specification methods . Designed primarily for descriptive modeling . But, may also be used partly for specification (e.g., partial code generation/code skeletons)

50 © Copyright Malina Software Precise Languages

 Examples: Object Constraint Language (OCL), Layered Queueing Networks (LQN)  Fully defined semantics (domain and mapping)  High level of abstraction but typically cover relatively small range . I.e., lacking detail for execution or implementation . Often declarative  Mostly designed for prescription (e.g., prediction and analysis), but may also be used for specification

51 © Copyright Malina Software Executable Languages

 ―Models that are not executable are like cars without engines‖, [D. Harel]  Examples: Modelica, Matlab  A subcategory of precise languages covering a range that includes sufficient detail for creating executable models . But, may be missing detail required for automatic generation of implementations . Often based on operational semantics that may not be easily analyzed by formal methods (due to scalability issues)  Rationale: . Enables early detection of design flaws . Helps develop engineering intuition and confidence

52 © Copyright Malina Software How We Can Learn From Models ?

. By inspection X = cos (h + p/2) X = cos+ x*5 (h + p/2) + x*5 – mental execution – unreliable ?

. By execution X = cos (h + p/2) X =+ cos x*5 (h + p/2) – more reliable than inspection + x*5 – direct experience/insight

. By formal analysis ? – reliable (provided the models X = cos (h + p/2) X =+ cos x*5 (h + p/2) are accurate) + x*5 – formal methods do not scale very well

53 © Copyright Malina Software Executable Modeling Tool Requirements

 Ability to execute a model on a computer and observe its behavior . With possible human intervention when necessary  Key capabilities . Controllability: ability to start/stop/slow down/speed up/drive execution . Observability: ability to view execution and state in model (source) form . Partial model execution: ability to execute abstract and incomplete models

54 © Copyright Malina Software Implementation (Modeling) Languages

 Computer languages that: . Provide concepts at high levels of abstraction suitable for descriptive purposes, and also . Include detailed-level concepts such that the models can provide efficient implementations through either automatic code generation or interpretation  Examples: UML-RT, Rhapsody UML, etc.

55 © Copyright Malina Software Language Abstraction Levels

Degree of Application (computing specific technology) abstraction

Modeling languages

Classical (3G) programming languages

Computing Assemblers (2G), technology machine Compiler specific languages (1G) filled detail Implementation level

56 © Copyright Malina Software Full Range Modeling Languages

 A number of ―descriptive‖ modeling languages have evolved into fully-fledged implementation languages Degree of Application (computing specific technology) abstraction

Modeling e.g., UML Action languages Language Classical (3G) programming languages Action languages

Assemblers (2G), Computing Compiler Translator technology machine filled detail specific languages (1G) filled detail Implementation level

57 © Copyright Malina Software Precision Level Categories

 A more refined categorization based on degree of ―formality‖ . Precision of definition, internal consistency, completeness, level of detail covered

Category Characteristics Primary Purpose Defined, formal, consistent, Prediction, IMPLEMENTATION complete, detailed Implementation Defined, formal, consistent, Analysis, EXECUTABLE complete Prediction Analysis, PRECISE Defined, formal, consistent Prediction Documentation, CODIFIED Defined, informal Analysis Documentation, AD HOC Undefined, informal Analysis (no reuse)

58 © Copyright Malina Software Modern MBSE Development Style

 Models can be refined continuously until the application is fully specified  in the extreme case the model can become the system that it was modeling!

void generate () {for (int i=0; i<10; «sc_method» producer i++) producer {out1 = i;}} start out1

NotStarted producer start /generate ( )

NotStarted Started refine start St1 St2 Started

59 © Copyright Malina Software But, if the Model is the System...

 ...are we not losing the key abstraction characteristic of models?

• The computer offers a void generate () uniquely producer {for (int i=0; i<10; capable abstraction i++) device: {out1 = i;}} Software can be represented NotStarted from any desired viewpoint and at Model start /generate ( ) any desired level of Xform abstraction Started The abstraction resides within the model and can be St1 St2 extracted automatically

60 © Copyright Malina Software The Unique Nature of Software

 Software is a unique in that a program and its model share the same medium – the computer  The two can be formally linked to each other  This formal linkage can be realized by automated transformations implemented on a computer

61 © Copyright Malina Software A Unique Feature of Software

Software has the unique property that it allows us to directly evolve models into implementations without fundamental discontinuities in the expertise, tools, or methods!  High probability that key design decisions will be preserved in the implementation and that the results of prior analyses will be valid

62 © Copyright Malina Software Automatic Code Generation

 A form of model transformation (model to text) . To a lower level of abstraction  State of the art: . All development done via the model (i.e., no modifications of generated code) . Size: Systems equivalent to ~ 10 MLoC . Scalability: teams involving hundreds of developers . Performance: within ±5-15% of equivalent manually coded system

63 © Copyright Malina Software Major Telecom Equipment Manufacturer

 MBE technologies used . UML, Rational Technical Developer, RUP  Example 1: Radio Base Station . 2 Million lines of C++ code (87% generated by tools) . 150 developers  Example 2: Network Controller . 4.5 Million lines of C++ code (80% generated by tools) . 200 developers Benefits

80% fewer bugs 30% productivity increase

64 © Copyright Malina Software Styles of MBE

Levels of Abstraction Automation Code Round Trip Code only Model-centric Model only Visualization Engineering Model Model Model Model

visualize synchronize generate

Code Code Code Code

“What’s a “The code is “Manage “The model is “Who cares model?” the model” code and the code” about the model” code?”

Time

67 © Copyright Malina Software Roundtrip Engineering

Implementation transformation

Reverse engineering

NB: Slide idea borrowed from an itemis AG presentation 68 © Copyright Malina Software State of the Practice

Levels of Abstraction Automation Code Round Trip Code only Model-centric Model only Visualization Engineering Model Model Model Model Predominant State of the Practice visualize synchronize generate State of the Code Code Code Code Art

“What’s a “The code is “Manage “The model is “Who cares model?” the model” code and the code” about the model” code?”

Time

69 © Copyright Malina Software Selecting a Model Type

Modeling Language Features

With the Specification appropriate choice Scope of Abstraction Abstraction Extension Range and Range Precision Level in Concrete combination with Precision Syntax Level Model of suitable model Computation transforms, it is possible to define languages that Model Type support both types of models

Descriptive Prescriptive

70 © Copyright Malina Software Pragmatics: Multiple Models Needed

 In reality, it is generally not practical to have a single model that covers all possible levels of abstraction  But, it is possible to formally (i.e., electronically) couple different models via persistent model transforms

NB: The same language a' b' and tools are used for both models m'

Abstract Model

a1 a2 c1 c2 b2 b1

m1 m2 m3 m4 m6 m5

Detailed Model

71 © Copyright Malina Software Selecting a Model of Computation

Modeling Language Features

Scope Specification

Abstraction Extension Range

Concrete Precision Syntax Level Model Type

Model of Computation

 Model of Computation: A conceptual framework (paradigm) used to specify how a (software) system realizes its prescribed functionality . Where and how does behavior (i.e., computation) occur . Derived usually from domain semantics

72 © Copyright Malina Software Key Dimensions of MoC

 Involves a number of inter-related decisions

Model of Computation

Computational Semantic Paradigm Domain Concurrency Distribution Paradigm Paradigm

Causality Interaction Paradigm Paradigm

73 © Copyright Malina Software Selecting a Computational Paradigm

Model of Computation

Computational Semantic Paradigm Domain Concurrency Distribution Paradigm Paradigm

Causality Interaction Object Flow Paradigm Paradigm Oriented Based

ControlFlow DataFlow Based Based

74 © Copyright Malina Software Other MoC Dimensions

 Concurrency paradigm: does computation occur sequentially (single thread) or in parallel (multiple threads)?  Causality paradigm: what causes behavior . event driven, control driven, data driven (functional), time driven, logic driven, etc.  Execution paradigm: nature of behavior execution . Synchronous (discrete), asynchronous, mixed (LSGA)  Interaction paradigm: how do computational entities interact . synchronous, asynchronous, mixed  Distribution paradigm: does computation occur in a single site or multiple? . Multisite ( concurrent execution) vs. single site . If multisite: Coordinated or uncoordinated (e.g., time model, failure model)?

NB: These choices require a deep understanding of computing technology and cannot be made easily by non-experts

75 © Copyright Malina Software Semantics

 The meaning of language concepts  Specified by relating them to concepts of a ―well- understood‖ different domain . E.g.,

A class describes a set of objects UML that share the Shared Class human (concept) same specifications of knowledge features, constraints, and semantics

Semantic Mapping Semantic Domain

76 © Copyright Malina Software ―Formal‖ Semantics

 The mapping and the domain are defined using precisely defined domains and mappings . Formal mathematical frameworks (e.g., first-order logic, abstract state machines, process algebras, IO streams, etc.) or . Executable computer languages (e.g., Java, Prolog) • Which may themselves have a formal semantics definition  Example: . Base UML (bUML) is defined in terms of mappings to the Process Specification Language (PSL), which is itself based on situational calculus and first order logic . Foundational UML (fUML) is defined operationally as a bUML program

77 © Copyright Malina Software Selecting a Semantics Domain

 Avoid sophisticated mathematical formalisms . Difficult to understand and verify (unless suitable tools are available) . Operational methods are generally preferred in practice  Choose a domain with existing tool support . Enables verification of the semantics specification itself . Enables verification/prediction of model properties . Examples: • Abstract state machines • Temporal Logic of Actions • Process Specification Language

78 © Copyright Malina Software Pragmatics: Multiple (Nested) MoCs  Some modeling languages use a void generate () combination of {for (int i=0; i<10; producer i++) MoCs (e.g., UML) {out1 = i;}}

NotStarted Control-flow start /generate ( ) driven MoC «sc_method» producer Started start out1

St1 St2

Distributed MoC

Event-driven concurrent MoC

79 © Copyright Malina Software Selecting a Concrete Syntax

Modeling Language Features

Scope Specification

Abstraction Extension Range

Precision Level Model Model of Type Computation Concrete Syntax

Surface Interchange Syntax Syntax

80 © Copyright Malina Software State of the Art

―Very little is documented about why particular graphical conventions are used. Texts generally state what a particular symbol means without giving any rationale for the choice of symbols or saying why the symbol chosen is to be preferred to those already available. The reasons for choosing graphical conventions are generally shrouded in mystery.‖ [S. Hitchman]*

* S. Hitchman, “The Details of Conceptual Modeling Notations are Important – A Comparison of Relationship Normative Language”, Comms. of the AIS, 9, 2002.

81 © Copyright Malina Software Concrete Syntax Design

 Two main forms: . For computer-to-computer interchange (e.g., XMI) . For human consumption – ―surface‖ syntax  Designing a good surface syntax is the area that we understand least . If a primary purpose of models is communication and understanding, what syntactical forms should we use for a given language? . D. Moody, ―The ‗Physics‘ of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering‖, IEE Transactions on Software Engineering, vol. 35, no.6, Nov./Dec. 2009  Requires multi-disciplinary skills . Domain knowledge . Computer language design . Cognitive science . Psychology . Cultural Anthropology . Graphic design . Computer graphics

82 © Copyright Malina Software A Couple of Thoughts on Graphics

 ―Whenever someone draws a picture to explain a program, it is a sign that something is not understood.‖ – E. Dijkstra*  ―Yes, a picture is what you draw when you are trying to understand something or trying to help someone understand.‖ – W. Bartussek*

* Quoted in D.L. Parnas, “Precisely Annotated Hierarchical Pictures of Programs”, McMaster U. Tech Report, 1998.

83 © Copyright Malina Software Text vs. Graphics: Example

State: Off, On, Starting, Stopping; Initial: Off; Transition: {source: Off; target: Starting; trigger: start; stopped Off action: a1();} Transition: {source: Starting; target: On; start/a1() trigger: started;} Stopping Starting Transition: {source: On: stop/a2() target: Stopping; trigger: stop; action: a2();} Transition: On started {source: Stopping; target: Off; trigger: stopped;}

84 © Copyright Malina Software Surface Syntax

 Textual forms . Same as for programming languages: linear sequence of symbols . Usually specified as a type of BNF with terminals; e.g.: Surface ::= „ADD‟ <[arguments-list]> Syntax ::= „(„  Tabular forms . Constrained 2-dimensional Graphical Textual . E.g., spreadsheets, Parnas tables  Graphical forms Tabular . More complex: unconstrained 2-dimensional • Actually 2.5 dimensional – concept of Z-dimensions (overlapping graphics) . More flexible: user can choose which parts of the model to represent and how! • E.g., shape, line/fill styles, x-y position, size, font, etc.

DepositFunds vs. DepositFunds

85 © Copyright Malina Software Guidelines for Effective Visual Design

Different visual 1:1 correspondence dialects for between concepts different and symbols audiences 1. Semiotic Different concepts Clarity should have different symbols 2. Perceptual 6. Cognitive fit Discriminability

Cognitive Symbols should Effectiveness suggest meaning

5. Graphic 3. Perceptual Parsimony Immediacy

4. Visual Number of different Expressiveness graphical conventions Use full range should be cognitevly of visual managable variables * D. Moody and J.v.Hillegersberg, “Evaluating the Visual Syntax of UML: An Analysis of the Cognitive Effectiveness of the UML Suite of Diagrams”, 86 © Copyright Malina Software Extending an Existing Language?

Modeling Language Features

Scope Specification

Abstraction Range

Concrete Precision Syntax Level Model Model of Extension Type Computation

Define Extend

Refine

87 © Copyright Malina Software Approaches to DSML Design

1. Define a completely new language from scratch 2. Extend an existing language: add new domain- specific concepts to an existing (base) language 3. Refine an existing language: specialize the concepts of a more general existing (base) language

88 © Copyright Malina Software Refinement vs Extension

 Semantic space = the set of all valid programs that can be specified with a given computer language  Refinement: subsets the semantic space of the base language (e.g., UML profile mechanism) . Enables reuse of base-language infrastructure  Extension: intersects the semantic space of the base language

Base Language Space

Extension Refinement

89 © Copyright Malina Software Comparison of Approaches

Expressive Ease of Infrastructure Multimodel Approach Power Lang.Design Reuse Integration New Language High Low Low Low Extension Medium Medium Medium Medium Refinement Low High High High

90 © Copyright Malina Software Define, Refine, or Extend?

 Depends on the problem at hand . Is there significant semantic similarity between the base language metamodel and the new language metamodel? • Does every new language concept represent a semantic specialization of some base language concept? • No semantic or syntactic conflicts? . Is language design expertise available? . Is domain expertise available? . Cost of establishing and maintaining a language infrastructure? . Need to integrate models with models based on other DSMLs?  The ability to reuse the infrastructure of a language has often led to refinement or extension as the preferred choice . Not necessarily optimal from a purely technical viewpoint . E.g., Z.109 (SDL profile of UML), SysML4Modelica (SysML profile), SystemC (UML profile), AADL (UML profile), MoDAF/DoDAF (UML profile)…

91 © Copyright Malina Software Selecting a Language Specification Method

Modeling Language Features

Scope Specification

Abstraction Extension Range

Concrete Precision Syntax Level Model Model of Type Computation

 What methods should be used to specify a modeling language?

92 © Copyright Malina Software Summary: Modeling Language Design

 Modeling language design is still much more of an art than a science . Few reference texts; no consensus  Doing it well requires a rare combination of skills: . Understanding of modeling technologies, computer language technologies, domain knowledge, and even non-technical knowledge such as cognitive psychology . Many complex technical and non-technical design choices and tradeoffs need to be made  DSMLs are an important and inevitable trend, but the often advertised notion of ―end-user language design‖ is far from practical reality

93 © Copyright Malina Software Tutorial Outline

 Models: What and Why

 Modeling Language Design

 Modeling Language Specification

 Model Transformations

 Summary

94 © Copyright Malina Software Elements of a Modeling Language

Modeling Language

0..1

0..* 1 Concrete Semantics Syntax Mapping Mapping 1 0..* 1..* 0..* 1 Concrete Abstract 0..* 1..* Semantics Syntax Syntax Domain

Semantics

95 © Copyright Malina Software Tutorial Outline

 Models: What and Why

 Modeling Language Design

 Modeling Language Specification

. Specifying Abstract Syntax . Specifying Concrete Syntax . Specifying Semantics . Case Study: UML

 Model Transformations

 Summary

96 © Copyright Malina Software Data and Metadata

Legend:

Line A Line B

Line C Line D

The metadata

The data

97 © Copyright Malina Software Metamodeling Approaches

 Abstract syntax specified by a model using a domain-specific modeling language . i.e., a language for defining abstract syntaxes . Metamodeling language  Notable metamodeling languages . OMG‘s MetaObject Facility (MOF) . Eclipse‘s Eclipse Modeling Framework (EMF) . Xactium‘s XMF

98 © Copyright Malina Software Metamodels vs. Other Specification Styles

 Models explicitly capture potentially intricate relationships between the elements of a model . Models map naturally to graphs  BNF specifications are tuned to linear text-based syntactical forms . Typically parsed into ―abstract syntax trees‖ (ASTs) that obscure some relationships  need to rely on element identifiers to reconstitute them  Equivalent constraints apply to XML-based approaches . Still, XML is typically used to interchange model specs . Generated from models as a linear representation

99 © Copyright Malina Software The OMG‘s 4-Layer ―Architecture‖

01011 <2 tons> 01011 01011 Real Objects <5 tons> (computer memory, (M0) run-time environment)

«representedBy» «representedBy» «representedBy»

Customer CustomerOrder Model (M1) id item (model repository) quantity

«specifiedBy» «specifiedBy» (M2 = UML, Class Association . . . Meta-Model (modeling tool) CWM)

«specifiedBy»

Class(MOF) . . . Meta-Meta-Model (M3 = MOF) (modeling tool) «specifiedBy»

100 © Copyright Malina Software The Structure of MOF (simplified)

UML Infrastructure

EMOF

«merge» «merge» «merge» «merge»

Reflection Identifiers Extension CMOF

101 © Copyright Malina Software Essential MOF Concepts (Example) Package  Key concepts used to define an abstract syntax (modularization construct)

Generalization Vehicle (relationship) Class (concept)

Automobile w Wheel make : String 3..* power : Integer Association Constraint (relationship) vehicle 0..2 (well-formedness Composition rule) driver 0..* (relationship) Person (driver.age <= 16) implies (power <= 10)

102 © Copyright Malina Software Example: EMOF Metamodel (Root)

Metaclass = A MOF  Using MOF to define Class that models a Language Concept (E)MOF

0..1 Element

NamedElement Comment 0..* name : String body : String

Type TypedElement

103 © Copyright Malina Software Example: EMOF Metamodel (simplified)

type 0..* Type TypedElement 0..1

Class 0..* Property isAbstract : Boolean isReadOnly : Boolean default : String [0..1] isComposite : Boolean opposite isDerived : Boolean 0..1

0..* 0..* Operation Parameter

104 © Copyright Malina Software The Meaning of Class Models

type 0..* Type TypedElement 0..1

 A key element of abstract syntax definition  What does this model represent? . There is much confusion about the meaning of this type of diagram (model)  Questions: . What do the boxes and lines represent? . How many Types are represented in this diagram? . What does ―type‖ mean? . What does ―0..*‖ mean?

105 © Copyright Malina Software Example: Two Populations with Relationships

Adults Children

Karl

Cory Ida Bob Dee Jill Fred Guy

Alice Peggy Hayley Les

106 © Copyright Malina Software Some Facts We Can State

 Particular statements (propositions): . Bob has no children (in the set Children) . Karl is the father of Dee and Ida . Karl and Jill are the parents of Cory . Fred and Peggy are the parents of Guy . Peggy is the mother of Hayley . Alice is the mother of Les  General statements (predicates – through abstraction): . Children can have one or two Adult parents . Some Adults are parents of Children . Every Person has a name and a gender

107 © Copyright Malina Software Classes and Associations in MOF (and UML)

 Class: A specification of a collection of object instances characterized by possessing the same set of features and behaviours  Association: A specification of a collection of links whose ends conform respectively to the same type

108 © Copyright Malina Software Classes and Association Classifiers

Adults Children

Karl

Cory Ida Bob Dee Jill Fred

Guy

Alice Peggy Hayley Les

parents children Adult Child

name : String name : String 1..2 0..* gender : [M, F] gender : [M, F]

109 © Copyright Malina Software Interpreting Association Ends

parents children Adult Child

name : String name : String 1..2 0..* gender : [M, F] gender : [M, F] The ―children‖ (set) of Karl Children Adults

Karl Ida Dee Cory

Jill The ―parents‖ An OCL (set) of Cory constraint

Karl.children->includes(Cory)

110 © Copyright Malina Software Example Metamodel: UML (simplified fragment) sources 1..* Directed Element targets Relationship 1..* NamedElement

NamedElement generalizations name : String 0..* Generalization TypedElement

types 1..*

Classifier Type features Feature 0..*

Classifier attributes 0..* Attribute Class operations 0..* Operation Primitive Type

111 © Copyright Malina Software Under the Hood: How Models are Stored

Diagrams are just attributes[1] selective views of : ClassObj 1 : AttributeObj 2 the underlying model name[ClassA = “A”] name[attr =. a1] “a1”

targets[1] A types[1] a1 : Integer generalizations [1] : Generalization : PrimitiveType name = “Integer”

sources[1] types[1] B : Class get_a1() : Integer name = “B” NB: Models are operations[1] complex : Operation graphs name = “get_a1” Model User view repository view 112 © Copyright Malina Software Models and Diagrams  Model elements can be created by: . Indirectly: by creating a new element in a diagram . Directly: by inserting it directly into the model (e.g., through a program or a model browser/explorer) Diagrams (model views) : Class attributes[1] : Attribute

A name = “A” name = “a1”

a1 : Integer targets[1]

types[1] generalizations [1] : Generalization : PrimitiveType B name = “Integer” Programmatic get_a1() : Integer sources[1] types[1] (API) : Class

name = “B” access

operations[1] Diagrams are : Operation

usually separated name = “get_a1” from the model Model Repository

113 © Copyright Malina Software OBJECT CONSTRAINT LANGUAGE (OCL): WRITING CONSTRAINTS (WELL- FORMEDNESS RULES) AND QUERIES

114 © Copyright Malina Software Example: A Community

friend friend

Alice Bob Eunice Fred Jill Karl

friend

Cory Dee Guy Hayley Ida Les friend

Millie Nick Orville Peggy

friend 115 © Copyright Malina Software A Corresponding Class Diagram

+husband

0..1 0..*

+wife Person 0..* +name: String <> 0..1 +isMarried: Boolean +friend Gender +gender: Gender +age: Integer +M +F +isSenior(): Boolean

+parent +child Adult Child 0..* 0..*

116 © Copyright Malina Software Propositions, Predicates, and Constraints

 Proposition: A statement that is either True of False . Bob is an Adult . Les and Ida are friends  Predicates: Propositions that involve variables; e.g.: . There is at least one Adult with the name ―Bob‖ . All Adults are married . Every Child has at least one Adult parent  A predicate require a range for its variables  Constraints: predicates that, by design, must evaluate to True; e.g.: . Only Adults can have Children . An Adult who is married must have a spouse

117 © Copyright Malina Software First-Order (Predicate) Logic(s)

 Used to reason about predicates  Basic operators of FOL: . The usual Boolean operators • AND () • OR () • NOT () . Conditional: • If is True (hypothesis) then (conclusion) must be True •  . Existential quantifier (): • There exists at least one member of the domain such that predicate is True •  a  Dom | . Universal quantifier (): • For all members of the specified domain is True •  a  Dom |

118 © Copyright Malina Software FOL Examples and OCL Equivalents

 There is at least one Adult with the name ―Bob‖ .  a  Adult | (name(a) = ―Bob‖)  All Adults are married .  a  Adult | (married(a) = True)  Every Child has at least one Adult parent   c  Child | (size(parents(c))  1)  ...and their OCL equivalents . exists (a:Adult| a.name = “Bob”) . forAll (a:Adult | a.isMarried) . forAll (c:Child | parents->size() >= 1)

119 © Copyright Malina Software The Object Constraint Language (OCL)  An OMG standardized language for specifying constraints and queries for UML and MOF classifiers and objects . http://www.omg.org/spec/OCL/2.2/PDF . Declarative side-effect-free language  Primarily used in conjunction with MOF to specify the abstract syntax of modeling language constructs . Example: +parent +child Adult Child 0..* 0..*

context Child inv: self.parent->size() <= 2

120 © Copyright Malina Software OCL Basics – Contexts and Constraints

+husband

0..1 0..*

+wife Person 0..* +name: String 0..1 +isMarried: Boolean +friend +gender: Gender +age: Integer +isSenior(): Boolean

 Context: identifies the class (or object) to which the constraint (also called an invariant) applies context Person inv: ...  Class constraints are written from the perspective of a generic member of the context class . ...which means that they apply to all members of the class ((self.isMarried) and (self.gender = #M)) implies((self.wife->size() = 1) and (self.husband->size () = 0))

121 © Copyright Malina Software OCL Basics – Data Types Used in OCL

 Reuses basic UML/MOF primitive types . Boolean, Integer, String . Adds type Real . Support all common arithmetic and logic operators  Collection types . Set, OrderedSet, Bag, Sequence  Model types . Modeler-defined application-specific classes . E.g., Person, Adult, Child, Gender  OclType = the type of all types (metatype) . Useful operation on any type: allInstances()

Person.allInstances() -- returns the set of all -- instances of Person

122 © Copyright Malina Software OCL Basics – Standard Arithmetic Operators

 <  >  <=  >=  +  -  *  /  .mod()  ...

123 © Copyright Malina Software

OCL Basics – Common Logic Operators

 not  or  and  xor  =  <>  implies  if then [else endif]

124 © Copyright Malina Software OCL Basics – Accessing Properties

+husband

0..1 0..*

+wife Person 0..* +name: String 0..1 +isMarried: Boolean +friend +gender: Gender +age: Integer +isSenior(): Boolean

 Classifier (and object) attributes and operations are accessed by the dot (.) operator self.name -- returns name String self.isSenior() -- returns True or False self.friend -- returns a collection -- persons who are friends -- of “self”

126 © Copyright Malina Software OCL Basics – Association/Link Navigation

 Association ends are accessed like all other Properties of Classifiers  OCL can navigate from a Classifier context to any outgoing association end...regardless of navigability

0..* Person 0..* +name: String +isMarried: Boolean +friend +gender: Gender +age: Integer +isSenior(): Boolean self.friend self.person -- uses default naming rule for -- unnamed ends  Unless the multiplicity is exactly 1, the result of the navigation is a collection

127 © Copyright Malina Software OCL Basics – OCL Collections and Operations

Collection

OrderedSet Set Bag Sequence

 Collections represent groups of values (e.g., Classes)  Collections can be manipulated using special collection operations . size() -- the size of the collection (Integer) . count() -- the number of occurrences of (Integer) . includes() -- True if collection includes . includesAll() -- True if collection includes . isEmpty() -- True if collection is empty . notEmpty() -- True if collection is not empty . exists() -- True if is True for at least 1 element . forAll() -- True if is True for all elements . ...

128 © Copyright Malina Software OCL Basics – Applying Operations to Collections

 The application of an operation to a collection is indicated by the use of the right-arrow (->) operator . self.friend->size() -- number of friends of self . self.friend->isEmpty() -- checks if set of -- friends is empty

129 © Copyright Malina Software OCL Basics – Universal and Existential Quantifiers

 ―exists‖ and ―forAll‖ operations are used to specify predicates over collections . exists =  (first-order logic existential quantifier operator) • self.friend->exists (f:Person | f.name = „Bob‟) -- at least one friend must be named „Bob‟ . forAll =  (first-order logic universal quantifier operator) • Person.allInstances()->forAll(p:Person| p.name <> „‟) -- the name of a Person cannot be an empty string . Avoids confusing mathematical symbols (+ avoids need for special typesetting)

130 © Copyright Malina Software OCL Basics – Select and Collect Operations

 Special iteration operations for deriving useful new collections from existing ones  Select provides a subset of elements that satisfy a predicate . ->select ( : | ) . Person->select (p:Person | p.isMarried)  Collect returns a new collection of values obtained by applying an operation on all of the elements of a collection . ->collect ( : | ) . Person->collect (p:Person | p.name)

131 © Copyright Malina Software OCL Basics – Other Useful Collection Operations

 For Sets, Bags, Sequences . ->union () -- returns the union of -- and . ->intersection() -- returns the -- intersection of -- and . - () -- returns a collection of -- elements in -- that are not in  For OrderedSets and Sequences . ->at(i) -- access element at position i . ->append(