MDSE In Practice - Chapter 1 - Reading Notes

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

1. Introduction
  • It is natural for the human mind to form abstractions (generalisations, classifications, aggregation).
  • Informal definition of a model: "a model as a simplified or partial representation of reality, defined in order to accomplish a task or to reach an agreement on a topic."
  • This implies that a "model will never describe reality in its entirety."
  • [Modeling is natural to humans.  We implicitly use models to help us understand the world.  Even computer programs are models, in a sense.]
  • [As useful as models are, we must be cognizant of the inherent constraint that they do not give a 100% representation of reality.  This is particular true of those models which are defined as being references or blueprints in some form.]
1.1 Purpose and Use of Models
  • Ubiquity of models in diverse fields (Maths, Physics, Philosophy of Science, Engineering).
  • Roles for models
    • Reduction feature - representation of a selection (or sub-set) of the original's properties.
    • Mapping feature - Based on the original as a prototype, and then used for abstraction & generalization.
  • Purpose of models
    • Descriptive - describe reality.  [maybe think of as 'as is'.]
    • Prescriptive - used for construction.  [maybe think of as 'to be'.]
  • Models can be used to investigate, verify, document, discuss, product creation (automation).
  • A model always exists, even if it is just in somebody's head.  The decision almost always is as to whether one should create an explicit physical representation or not.
1.2 Modeling for Software Development
  • MDSE Practices - Increase efficiency and effectiveness in software development.  [Anecdotally, diagrams have always been used to clarify potential software engineering solutions].
  • Growing need for MDSE
    • Software artifacts are becoming more complex.
    • Software is more and more pervasive in people's lives.
    • There is a continuous shortage of software development skills.
    • Software development is not a self-standing activity.  Many people are involved & communicated with.
  • Industry moving to greater use of models.
  • Classification Model Use (See Martin Fowler definition).
    • Model as sketches
    • Models as blueprints
    • Models as programs
1.3 How to Read This Book
  • MDSE Curious
  • MDSE User
  • MDSE Developer
  • Student
  • Instructor

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