MDSE In Practice - Chapter 2 - Reading Notes

-
Model-Driven Software Engineering In Practice - Chapter 2 - Reading notes

2. Introduction
  • "MDSE is conceived as a tool for ... transforming models into first-class citizens in software engineering."
2.1 MDSE Basics
  • Aspects
    • Concepts
      • Models and Transformation (Models + Transformations => Software)
      • [Transformations do not necessarily need to be programmatic, they could be manual.]
    • Notations - Models are expressed in a particular notation, depending on the domain.
    • Process & Rules - These inform what models should be used, in what order and how they should be used.
    • Tools - We need tools to make all these feasible.
  • "Everything is a model"
  • Drawing != Modeling.  Advantages of Modeling: Syntactical validation, model checking, model simulation, model transformation, model execution, model debugging.  [When is model simulation different from model execution?]
2.2 Lost In Acronyms: The MD* Jungle
  • See here for Jordi Cabot's blog for equivalent material.
  • Basically MDA < MDD < MDE < MBE
  • MBE is a softer version of MDE, where software models play an important role although they may not necessarily be the key artifacts of the development.
  • MDSE is a version of MDE focused on software engineering & the subject of this book.
2.3 Overview of the MDSE Methodology
2.3.1 Overall Vision

Issues Conceptualization
Implementation Levels Application Application Domain Meta-Level
Modeling Model Modeling Languages Meta-Modeling Languages
Automation Transformation/Code Generation Transformation Definition Transformation Language
Realization Artifacts (e.g. code) Platform

2.3.2 Domains, Platforms, And Technical Spaces

  • MDE implies: Context -> Model of Context -> Some other Model
  • Problem Space (or problem domain [or representation]) addressed by analysis phase.
  • Solution Space addressed by requirements collection phase and design phase.The Solution Space is the set of choices made at design, implementation & execution levels.
  • Domain Model - Conceptual model of the problem domain - "The purpose of domain models is to define a common understanding of a field of interest, through the definition of its vocabulary and key concepts."
  • Technical Spaces represent a working context bound to specific implementation technologies.
    • Some technical spaces may span both problem & solution spaces (e.g. MDE), while others (e.g. Java or XML) may only be relevant with the solution space.
    • "extractors" and "injectors" may be used to transfer knowledge from one technical space to another.
2.3.3 Modeling Languages
  • Domain-Specific Languages (DSLs)
    • Specifically designed for a domain.
    • DSML - Domain-Specific Modeling Language
    • E.g. HTML, Logo, VHDL, Mathematica/MatLab, SQL
  • General-Purpose Modeling Languages (GPLs)
    • Can be applied to any sector or domain.
    • e.g. UML, Petri-nets, state machines
  • Note
    • Can further categorise languages and resulting models based on the level of abstraction.
    • Transformations can be defined for mapping between levels.
    • Models may be static or dynamic
  • Multi-viewpoint Modeling
    • Crucial principle of MDSE
    • Multiple models may define the same solution.
    • "Models can be interconnected through cross-referencing the respective artifacts."
    • Convenient to use Modeling Language Suites (or Family of Languages).  E.g. UML
2.3.4 Metamodeling
  • [Modeling the models]
  • A Metamodel is an abstraction of a model or family of models.
  • In practice meta-models can be defined based on themselves, and usually no further abstraction is required.
  • Examples
    • M0: (Casablanca Video) -> M1: Video Class -> M2: Definition of Class and Attribute -> M3: Common definition for Class and Attribute elements.
    • ModelWare: aBank.uml -> UML -> MOF
    • GrammarWare: aBank.java -> Java.g -> EBNF.g
2.3.5 Transformation
  • [Modeling transformations]
  • Transformation are defined at the metamodel level and then applied at the model level.
  • Source Model -> Transformation -> Target Model
  • Transformations
    • Set of templates & rules
    • Could operate as a 
      • manual operation, from scratch by a developer
      • be defined as a refined specification of an existing one
      • produced automatically out of a higher level mapping between models.
  • "Transformations themselves can be seen as models"
2.4 Tool Support
  • Lots of choice in every dimension.
2.4.1 Drawing Tools Vs Modeling Tools
  • Modeling Tools != Drawing Tools
  • Not all models need to be graphical models, some are textual.
  • Advantages of using a modeling tool
    • Apis (programming, file formats) are semantic-aware to ease import/export into other tools.
    • Guaranteed minimum level of semantic meaning and model quality.  Models must conform to the meta-model.
    • Typically provides features for transformation.
2.4.2 Model-Based Vs Programming-Based
  • Book advocates Model Based
2.4.3 Eclipse And EMF

  • Book advocates Eclipse/EMF
2.5 Adoption and Criticism of MDSE
  • Modeling frequently advocated but adoption does not match level of advocacy.  This may be because of inflated expectations raised in the past.
  • Commentators have positive views going forward, because
    • New technologies & methods.
    • Widening of the scope of the field.
    • More pragmatic modeling approaches are being advocated.
    • Maturation of de facto standard tools (e.g. EMF)
  • With respect to the hype cycle, MDSE is past the "Trough of Disillusionment" and currently on the "Slope of Enlightenment".
  • Main barriers to adoption are assessed as being human.  In particular, as adoption of new tools or techniques usually incurs lower productivity, at first, before productivity gains kick in at a later stage.
  • MDSE not a panacea.  Beware of:
    • Statements of pure principle.
    • Placing modeling as a trade-off with respect to programming.
    • diagrams being confused with models.
    • inadequate level of detail (corresponding to reality) with regards to the purpose of the model.
    • Perception of trade-off with regards to the executing system.
    • [That if you have a hammer, everything may look like a nail.]

Comments

Post a Comment

Popular posts from this blog

Creating Items in Sparx EA via Java

-
Introduction This short post provides guidance on how to create "things" in a Sparx EA model via the Java API. Theory Creating "things" in EA via Java is driven by the Add New method and the Collection class. The first example in the code is adding a "view" to an existing root node. The code below will retrieve the root GUID if the "i" variable is set to 0; rootPackageID = rep . GetModels (). GetAt ( i ). GetPackageGUID (); After obtaining the root GUID it is possible to create a view under the root node. Note the process of retrieving the packages under the root and placing them in a collection. The Add New process is driven from the Collection. Importantly, for a view, the code needs to set a flag which indicates a particular icon. This process is only required for views. org . sparx . Package root = rep . GetPackageByGuid ( rootPackageID ); // get the root Collection < org . sparx . Package > subPackages = r
Read more

Module Management - Part 1 - getModule() Pattern

-
As discussed in  Module Management - Analysis , EA does not provide support for the ubiquitous Module Pattern .  This becomes an issue with an increase in complexity of model addins.  In order to a) Minimise the management of dependencies, and b) Cater for the use of 3rd party modules, The  framework  provides an analogous pattern, which I'm calling the getModule() pattern, because I lack imagination. The premise is straight forward.  Rather than having an anonymous self executing function returning a module object, we instead have module class elements which have a method called "getModule()"  and this returns a module object when the method is called. The getModule() method would be declared (via the EA interface) on a class element, and then we would place all of the module's code in the body of the getModule() method/operation.  The method would return a module object to the caller. The sample contents of a typical getModule() operation might look like this.
Read more

Traversing a EA Model via Java

-
Traversing an Enterprise Architect model from Sparx Systems is relatively simple. This blog introduces the concept of model traversal via the Java API. For information on Java Set-Up see this blog entry . The first step is to obtain the repository object as it provides the anchor from which all other operations are derived. In the example below, a repository is held on the file system. The variable "repoLocation" holds the file system location of the "eap" file.   rep = new Repository();  // get a repository   rep.OpenFile(repoLocation);  //open the repository file At the top of a model is a root node and it is typically where you want to start when traversing a model. From the root node you can then obtain a collection of packages. At this point, it is easy to traverse the collection pulling in the packages via a loop and in this example printing out their names. To see the complete example, go to GitHub .   org.sparx.Package myMode
Read more