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<int> out1; SC_SLAVE(accumulate, in1); sc_in<bool> 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<int> 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<int> 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<int> out1; SC_SLAVE(accumulate, in1); sc_in<bool> 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<int> 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<int> 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