Skip to content

Feed aggregator

Topconf Linz interview. 

Sander Hoogendoorn - Thu, 01/19/2017 - 22:57
Here’s a ​short interview with me as a prelude to my upcoming keynote early March at #TopConf in Linz, Austria.  http://topconf.com/linz-2017/news/chatroom-with-sander-hoogendoorn/
Categories: Blogs

An ecosystem of tools around PlantUML to render textual UML diagrams anywhere you want (updated)

Software Modeling Blog - Mon, 01/16/2017 - 09:03

Check the growing ecosystem around PlantUML, a textual UML tool to easily create and embed graphical UML diagrams wherever you need them.

The post An ecosystem of tools around PlantUML to render textual UML diagrams anywhere you want (updated) appeared first on Modeling Languages.

Categories: Blogs

Continuous Model-Driven Engineering

Software Modeling Blog - Mon, 01/09/2017 - 06:07

Keep reading to see how we managed to combine modeling and continuous delivery and how this combination is beneficial for both continuous integration / deployment and model-driven tools

The post Continuous Model-Driven Engineering appeared first on Modeling Languages.

Categories: Blogs

Top 5 modeling posts of the year (2016 edition)

Software Modeling Blog - Fri, 12/30/2016 - 06:07

Over 300.000 visitors stopped by this site in 2016 . Let's see what their favourite content was (among all posts written during this same year). This is your chance to discover (or reread) them!

The post Top 5 modeling posts of the year (2016 edition) appeared first on Modeling Languages.

Categories: Blogs

Interview with Francis Bordeleau on Papyrus, “the” modeling platform in Eclipse

Software Modeling Blog - Mon, 12/19/2016 - 06:04

Learn more about the past, present and future of Papyrus and the industry of software /systems modeling in general.

The post Interview with Francis Bordeleau on Papyrus, “the” modeling platform in Eclipse appeared first on Modeling Languages.

Categories: Blogs

EA TFS Connector a new add-in for the Bellekens EA Toolpack

The Bellekens EA toolpack, the free set of add-ins for Enterprise Architect has expanded with a new add-in: the EA TFS Connector. This new add-in for Sparx Systems Enterprise Architect synchronizes workitems 2-ways between EA and TFS […]

The post EA TFS Connector a new add-in for the Bellekens EA Toolpack appeared first on Bellekens.

Categories: Blogs

Reverse engineering of database security policies

Software Modeling Blog - Wed, 12/14/2016 - 05:09

Automatic extraction of security policies that generates an RBAC security model from an existing database by analyzing its dictionary, views, triggers,...

The post Reverse engineering of database security policies appeared first on Modeling Languages.

Categories: Blogs

Re-implementing Apache Thrift with MDE (guess what happened!)

Software Modeling Blog - Fri, 12/09/2016 - 07:50

How well does it fare the "MDE-version" of a well-known open source software project wrt the original? Find out what benefits (and shortcomings) MDE brings in this scenario

The post Re-implementing Apache Thrift with MDE (guess what happened!) appeared first on Modeling Languages.

Categories: Blogs

Closing keynote at SwanseaCon 2016 in Wales

Sander Hoogendoorn - Tue, 12/06/2016 - 16:34
​Here’s my closing keynote at #SwanseaCon 2016 with Sander Hoogendoorn. Beyond breaking bad. The current state of agile in ten easy lessons.  https://t.co/dvZ6QQT347 
Categories: Blogs

Do. Or do not. There is no try. Well actually, there is.

Sander Hoogendoorn - Mon, 12/05/2016 - 22:10
One of the great things about being a programmer is that you never stop learning. Even after having programmed for almost 35 years, I still improve on the way I write code. About a year ago, the way I write code changed once again when I started to apply monads and especially the Try class. Do. Or do not. There […]
Categories: Blogs

Open PhD and Postdoc positions – Software Engineering – Barcelona

Software Modeling Blog - Mon, 12/05/2016 - 00:29

For those of you looking for a PhD or Postdoc position in Software Engineering, take a look at the latest offers we have published on our team website . We are looking for candidates in a variety of topics (model-driven engineering, software analytics, formal methods, open data,…). If you think you’re the right person for the job, […]

The post Open PhD and Postdoc positions – Software Engineering – Barcelona appeared first on Modeling Languages.

Categories: Blogs

Big Data and modeling: Are they mutually compatible?

Software Modeling Blog - Tue, 11/29/2016 - 14:40

Ten thngs to keep in mind when mixing modeling and big data. Modeling is as important as ever when dealing with big data but it must be adapted

The post Big Data and modeling: Are they mutually compatible? appeared first on Modeling Languages.

Categories: Blogs

Experimental feature: reverse-engineering a database schema into a Cloudfier application

abstratt: news from the front - Wed, 07/27/2016 - 20:12

We just released a new version of Cloudfier which sports a long requested feature (in experimental status): reverse engineering a relational database schema as a Cloudfier application. It relies on offline database schema snapshots produced by the SchemaCrawler tool.

Steps
  1. Create a new folder (call it, say, ‘import-test’)
  2. Select the folder you just created, right click it, and choose Import > File or Zip Archive, then pick a database snapshot file created using SchemaCrawler in your computer (feel free to download this example snapshot). When asked whether the file should be unzipped, CHOOSE “NO”.
  3. Select the folder you just created, right click it, and choose Open Related > Shell
  4. type cloudfier init-project .
  5. type cloudfier app-deploy . so the contents of the project are published
  6. type cloudfier import-schema-crawler . offline.db_.zip to import the SchemaCrawler snapshot as TextUML model (provide the proper file name if your snapshot file has a different name)
  7. if you used the sample snapshot, delete the forlint.tuml file before you take the next step.
  8. type cloudfier full-deploy . to deploy the application.

all-steps-import-schema-crawler

Producing an offline database schema with SchemaCrawler
  1. Download and extract SchemaCrawler into your computer.
  2. Open a terminal or command prompt and cd into the _schemacrawer directory inside the location where you extracted SchemaCrawler.
  3. Run SchemaCrawler tool “serialize” command against your database, for instance (for a SQL Server database):
    ./schemacrawler.sh -command=serialize -server=sqlserver -infolevel=standard -password=DB_PASSWORD -user=DB_USER -database=DB_NAME -host=DB_HOST -o=my-offline-schema.zip  
    

More details on running SchemaCrawler here.

Controlling the schema import operation

There are a bunch of options that you can add to your mdd.properties file to customize the importing operation. Some of which are demonstrated in this test class.

Categories: Companies

Generating UML Reports From XMI Files

SDMetrics - UML design quality measurement - Mon, 02/24/2014 - 10:40

Occasionally I receive requests from people looking for a simple way to generate a report from an XMI file. For example, they may need to collect a list of all class attributes that satisfy a certain condition, and write them to some HTML or XML file. Depending on the task at hand, XSLT could work in such situations, especially if it’s a one-off problem to solve, the XMI files are not very large, and come from a single source. Another option is to use the report generation facilities that some UML modeling tools offer.

But what if you’re dealing with huge XMI files, possibly from different sources? Or the report depends on information contained in proprietary XMI extensions that your UML modeling tool does not import? Or you need to evaluate complex conditions or constraints on the UML model elements for the report? That’s what SDMetrics was designed for. However, SDMetrics does not have a report generation facility. You could use SDMetrics’ API and write a Java program to generate the report. That requires Java skills, and the solution must be recompiled and redeployed every time the report needs to be changed. A more flexible solution is to use a Java-based template engine such as Velocity for report generation.

In this post, we will develop a Velocity template for SDMetrics to generate an HTML report for a UML model. The report will list

  • every UML model element in the model, along with the values of its attributes,
  • the metric values for each model element,
  • the contents of the helper sets for each model element (for example, the set of ancestor/descendant elements),
  • the list of rule violations of the model element, if any.

Here’s a preview of what the report will look like. In this form, the report is not yet particularly useful or appealing. However, the main purpose of this post is to demonstrate how to include all the model information in the report using the SDMetrics API. The template we are about to write can thus serve as a starting point for developing customized reports more quickly.

To execute the report generator, we need

We also need a Java compiler or IDE to compile the glue code that hooks up Velocity with the SDMetrics API, and a Java 1.7 runtime for execution. I have prepared a ZIP archive for download that contains the libraries, glue code, and the finished template, ready to compile and run.

Define a report facade

Java template engines provide a scripting language to access Java objects, and invoke methods on these objects to traverse the data structures for the report. In the SDMetrics API, the interesting Java classes for report generation are:

I found it useful to implement a single Java class that serves as facade to the container classes (MetaModel, Model, MetricStore, MetricsEngine, RuleEngine). That way, the report template author does not have to deal with these five objects individually, but can rely on a single class that provides all the data. Let’s call this class ReportFacade. Here’s an excerpt from the class:

import com.sdmetrics.metrics.*;
import com.sdmetrics.model.*;
import java.util.*;

public class ReportFacade {

  private Model model;
  private MetaModel mm;
  private MetricsEngine me;
  private RuleEngine re;

  // Access to the metamodel

  public List<MetaModelElement> getTypes() {
    List<MetaModelElement> typeList = new ArrayList<>();
    for(MetaModelElement mme : mm)
      typeList.add(mme);
    return typeList;
  }
  
  // Access to the model

  public List<ModelElement> getElements(MetaModelElement type) {
    return model.getAcceptedElements(type);
  }
  
  public List<ModelElement> getRootElements() {
    ArrayList<ModelElement> roots=new ArrayList<>();
    for(ModelElement me : model)
      if(me.getOwner()==null)
        roots.add(me);
    return roots;
  }
  
  public boolean isModelElement(Object o) {
    return o instanceof ModelElement;
  }
  
  // Access to metrics and sets
  
  public Collection<Metric> getMetrics(MetaModelElement type) {
    return me.getMetricStore().getMetrics(type);
  }
  
  public Object getMetricValue(ModelElement e, Metric m) {
    return me.getMetricValue(e, m);
  }
  
  ...
  
}

The methods of the facade class mostly just delegate to the respective getter methods of the container classes. Where necessary, objects are filtered or placed into collections so that the report template can access them.

Creating the report structure

Let’s start with the template. The following code snippet generates the overall structure of the report:

<?xml version="1.0" encoding="$encoding"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 

[... skip macro definitions for now ...]

<html>
<head>
<title>$title</title>
<style type="text/css">
table { border-collapse:collapse; }
table,th,td { border: 1px solid black; text-align:left; }
</style></head>
<body>
<h1>Overview of elements</h1>
#writeElementHierarchy($report.getRootElements())
#foreach( $type in $report.getTypes() )
  #set( $elements = $report.getElements($type))
  #if($elements.size() > 0)
    <h1>List of elements of type '$type.getName()' ($elements.size())</h1>
    #foreach($element in $elements)
      <a name="$element.getXMIID()">
      <h2>$type.getName() #escp($element.getFullName())</h2></a>
      #writeAttributes($element)
      #writeMetrics($element)
      #writeSets($element)
      #writeRuleViolations($element)
    #end
  #end
#end
</body>
</html>

The template writes the boiler plate markup for a valid XHTML 1.0 file, with <html> and <head> tags and a little CSS styling. The variable $encoding contains an externally provided string with the character encoding for the output file (for example “UTF-8″). Likewise, variable $title provides the title for the report.

Next is the body of the report. The macro #writeElementHierarchy() recursively writes the nested list of model elements that serves as a “table of contents” of the report. We’ll look at its definition in a moment. Variable $report is an externally provided reference to our ReportFacade instance that holds the UML model. Method getRootElements() obtains a list of all model elements that have no owner. All other elements in the model are directly or indirectly owned by the model elements on this list.

After that, the templates goes into a foreach-loop over all element types in the meta model ($report.getTypes()). The body of the loop creates, for each element type, a list of all model elements for that type ($report.getElements()). For each model element, we write an <h2> tag with the type and name of the model element, and a named anchor to cross-reference model elements within the report using hyperlinks. The XMI IDs of the model elements serve as anchor names. The macros #writeAttributes(), #writeMetrics(), #writeSets(), and #writeRuleViolations then output the detailed information for each model element. So let’s have a look at those macros.

Write the element hierarchy

This is macro #writeElementHierarchy(), along with two little helper macros it requires:

#macro( escp $text )$reportUtils.xmlEncode($text)#end

#macro( writeElementRef $elem )
  #if( $elem )
    <a href="#$elem.getXMIID()">$elem</a>
  #end
#end

#macro( writeElementHierarchy $elements )
  #if($elements && ($elements.size()>0))
    <ul>
    #foreach($element in $elements)
      <li>#escp($element.getType().getName()) #escp($element.getName()) -
        #writeElementRef($element)
        #writeElementHierarchy($element.getOwnedElements())
      </li> 
    #end
    </ul>
  #end
#end

The macro receives a list of model elements as input parameter. The list may be empty or null. The macro produces an unordered HTML list (<ul>) with the type and name for each model element, and a hyperlink to the detailed description of the model element (call to macro #writeElementRef()). If an element owns sub-elements, those elements are written out recursively in a nested, unordered list.

Macro #escp() replaces XML special characters (<, >, & etc) with their predefined entities. For simplicity, we use a little utility class of our own (ReportUtils, not shown here) for that. Velocity comes with an optional tools package (Velocity tools) that also provides this functionality and should be used instead in a production environment.

Write the attribute values

To generate a table with the values of all attributes of a model element, we define macro #writeAttributes() as shown below. It takes the model element to write as input parameter. The macro determines the type of the model element, obtains the list of the attributes for that type, and writes out an HTML table with the attribute names in the first column, and the attribute values in the second column.

#macro( writeElementRefs $elems )
  #if($elems) 
    #foreach($elem in $elems)
      #writeElementRef($elem)#if( $foreach.hasNext ),#end
    #end
   #end
#end

#macro( writeAttributes $elem )
  #set ($elemType = $elem.getType())
  #set ($attributes = $elemType.getAttributeNames())
  <table><tr><th>Attribute</th><th>Value</th></tr>
  #foreach($attribute in $attributes)
    <tr><td title="#escp($type.getAttributeDescription($attribute))">#escp($attribute)</td><td>
    #if($elemType.isSetAttribute($attribute))
      #if($elemType.isRefAttribute($attribute))
        #writeElementRefs($elem.getSetAttribute($attribute))
      #else
        #escp($elem.getSetAttribute($attribute))
      #end
    #else
      #if($elemType.isRefAttribute($attribute))
        #writeElementRef($elem.getRefAttribute($attribute))
      #else
        #escp($elem.getPlainAttribute($attribute))
      #end
    #end
    </td></tr>
  #end
  </table>
#end

Writing the attribute values requires a bit of attention. The SDMetrics meta model distinguishes between data and reference attributes. Data attributes carry string values, reference attributes contain references to other model elements. An attribute can be single-valued or multi-valued.
Multi-valued attributes contain a set of values, single-valued attributes just one. The nested #if-statements in macro #writeAttributes() determine which combination of data/reference and single/multi-valued attribute applies, and obtain the values accordingly. Helper macro #writeElementRefs() is used to generate a comma-separated list of hyperlinks for multi-valued reference attributes.

Write the metric values

Macro #writeMetrics() below creates the table with the metric values for a model element. The macro determines the list of metrics for the element type, and writes out an HTML table with the metric names in the first column, and the metric values in the second column. Metric values can be strings, numbers, or references to other model elements. Helper macro #writeValue() checks if a metric value is a model element reference or not, and either writes a hyperlink to the model element, or just the plain metric value.

#macro( writeValue $value )
  #if($value)
    #if( $report.isModelElement($value) )
      #writeElementRef($value)
    #else 
      #escp($value) 
    #end
  #end
#end

#macro( writeMetrics $elem )
  #set ($elemType = $elem.getType())
  #set ($metrics = $report.getMetrics($elemType))
  #if($metrics.size() > 0)
    <h3>Metrics</h3>
    <table><tr><th>Metric</th><th>Value</th></tr>
    #foreach($metric in $metrics)
      <tr><td title="#escp($metric.getBriefDescription())">#escp($metric.getName())</td>
      <td>#writeValue($report.getMetricValue($elem,$metric))</td></tr>
    #end
    </table>
  #end
#end

Macros #writeSets() and #writeRuleViolations to write the helper sets and rule violations for a model element work in the same fashion and are not shown here.

Give it a spin

To play with the template, the zip archive (1.3 MB) contains a self-contained Java project with everything you need. It is an Eclipse project, but you can also import it in Netbeans or IntelliJ IDEA:

  • The Java source files are in the “src” folder.
  • Make sure the two jar files in the “lib” folder are included in the project’s class path.
  • File “sdmetricstemplate.vm” in the project’s root directory contains the Velocity template.
  • Class com.sdmetrics.velocity.ReportLauncher has a main method that applies the template to the XMI file “sample.xmi” in the project’s root directory.

The support for report generation can be taken further. For example, it is easily possible to define metric or condition expressions directly in the template, have them evaluated on-the-fly by the metrics engine, and include the result in the report. I’ll demonstrate this in a future post.

Categories: Companies

Counting OCL Expressions in UML Classes

SDMetrics - UML design quality measurement - Thu, 01/09/2014 - 14:03

In this post we’ll look at another real-life case study of how to adapt SDMetrics in order to solve a particular measurement problem. An SDMetrics user needed to count the OCL expressions in classes. SDMetrics does not produce this count out of the box, but needs a little tweaking.

In the UML2, an OCL expression is represented by a constraint whose specification is an opaque expression with OCL as its language. The following excerpt from an XMI file shows an OCL expression for a class:

<packagedElement xmi:type="uml:Class" xmi:id="id1" name="Cls1">
  <ownedRule xmi:type="uml:Constraint" xmi:id="id2" name="constr1">
    <specification xmi:type="uml:OpaqueExpression" xmi:id="id3">
      <language>OCL</language>
      <body>self.association().oclIsKindOf(Class)</body>
    </specification>
  </ownedRule>

OCL expressions may not only be defined for the class itself, but also for operations, properties, or other owned elements of the class. All these constraints should be included in the OCL count for the class. Therefore, the general strategy to define this metric in SDMetrics is to count all opaque expressions directly or indirectly owned by the class, where the language is OCL. However, we first need to extend SDMetrics’ XMI import to obtain all the required information from the model.

SDMetrics as shipped does not read the sub-elements of constraints, so the opaque expression elements owned by constraints are ignored by default. To change this, we must set the recurse attribute in the XMI transformation for constraints (cf. bottom of this section in the user manual):

<xmitransformation modelelement="constraint" 
  xmipattern="uml:Constraint" recurse="true"/>

Next, SDMetrics’ simplified UML metamodel does not define the attribute ”language” for opaque expressions. So we simply add it to the metamodel definition file:

<modelelement name="opaqueexpression">
  <attribute name="language" type="data" /> 
</modelelement>

We also have to create an XMI trigger for the new attribute in the XMI transformation file:

<xmitransformation modelelement="opaqueexpression" 
  xmipattern="uml:OpaqueExpression">
    <trigger name="language" 
      type="ctext" src="language" />
</xmitransformation>

This instructs SDMetrics to use the text of the child element “language” in the XMI file as the value for the “language” attribute of opaque expressions.

With these extensions to SDMetrics’ XMI import, we can then define the metric to count all opaque expressions in the class where the language is OCL:

<metric name="OCLExpressions" domain="class" category="Size">
  <description>The number of OCL expressions in the class.</description>
  <subelements target="opaqueexpression" condition="language='OCL'" />
</metric>

And that’s it! Yet another measurement problem for SDMetrics that could be solved with a few lines of XML code. The customization features work as advertised.

Categories: Companies

Re: [UML Forum] Modeling data changes within a structure

UML Forum Google Group - Sat, 05/25/2013 - 21:22
Responding to Sanders...

I'm not sure exactly what your are trying to model, probably because I
am making some assumptions. So let's see if I understand the problem...

You have a blob of legacy code with a UI that writes to the DB. The
inputs to the legacy code are in the form of events, either literally

Categories: Communities

Re: [UML Forum] Modeling data changes within a structure

UML Forum Google Group - Sat, 05/25/2013 - 21:22
State Machine

transitions/triggers for UI events

effects on transitions for DB changes

Phil Chudley

Sent from Samsung Mobile

-------- Original message --------
To: umlforum@googlegroups.com

Dear peers & colleagues,

I would like to ask for your views on, or how you would go about, modeling data changes within a data structure as a consequence of a user event. Modeling as in UML modeling of course, but simply anything more visually appealing or clue-providing is allowed as well.:-)

Categories: Communities

Modeling data changes within a structure

UML Forum Google Group - Sat, 05/25/2013 - 21:22
Dear peers & colleagues,
I would like to ask for your views on, or how you would go about, modeling
data changes within a data structure as a consequence of a user event.
Modeling as in UML modeling of course, but simply anything more visually
appealing or clue-providing is allowed as well.:-)
The context: assume a data structure which in itself is not overly complex,
Categories: Communities

Re: [UML Forum] What does the arrow end of a dependency relationship indicate?

UML Forum Google Group - Sat, 05/25/2013 - 21:22
Martin,

I understand your confusion.
The answer to the question is that the arrow end of a dependency relationship represents the supplier and the tail represents the client.
The provided answers are poorly worded. A, B, C are clearly wrong.
I think D is trying to say [the arrow end indicates ] the client element, which is affected by a change in the supplier element

Categories: Communities

Re: [UML Forum] What does the arrow end of a dependency relationship indicate?

UML Forum Google Group - Sat, 05/25/2013 - 21:22
Responding to Martin...

Because this borders on being a trick question. Dependencies are about
what one element /knows /about the other element. A basic tenet of
dependency management is that dependencies should be one-way with the
client knowing something about the supplier but the supplier knowing

Categories: Communities