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

 

In Parts 1, 2, and 3 of this article series we introduced a student project that I’m managing at the University of Southern California Center for Systems and Software Engineering.  This article (Part 4) describes the results of our first semester’s effort.  We are currently getting started again on enhancements with a new group of students for the Spring 2017 semester.  USC’s location in downtown Los Angeles is at the epicenter of a lot of bad driving, so we’re attempting a “crowdsourced bad driver reporting system”.

Our system consists of a voice-activated “dashboard-cam” mobile app connected to a Mongo database in the cloud, via a Node JS REST API, and some Angular JS webpages to file, review and query bad driver reports.  This technology stack for our web-app is sometimes referred to as MEAN stack (Mongo, Express, Angular, Node).  We developed a native Android mobile app in Java, and a native iOS app in SWIFT.  Following the Resilient Agile process, and using Enterprise Architect to model the project, we attempted to go from zero to a working system in about 12 weeks of class time, by having students develop use cases in parallel with each other.  Previous articles in the series have presented snippets of the UML model but everybody knows that successful implementation is where the rubber meets the road.  So this article will show you how far we got.  

When the driver issues either the “Report Bad Driver” or “Emergency Alert” command, the mobile app triggers video upload and server-side creation of the Bad Driver Report or Emergency Alert Report, as appropriate .   The server then sends an email to the driver’s posting account with a link to a new report that’s pre-populated with the video.

While submitting the report, the poster reviews the video, records the license plate number, and grabs a single video frame that most clearly captures the offending vehicle.  The report is then made available for independent reviewers to evaluate.  The system requires unanimous agreement from 3 independent reviewers that the report is accurate.  Once this consensus has been achieved, the report is entered into a database that is queryable by insurance companies.

From a development standpoint, we were able to exploit parallelism among the students to complete this set of use cases (including defining requirements, UML design, and coding) in approximately 12 weeks of calendar time with 15 students each contributing 5 hours a week.  This calculates out to 900 student-hours or 22.5 equivalent full-time work weeks.  In other words, about half a person-year total effort.

Published in Case Studies