Enterprise Architect version 15.0

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

Tuesday, 01 October 2019 08:45

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:

infrastructure

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:

 CreateOne Mongo

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:

CreateOne API Docs

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:

CreateOne JS Client

Or you might write a Java client:

CreateOne 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:

pojo

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.

Published in Tutorials

One of our biggest challenges at Parallel Agile is explaining how two apparently unrelated aspects of our business are actually very closely related. Specifically, how our domain driven database and API generator (aka Parallel Agile CodeBot) enables the Parallel Agile Process, which allows large teams of developers to collaborate more efficiently and breaks the “two pizza rule” on team size.

To understand how the CodeBot enables large-scale parallel development we need to go back to Brooks’ Law, the widely believed postulate that you can’t accelerate a software project by throwing more developers at it. Fred Brooks identified some key reasons why this has been (for the most part) a truism for the last 50 years. Two of the most important reasons are:

1) Communication. When you add new developers to a software project, somebody has to explain to them how the existing code is structured, and the new developers each have to experience a learning curve before they can be productive. Generally it’s the experienced developers (who are already productive) that have to take time away from their own work to train the new folks. So adding developers can actually slow you down.

2) Integration. If you have a large team of developers working (relatively) independently, it’s going to be difficult to make all of the pieces plug together and play well as an integrated whole piece of software.

It’s important to remember that Fred Brooks developed his postulate while managing a large mainframe operating project (OS/360), which was introduced in 1964. That’s a long time ago. There were no UML modeling tools, no REST APIs, no NoSQL databases. So it’s not unreasonable to ask the question 55 years later whether any modern technical innovations might mitigate some of the underlying factors that have made Brooks’ Law seem to be inviolable for such a long time. That answer turns out to be Yes – making a domain model executable mitigates both the communication and integration problems and enables large-team development to work a lot better.

While I’ve never been a big fan of Brooks’ Law, when we started the research that led to Parallel Agile, there was no particular intent of trying to disprove it.  It started back in 2014  when Barry Boehm and Supannika Mobasser invited me to give a guest lecture on ICONIX Process in their  CS577 Software Engineering class at the University of Southern California.   Around this time I had developed an interest in geofencing, and had in mind to develop a geofenced mobile app that delivered coupons to your phone when you got physically close to the business that was offering the coupons. 

LBA use cases

When I accepted the invitation to guest lecture I decided to ask if they would like me to grade a couple of UML homework assignments in addition to guest lecturing. They agreed so I split my Location Based Advertising project into 47 low level use cases and assigned one use case per student as homework (writing prototype code for the use case was optional extra credit).

To make a long story short, we were all surprised that the 47 independently developed use cases actually integrated into a cohesive system. I can clearly recall sitting in Barry’s office saying “you know, that’s not supposed to be possible” and Barry agreeing “yes, I know”. When we started investigating how the successful integration happened it seemed that we had made some fortunate choices of using a NoSQL database (Cassandra) and a REST API (Node JS), and giving all the students a code template that implemented the database access functions (aka CRUD functions) for a Cassandra collection that they could clone for their part of the database.

LBA Domain Model 2

 

It turned out that having the domain model in place made communication across the large (47 student) team go pretty well, and having all of the database access functions available through a REST API allowed different pieces of the system (iOS app, Android app, web app) to integrate together with ease.  And when we studied the effort numbers it turned out that each of the 47 use cases took about 4 days to develop – a day on requirements analysis, a day on design, and two days of coding.

One of the student from that project joined the PhD program and implemented a code generator that turned domain models into Mongo DB and Node JS, and after using this successfully on several other projects we decided to start Parallel Agile.

So, to sum it up…having a visual model of the problem domain makes it easy for everybody to get on the same page about what’s being built.  Generating your database from this domain model, and having a uniform set of functions to Create, Read, Update and Delete items in the database makes it easy for everybody’s code to integrate together.  And that’s how a code generator enables large-scale parallel development.

Published in Tutorials

 

We've just released a major upgrade to the Parallel Agile CodeBot.  As you might already know, CodeBot generates database schema, database access functions, and a REST API to access the database from a UML domain model.  But you might not know specifically how the class diagram is interpreted during code generation.

Here’s a simple domain model for a video editor that allows you to annotate an image for machine learning.

domainmodel

This example only uses Aggregation, but several other relationships are possible.  The table below explains how CodeBot interprets what’s on the diagram.

UML relationships

You should find Composition useful for creating nested JSON structures; something which particularly lends itself to MongoDB collections, where the recommended “best practice” is that child elements with a strong ownership relationship are nested within each parent element, rather than being put into separate collections.

All other relationship types – Dependency, Realization, Responsibility etc (ad infinitum) – are treated as “non-semantic” by CodeBot, so can safely be used to define more abstract concepts that document the model rather than drive it.

How Multiplicity affects what’s generated

If you define multiplicity in the relationships (e.g. 0..1, 1..*), CodeBot uses these wherever possible for validation checks. If you don’t define the multiplicity, it defaults to either “0..1” or “1”, depending on the context.

Multiplicity also affects whether fields are generated as a single item or a list of items. Additionally, in languages that support optional types (e.g. Option in Scala, or Optional in Java), a multiplicity of 0..1 will be generated as an optional type.

Let’s quickly illustrate that with some brief code examples:

multiplicity

Try CodeBot for free at http://www.parallelagile.com/codebot.html

 

Published in Tutorials
Thanks to my colleague Matt Stephens for writing this tutorial on the CodeBot that he's built.  You can download the CodeBot tutorial here, and also watch a CodeBot Tutorial video  here.
codebot
Parallel Agile CodeBot™ is accesible through the Parallel Agile Add-in for Enterprise Architect.  The CodeBot generates a complete REST API from your UML domain model. This article illustrates step-by-step how to run CodeBot from within EA, and incorporate the instant generated API into your domain driven project.
Find out more about Parallel Agile and try out CodeBot for free.
By the way, we also offer training, consultancy, and support for projects using CodeBot and the Parallel Agile development process. If this sounds like just what your organization needs, contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.
Published in Tutorials

This article will introduce you to both the Parallel Agile (PA) process and to the Parallel Agile Add-in for Enterprise Architect, which enables the PA process for Sparx customers.

Download the article in PDF here.

 

Parallel Agile Addin for Enterprise Architect

 

The Parallel Agile Add-in generates database access code and REST APIs from domain models, and it works in conjunction with the ICONIX Agile DDT Add-in, which generates acceptance tests from requirements and use cases.   Both add-ins are free.

We’ll discuss:

  • What’s Parallel Agile?
  • Compressing schedules with parallel development
  • Improving quality while compressing schedule
  • Why did we build an Enterprise Architect Add-in?
  • What’s an Executable Architecture?
  • What’s a Parallel Agile CodeBot?
  • Using the CodeBot to generate code for your domain model
  • Using our Cloud-Based Hosting Service to Test Your Generated API
  • Use Case Complexity Analyzer
  • Parallel Agile MDG Technology - supports Sprint Plans

 

 

 

Published in News