Cloudy Models

This should be a quick blog entry to document some of the conventions I have used in the  framework  to get a handle on Javascript module management for model addins. Element Naming Convention As discussed  here , all the element based creator functions for module addins are available at the global scope, so every class knows about every other class, hence polluting the global namespace.  Therefore the naming of classes needs to be carefully considered to avoid clashes. The scheme I have used is to build the namespace for each module into the name of the element.  For example, the module with namespace "ser.ea.element" is called "ser_ea_element".  That is, the dots (.) have been replaced by dashes (_). I'm not entirely happy with this workaround.  I've got a few ideas to have something different but they will probably require further customisation within EA, and a fair amount of experimentation.  For the moment, this naming workaround will suffice.

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.

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

This is the first in a series of blogs relating to the use of Java with  Enterprise Architect (EA)  from Sparx Systems. The purpose of the blogs is to provide a starting point for Java programmers in their use of the language with EA. The  official post  from Sparx Systems is to use Java as a scripting language within EA. While this is useful, I have a preference to create Java applications outside of EA. The diagram below describes how a Java application can be created which interfaces into the  Sparx Object Model . The  connection  between the Java application and EA is a COM object (SSJavaCOM.dll) provided by EA. This  page  from EA provides information on how to install the COM object within your windows environment. The Java application’s “view” of the Object Model is via a JAR file ( eaapi) which provides the  linkage  between the COM object and the Java software. I use  Netbeans  for Java Development and once you have installed a 32 bit JDK it is relatively e

I was going to do a single post on how JavaScript module management is done on Peso , however it ended up being a rather long post.  So instead I thought it would be more manageable to break it down into a number of smaller posts. This first post covers, in a sense, the background to how I came to make the decision to develop within the framework module management capabilities.  This introductory blog post is still rather large, so I have tried to clarify my thoughts under the following headings. Requirements JavaScript Quick Tour EA Capabilities and Constraints Some Conclusions Note, that what I'll be detailing here is my approach, based on the information and understanding available to me at this point in time.  Others may have different ways to solve these issues.  If in future I find better ways, then I will change what I've done in accordance with any new information.  If I am horribly wrong, then at least, at a minimum, this will serve as an example to others of