MDSE In Practice - Chapter 5 - Reading Notes

-

 Chapter 5 - Integration of MDSE In Your Development Process

  • MDSE
    • Is process agnostic
    • Does not define which models must be used.
  • Integrating MDSE can be complex.  One code generator a MDSE integration does not make.
5.1 Introducing MDS In Your Software Development Process
  • Technical and non-technical aspects should be taken into account.
  • Major challenges
    • The imbalanced distribution of efforts & rewards among team members.
    • The lack of socio-technical congruence.
5.1.1 Pains & Gains Of Software Modeling
  • If the pains of modeling are separated from the gains of modeling, in particular with respect to individual staff.  Those that are subjectively burdened with the pains may doubt that their effort is worthwhile.
  • Therefore, when the work distribution among the members separates the pains and gains of modeling, we must adopt policies that recognize (and compensate for) those differences.
5.1.2 Socio-Technical Congruence Of The Development Process
  • The introduction of MDSE can bring in changes, both technical and organizational.  These changes may disrupt the social elements of the team.
  • Depending on the starting point and the desired destination, the introduction may require a sheperding, perhaps an evolving one to move the technical and social aspects and avoid conflict.
5.2 Traditional Development Processes and MDSE
  • Traditional processes are already model based.
  • MDSE brings the possibility of going from model-based to model-driven (e.g. to facilitate the automation of the transition between different phases of the development process).
5.3 Agile And MDSE
  • Agile criticism of MDSE; Models
    • don't run (i.e. they are not working software).
    • are just documentation
    • require extra work & alignment
  • Counters to the above
    • models can be executable
    • active part of implementation & verification
    • design less expensive than construction
  • Agile Modeling (AM) as a synthesis of modeling and agile practices.  Principles:
    • Model with purpose
    • Travel light
    • Multiple models
    • Rapid feedback
    • Favor executable specifications
    • Embrace change
    • Incremental change
    • Working software is your primary goal.
    • Enabling the next effort is your secondary goal
  • Agile practices could be applied to modeling
5.4 Domain-Driven Design & MDSE
  • MDSE can be considered a framework that provides techniques for DDD.
  • MDSE complements DDD by helping developers to benefit even more from the domain models.
5.5 Test-Driven Development and MDSE

5.5.1 Model -Driven Testing
  • Models are used to derive the tests.
5.5.2 Test-Driven Modeling
  • Before developing a model excerpt, write the model test.
  • Requires that models be executable.
5.6 Software Product Lines and MDSE
  • Product line = family of systems
  • Aspect of interest - variability modeling
    • 2 approaches
    • Annotative & Compositional
  • FOSD - Feature-Oriented Software Development

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