MDSE In Practice - Chapter 6 - Reading Notes

-

 Chapter 6 - Modeling Languages At A Glance

6.1 Anatomy of Modeling Languages
  • Ingredients: Abstract syntax, Concrete syntax, Semantics
  • GPL - General Pruposes Language.  DSL - Domain Specific Language.
  • Semantics can be defined as
    • Denotational
    • Operational
    • Transactional
6.2 Multi-View Modeling and Language Extensibility
  • Used to model orthogonal aspects of a system.
  • Typical: static/structural & dynamic.
  • Extensibility.  Sometimes GPL+specialization -> DSL
  • e.g. UML->SysML, SoaML
6.3 General-Purpose Vs Domain Specific Modeling Languages
  • DSLs - "are languages that are designed on purpose for a specific domain, context, or company, to support people who need to describe things in that domain."
  • GPL - "represent modeling notations that can be applied to any sector or domain for modeling purposes."
  • While UML might be faulty we know its faults.  Beware of creating your own UML.
6.4 General-Purpose Modeling: The case of UML
  • Well known & understood.
  • Full-fledged language suits.
  • Synthesis of a set of languages.
  • Complex, borne out of its history.
6.4.1 Design Practices
  • Uses a set of models.
  • Different levels of detail.
  • Extensible.
  • Supports pattern based design.
6.4.2 Structure Diagrams (or Static Diagrams)
  • Two levels
    • Conceptual Item
    • Architectural Representation
  • Conceptual ItemLevel
    • Class Diagram
    • Composite Structure Diagram
    • Object Diagram
  • Architectural Representation
    • Component Diagram
    • Package Diagram
    • Deployment Diagram
6.4.3 Behaviour Diagrams (or Dynamic Diagrams)
  • Use-Case Diagrams.
  • Activity Diagrams
  • State Machine Diagram
  • Interaction Diagrams
    • Sequence Diagram
    • Interaction Overview Diagram
    • Timing Diagram
6.4.4 UML Tools
- See Wikipedia

6.4.5 Criticisms and Evolution of UML
  • Criticism: Verbose, Cumbersome, Incoherent, Not easy to use in domain-specific scenarios.
  • Being addressed by OMG.
6.5 UML Extensibility: The Middle Way Between GPL and DSL

6.5.1 Stereotypes
  • Extend meta-classes
  • By
    • Base Metaclasses
    • Constraints
    • Tagged Values
    • Icon
6.5.2 Predicates
  • Restriction predicates. e.g. OCL

6.5.3 Tagged Values
  • tag-value pairs associated with a stereotype.
6.5.4 UML Profiling
  • A way of packaging extensions to define a DSL
  • Examples: SysML, SoaML, etc.
6.6 Overview of DSLs
  • Advantage is that it is suited specific domain& does not require users to learn a GPL.
6.6.1 Principles of DSLs
  • The language must provide good abstractions & be easy to use.
  • The language must not depend on a sole person's expertise.
  • The language must evolve.
  • The language must come with supporting tools & methods.
  • A good DSL must be open for extensions & closed for modifications.
  • Classification
    • Focus: Vertical (e.g. from an industry) or Horizontal (broad, e.g. SQL)
    • Style: Declarative or Imperative
    • Notation: Graphical or Textual
    • Internality: External (independent) or Internal (relies on extending a host language)
    • Execution: Model interpretation or Code generation
6.6.2 Some examples of DSLs
  • VHDL
  • I*
  • BPMN
  • IFML
6.7 Defining Modeling Constraints (OCL)
  • OCL - Object Constraint Language
  • A typed, declarative & side-effect-free specification language.
  • Constraints expressed as a set of invariants in the context of specified types.

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