Introduction (See attachment for full article)

For the past several years I’ve enjoyed a mostly informal association with the University of Southern California Center for Systems and Software Engineering (USC CSSE).  I was on-staff at USC a few years ago teaching SysML and Model Based Systems Engineering, but for the last few years I’ve been mentoring Computer Science grad students in two Masters courses: CS577 Software Engineering and CS590 Directed Research.   The Directed Research (DR) course is basically a mechanism for students who are about to graduate from the Masters program but are one or two units short of the required number to pick them up by participating in a project with a mentor from industry (that would be me).   Students are expected to work 5 hours per week per unit.  

Teaching at USC is fun (I graduated from SC back in ancient times), gives me an opportunity to work with a lot of bright young software engineers, to stay current on new technology (in particular cloud-connected mobile app development) and also gives me an excuse to work with Prof. Boehm (author of Balancing Agility and Discipline among numerous other titles), who has happily taken an interest in some of my ideas related to improving productivity by innovating better software processes and allowing me to test my ideas out with USC grad students.  

This process work has included the development of the Resilient Agile process, an attempt to develop a better agile methodology which started out as an experiment called Massively Parallel Use Case Modeling that we did with the CS577 class a few years ago where we developed a complete location-based advertising system by handing one use case to each of 47 grad students and having each student develop their use case independently.  

This semester I’m working with a group of 15 Masters students, mostly taking a single unit of  DR.  One student is taking two units, so my team has an effective time budget of 80 student hours per week.  Although the semester at USC is 16 weeks long, by the time the student teams get formed, and with midterms and finals, we’ve got about 12 usable weeks of student time.  So it works out to a time budget of roughly 1000 student hours (that’s about half-a-person-year at 40 hours a week) over a 3 month schedule. 

Because I like challenges, we’re attempting a “crowdsouced bad driver reporting system” this semester, and because we need to be really productive, we’re using Enterprise Architect to coordinate all of the student homework.  This is the first article in a series that will describe our progress.

Are we crazy to think that we can get this system built in 3 months with a total of half-a-person-year of developer time?  Stay tuned for our next article to see how we’re doing.

Read Part 2 of this Case Study

Software and Systems Engineering, as any other interdisciplinary activity, requires the ability and means to build systems which are so large and complex that they have to be built by teams or even by teams of teams of engineers. In combination with a model-based approach, these teams need the possibility for modeling in a concurrent way. With other words, multiple users must be able to work on the same model in parallel or even on multiple versions of the same system. In code-centric software engineering, developers profit for years from the features provided by Version Control Systems (VCS), whereby one of the most important features is the possibility of comparing and merging changes of the same file. The key technique hereby is the so called three-way difference analysis which is also considering the common ancestor version of the artefact under comparison. Traditional approaches uses text- and line-based comparison tools, which are not suitable for graphical-based models.

In general, two different versioning strategies exist to cope with the concurrent evolution of one artifact. These are described in the following:

When pessimistic versioning is applied like it is implemented in EA, an artifact is locked while it is changed by one developer. Since other developers cannot perform any changes while the artifact is locked, conflicts are completely avoided with this strategy. However, the drawbacks are possible idle times for developers waiting for the release of a locked artifact.

To avoid such idle times, optimistic versioning allows the developers to change the same artifact in parallel and independently of each other. This process is depicted in the following figure:

The following videos give you insights into the latest developments in model versioning and act as tutorials in how you can set Enterprise Architect models under optimistic version control:

Tutorial 1 – LemonTree Introduction to Model Versioning

Tutorial 2 – LemonTree Model Comparison Tutorial

Tutorial 3 – LemonTree Concurrent Modeling Tutorial

For more information please visit: lemontree.lieberlieber.com

LieberLieber is proud to present a brand new Enterprise Architect tool named LemonTree (c). The most important function of this ground-breaking product is the diffing and merging of model versions.

Now, you do not have to lock your packages. Just check-in your eap files in your version control system!

Standard approaches use line- and text-based applications that do not suffice for graphic models. Only the finely-grained 3-way diffing algorithm that considers the model’s graph structure enables an exact comparison between two models.

 LemonTree highlights:

• Diff & Merge: Diffing and merging of Enterprise Architect models
• Model Versioning: Parallel editing of models with optimistic model versioning
• Integration: Seamless integration with Subversion (Tortoise) included
• Automation Interface: Automate LemonTree and integrate it in your versioning tool such as Git, PTC, or SVN
• Model Branches: Branches of models (longer-term, parallel development of versions and variants)
• Merge Preview: Diagram merge and merge preview
• Review: Changes are visualized clearly and understandably for review (including preview)

Stefan Mueller, HIMA Paul Hildebrandt, Safety-Related Automation Solutions: “In general, standards such as IEC 61508 demand the application of configuration management. This applies to all artifacts, including UML models. LemonTree from LieberLieber is our key to revealing the changes that have been made to a revision.”

Test LemonTree now and give us your feedback!

For more information: http://lemontree.lieberlieber.com/

In a candid interview with Arun Kant from CIOReview, Sparx Systems' CEO Geoffrey Sparks highlights how Enterprise Architecture has become an imperative for survival in the ever-changing and globalized corporate landscape.

CIOReview has also included Sparx Systems in their '20 Most Promising Enterprise Architecture Technology Providers 2016' list, resulting from a robust selection process actioned by a highly qualified panel of domain experts. The in-depth interview with Geoffrey Sparks is the featured article in this month's edition of CIOReview, where Geoffrey discusses the Sparx Systems tradition of continual development of the Enterprise Architect platform, while maintaining the highly competitive price-point that enables affordable outfitting for all project stakeholders.

Geoffrey Sparx, Founder and CEO, Sparx Systems

To read the full featured article, simply download the PDF attachment at the top of this article.

Automated FMU Generation from UML Models

(www.sysml4industry.org)

Introduction

The simulation of cyber-physical systems plays an increasingly important role in the development process of such systems. It enables the engineers to get a better understanding of the system in the early phases of the development. These complex systems are composed of different subsystems, each subsystem model is designed with its own specialized tool sets. Because of this heterogeneity the coordination and integration of these subsystem models becomes a challenge.

The Functional Mockup Interface (FMI) specification was developed by an industry consortium as a tool independent interface standard for integration and simulation of dynamic systems models. The models that conform to this standard are called Functional Mockup Units (FMU).

In this work we provide a method for automated FMU generation from UML models, making it possible to use model driven engineering techniques in the design and simulation of complex cyber-physical systems.

Functional Mockup Interface

The Functional Mockup Interface (FMI) specification is a standardized interface to be used in computer simulations for the creation of complex cyber-physical systems. The idea behind it being that if a real product is composed of many interconnected parts, it should be possible to create a virtual product which is itself assembled by combining a set of models. For example a car can be seen as a combination of many different subsystems, like engine, gearbox or thermal system. These subsystems can be modeled as Functional Mockup Units (FMU) which conform to the FMI standard.

The Functional Mockup Unit (FMU) represents a (runnable) model of a (sub)system and can be seen as the implementation of an Functional Mockup Interface (FMI). It is distributed as one ZIP file archive, with a ".fmu" file extension, containing:

• FMI model description file in XML format. It contains static information about the FMU instance. Most importantly the FMU variables and their attributes such as name, unit, default initial value etc. are stored in this file. A simulation tool importing the FMU will parse the model description file and initialize its environment accordingly.
• FMI application programming interface provided as a set of standardized C functions. C is used because of its portability and because it can be utilized in all embedded control systems. The C API can be provided either in source code and/or in binary form for one or several target machines, for example Windows dynamic link libraries (".dll") or Linux shared libraries (".so").
• Additional FMU data (tables, maps) in FMU specific file formats

The inclusion of the FMI model description file and the FMI API is mandatory according to the FMI standard.

Tools

Enterprise Architect is a visual modeling and design tool supporting various industry standards including UML. It is extensible via plugins written in C# or Visual Basic. The UML models from which we generate our FMU are defined with Enterprise Architect.

Embedded Engineer is a plugin for Enterprise Architect that features automated C/C++ code generation from UML models.

We further used the FMU SDK from QTronic for creating the FMI API. It also comes with a simple solver which we used to test our solution.

Running Example

Our basic example to test our solution is called Inc. It is a simple FMU with an internal counter which is initialized at the beginning and it increments this counter by a specified step value, each time it gets triggered, until a final to value is reached or exceeded.

State Machine

The state machine contains just an initial pseudo state which initializes the state machine and a state called Step. The Step state has two transitions, one transition to itself, in case the counter is still lower then the to value, if this is the case, the inc() operation will be called and we are again in the Step state. If the value is equal or greater to the to value, it reaches the final state and no further process will be done.

Class diagram

The class diagram consists of two parts. The left part with the Inc class is project specific. It holds three attributes: counter, step and to. All attributes are of type int. The initial value for the counter is 0, for the step it's 5 and for the to value it's 50. The FSM classes on the right are the mandatory classes for the Embedded Engineer to be able to generate the state machine code.
Some specific implementation code also exists in various places. In the state machine you can see, that we have some guards on the transitions. These guards are actually code that will be used to generate the code for the state machine:

me->counter < me->to

and

me->counter >= me->to

The property me represents a pointer to an instance of the Inc class.

And finally the implementation of the inc() operation is also provided:

me->counter = me->counter + me->step;

 

Manual Code Generation

First we manually created our reference Inc FMU, the following steps where taken:

1. UML models were defined in Enterprise Architect (class diagram and state machine diagram)
2. C code was generated from the previously created models (with the Embedded Engineer plugin)
3. The FMI model description xml file and the FMI API were created by hand
4. The (compiled) FMI API was packaged together with the model description file into a FMU file. This was done with a batch script.

 

 

Automatic Code Generation

Now we want to automate the creation of the FMI model description file and the FMI API. For this purpose we wrote our own Enterprise Architect plugin. To be able to generate semantically correct FMI model description and FMI API artifacts, we attached additional information to the UML models. This was achived through the definition of various UML stereotypes for UML class attributes and methods. Since the FMI defines its own data types we also had to map the data types used in the UML models to the corresponding FMI data types. With these challenges addressed we were able to implement our FMU generation plugin.

 

Future Work

Our work comprises a fundamental prototype that is only a start and could be improved in various ways. The following list describes some issues that could be tackled.

• One limitation of the current implementation is that we are not able to provide initial values for the FMU. Consequently, to test different configurations of our FMU, we always have to set the default values in the UML models and regenerate the FMU for the simulator again. Hence, future work includes creating new stereo types for initialization of FMU settings/variables and testing these bindings.
• We used the FMU SDK simulator for this project. Other (more powerful) simulators should be tested too. Furthermore, co-simulation with other FMUs needs to be tested.
• In our project we restricted ourselves to just look at discrete functions by using the event system of the FMU. To continue the journey we also have to consider continuous functions.
• More complex examples should be considered to test the capabilities of the automatically generated code. By creating more complex examples the practical limitations of modeling a FMU with a class diagram and a finite state machine need to be discovered. Questions like "What can be implemented?" and "What can not be implemented?" need to be answered.
• The automated code generation process could be reduced to a one-click functionality to directly generate the ".fmu" file without any additional compilation and packaging step necessary.

 

Acknowledgement

This work has been supported by LieberLieber in the context of the CDL-Flex project: http://www.sysml4industry.org/.

Screencast

Screencast FMU with UML

Managing Connectors

In this latest instalment in the series Phil Chudley will be looking at managing your connectors in Enterprise Architect.

https://www.youtube.com/watch?v=UhTsvUDrgDU

As always all of our videos are available right now via our YouTube channel ... and don't forget to subscribe!

Creating a Diagram

In this latest instalment in the series Phil Chudley will be looking at the basics involved in creating a diagram using Enterprise Architect.

https://www.youtube.com/watch?v=hs98ZjLqCMQ

As always all of our videos are available right now via our YouTube channel ... and don't forget to subscribe!

On 20 January 2016, researchers Konstantin Batygin and Michael E. Brown at Caltech announced a calculation-based evidence of a massive ninth planet in the Solar System.

Planet Nine would be 10 times the mass of Earth (approximately 5,000 times the mass of Pluto), and have an orbit that is so far away that it could take it 15,000 Earth years to orbit the Sun. It would most likely be an ice giant with a thick atmosphere of hydrogen and helium.

However, as Zeljko Ivezic (Large Synoptic Survey Telescope Project Scientist) suggests “if it exists, might be too small to be discovered with ongoing sky surveys, but large enough to be discovered even with only the first year of LSST data! That would be a great way to start the survey!”

Sparx Systems Enterprise Architect is providing a scalable, shared model to integrate the work of the geographically dispersed LSST team. Enterprise Architect has delivered complete requirements traceability, round-trip code engineering and detailed SysML support.

Additional Resources:

• Case Study: Designing the Large Synoptic Survey Telescope with Enterprise Architect - PDF Document

• Download E-Book: 20 Terabytes a Night: Designing the Large Synoptic Survey Telescope's Image Processing Pipelines - PDF Document
• Official website: Large Synoptic Survey Telescope - Visit Site

Creative Commons Attribution: Planet Nine in Outer Space artistic depiction image by Prokaryotes

On 15 December 2015, ISO 19160-1 was released.  This standard was developed by ISO/TC 211- a standard technical committee within the International Standards Organisation (ISO), to cover the areas of digital geographic information and geomatics.

The ISO 19160-1 standard defines a conceptual model for address information, together with the terms and definitions that describe the concepts in the model. The model was developed in Enterprise Architect and is presented in the Unified Modeling Language (UML).

For almost a decade Sparx Systems has supported the global geospatial community through provision of Enterprise Architect licences for standards development and inclusion of
Esri ArcGIS and GML profiles within Enterprise Architect.  

Additional Information:

• Press Release: Sparx Systems modeling tools adopted by ISO Geospatial Community
• Product Infrormation: Spatial Information Modeling with GML and ArcGIS
• Product Information: ArcGIS Geodatabase Design with UML
• Enterprise Architect User Guide: Geodatabase Design for ArcGIS
• Enterprise Architect User Guide: MDG Technology For GML
• Webinar Recording YouTube Playlist: ArcGIS Geodatabase Modeling

Introduction

Straight out of the box, Sparx Enterpise Architect provides support for multiple modeling notations. Using a synergy of notations can result in a better description of business architecture. This article considers how ArchiMate, BPMN and UML can be combined into a model that is focused at a high-level of abstraction, whilst still allowing for some critical details to be explored.

Revealing layers of abstraction

As explained in Marc Lankhorst's book Enterprise Architecture at Work (third edition, p. 117), modeling notations provide a way to represent knowledge. The process of building, sharing and transforming the model can foster a new level of understanding amongst the participants. This refined knowledge is (at least) as valuable as the resulting model artifacts (the representation). Effective communication of that knowledge requires consideration for the target audience and an appropriate level of detail.

ArchiMate is good for:

• People who have a job title like Enterprise Architect or Business Architect.
• Presenting high-level and layered abstractions of the business itself, along with the software and technology that are used to support it.
• Tracing and illustrating how the motivating strategy is realised by the business.
• Planning the evolution and transformation of a business.
• Supporting concepts that are similar to those found within TOGAF.

By design, the ArchiMate 2.1 specification does not (explicitly) provide for detailed:

• Business process modeling
• Data modeling

Meanwhile:

• BPMN (Business Process Modeling and Notation) is focused on the detailed modeling of business processes; naturally enough, BPMN is increasingly used amongst the Business Analyst community.
• UML Class diagrams may be used to detail data types, along with the relationships between data types; they are widely recognized amongst software developers, and a good alternative to using entity relationship diagrams for logical data modeling.

Coordinating multiple notations in a single model repository

UML is the native metamodel and notation of Sparx Enterprise Architect. Each additional notation (such as ArchiMate and BPMN) is provided as a MDG (Model-Driven Generator) technology within the tool. The UML specification provides for semantic extension of the UML through the mechanism of Profiles, Stereotypes and Tagged Values. Profiles are the heart of each MDG Technology, enhanced with Sparx tool specific details supporting new types of diagram notations and diagram toolboxes.

Using multiple notations within a single repository requires a disciplined approach in order maintain clarity. In brief, the best practice is to:

• Restrict the elements of each notation to a separate root node.
• Use the UML «Trace» dependency to provide an elegant way of relating elements belonging to different notations.

Add root node to your Sparx Enterprise Architect repository

You might not have realised that the File|New Project… menu option is something of a misnomer. Both EAP and FEAP files are actually self-contained model repositories, and can therefore contain multiple root nodes (just like a RDBMS hosted shared repository, whether accessed through an ODBC or Cloud connection). As a reminder, you can add a new root node into a repository by performing the following steps:

1. If necessary, click View|Project Browser to open the Project Browser window.
2. Right-click inside the blank (white) area of the Project Browser window and then click Add|Add Root Node….
3. The Create New Model (root node) window is displayed. Type MyCorporation (ArchiMate) into the Model Name field.
4. In a similar way, create root nodes for:
   • MyCorporation (BPMN)
   • MyCorporation (UML)

Create a «Trace» dependency between elements belonging to different notations

As stated in the Unified Modeling Language 2.5 specification (p246):

"Models can have Abstraction Dependencies between them: refinement (stereotyped by «Refine» from the Standard Profile) or mapping (for example stereotyped by «Trace» from the Standard Profile). These are typically represented in more detail by Dependencies between the elements contained in the Models. Relationships between elements in different Models generally have no direct impact on the contents of the Models because each Model is meant to be complete. However, they are useful for tracing refinements and for keeping track of cross-references between models."

ArchiMate for an architectural understanding

For example, an ArchiMate Business Process Viewpoint diagram for Purchase Item might look as follows:

This provides a high-level overview of a core business process, with enough detail to inform stakeholders and decision making at a whole-enterprise level of abstraction.

BPMN for detailing business processes

BPMN can be used to detail the ArchiMate Business Process concept, as follows:

UML for detailing the data entites

UML Classes can be used to detail the ArchiMate Business Object concept, as follows:

Usually, diagrams should only contain a single notation. In the examples above, multiple notations are deliberately used to visualise «Trace» dependencies between the ArchiMate, BPMN and UML elements.

How-to add «Trace» dependencies between elements model elements

Best practice for adding «Trace» dependencies using a diagram is to:

1. Temporarily add the required elements of the foreign notation to a diagram.
2. Draw the «Trace» depencies between elements.
3. Remove the foreign notation elements from the diagrams, whilst retaining the traceablity links within the model repository. (So, delete the foreign elements from the diagram, but NOT the repository).

Alternatively, you could use the Relationship Matrix functionality of Sparx Enterprise Architect (click Tools|Relationship Matrix to get started).

Summary

The UML specified «Trace» dependency (relationship) is an elegant way of tracing between different modeling notations. Sparx Enterprise Architect provides a wide coverage of modeling notations, by leveraging the UML Profiles mechanism, and enhancing it with MDG technologies. In practice, this enables a synergy of the ArchiMate, BPMN and UML notations. Models can be constructed as layered abstractions, moving from one notation to another to suit the level of detail required by the user and intended audience.