Enterprise Architect version 15.2
My Profile
Help
Hot Topics
Top Community Contributors
Social Media Channels
Displaying items by tag: API
Tutorial: Domain Driven Database Design
The first video of our CodeBot 201 tutorial series walks you through defining a domain model for a Fantasy Football app, and using CodeBot to instantly transform the domain model into a complete MongoDB database and REST API:
How easy is it to generate a working database and API from an EA domain model? Really, really easy...
This video will show you how in less than 3 minutes…which is about how long it takes for you to try it yourself. In our example, your app can show video of the players scoring touchdowns in near real-time
In this video we’ll follow the evolution of the TEAM object from a noun on a short problem domain description,
Team is an object in the problem domain
to a class on a domain model diagram,
A Team has an Owner and a Roster and a Schedule
to a Mongo DB collection with a NodeJS REST API (documented in Swagger),
Use the API to Create Teams, Read Teams, Update Teams…
and a client-side layer that makes accessing the API nice and straightforward.
You don’t need to call the API directly because CodeBot generates client-side code including usage samples
CodeBot is a complex product that does an incredible amount of work to simplify your life as a developer. Give it a try today!
Anatomy of an Executable Architecture
Anatomy of an Executable Architecture
A few months ago, we released the Parallel Agile Add-in for Enterprise Architect. This add-in gives Enterprise Architect users a unique opportunity to save substantial amounts of time in building the database infrastructure for your project, because you can now generate it automatically from a domain model (class diagram). What gets generated includes database access functions, an API to access the database, API documentation of, and some client side code that shows you how to call the API - what we're calling an Executable Architecture. Our first target platform is MongoDB and Node.JS (aka MEAN Stack), but we're currently working on additional platforms including MySQL and Firebase, so stay tuned.
Meanwhile, let's say you’re starting a new MEAN Stack project and you’re going to need a MongoDB database, Node API to access it, API documentation and some client-side code, so you can start prototyping. How fast can your engineering team get it done? How about an hour?
With Parallel Agile CodeBot you can spend an hour or so with the project stakeholder, BA and a bunch of other people, creating a domain model. Then simply right-click in the model and click Generate Project. Seconds later, you have a complete, working API, client library, Swagger API docs, and it’s already hosted as a live prototype API for your team to try out.
Here’s an example of what CodeBot will create based on your domain model, for a Node/Mongo architecture:
Let’s say you’re creating a single database collection called PaymentMethods. Typically you would need to create at least all of the following, just to be in a position to start prototyping the UI and so forth.
First, you would need to build the basic set of database access functions for each database collection (or table) that you’re going to need. These are the CRUD (Create, Read, Update, Delete functions). In a NoSQL database like Mongo these are implemented with GET / PUT / POST methods:
Next, you would need to define a REST API to allow your client-side code to call the database access functions. In a MEAN Stack application these are bundled together in an Express JS file as shown above. Note that each of your database access functions has several layers of exception handling that need to be built.
After creating the API, you’ll need to create API documentation so that your client-side developers know how to call it:
Once your API is in place and documented, you’ll want to write some client side code that encapsulates the database access methods. You might write a JavaScript client that handles callbacks:
Or you might write a Java client:
It’ll make sense for your Java client to have an entity class (often referred to as a Plain Old Java Object or POJO) available for each domain object:
All of this code is infrastructure for your project, and tends to be of a somewhat boring and repetitive nature - you always need to write the database access functions, they need to be written for each collection, and the code is all very similar to the code you wrote yesterday. Writing it by hand is slow, tedious, and error-prone.
Yet in thousands of development organizations around the globe, developers are writing the database access layer of their applications manually. We asked ourselves if there was a better way and decided the answer was yes. And then we built it. If you’d like to try it, download the free Parallel Agile Add-In for Enterprise Architect.
Automated FMU Generation from UML Models
Automated FMU Generation from UML Models
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:- UML models were defined in Enterprise Architect (class diagram and state machine diagram)
- C code was generated from the previously created models (with the Embedded Engineer plugin)
- The FMI model description xml file and the FMI API were created by hand
- 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.