Enterprise Architect version 15.2

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

Displaying items by tag: node js

Thursday, 10 December 2020 20:34

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:

 video title

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,

list of nouns

Team is an object in the problem domain

 to a class on a domain model diagram,

domain model

A Team has an Owner and a Roster and a Schedule

 

to a Mongo DB collection with a NodeJS REST API (documented in Swagger),

API docs

Use the API to Create Teams, Read Teams, Update Teams…

and a client-side layer that makes accessing the API nice and straightforward.

client code

 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!

Published in Tutorials

How to create a full-stack React Bootstrap UI in under 10 minutes

A tutorial and reference on designing a complete web application and generating it with CodeBot UX

by Matt Stephens, Parallel Agile

This article was originally published here: https://medium.com/parallel-agile-blog/create-a-full-stack-react-bootstrap-ui-in-under-10-minutes-d0eec3077618

CodeBot from Parallel Agile is a full-stack application generator, which can also host your generated application in the cloud. Give CodeBot a domain model and UI wireframes, and it’ll create:

  • a React web UI
  • a MongoDB database
  • a Node/Express.js REST API, optionally secured using JWT
  • API client libraries — currently Java and JavaScript, with other languages set to be released soon, including C#, Swift, TypeScript
  • JSON Schema
  • Swagger/OpenAPI docs

We have more targets, platforms, architectures and languages on the way, but that’s plenty to get started with!

To whet your appetite, here’s a quick CodeBot video that shows a project being turned into a generated UI:

tutorial1

 

Getting Started

To get started designing your new application, you’ll need:

  • a copy of Enterprise Architect (EA)  to create the domain model and wireframes
  • a CodeBot account from Parallel Agile

At the time of writing, the generated React UI isn’t in full release, but it’s available under Early Access for customers with a CodeBot license (to gain access, please email us)

There’s also a handy series of step-by-step CodeBot 101 videos that show how to get everything installed and set up — so I won’t repeat those details here:

VSRADS Example

In this article I’ll walk through the a much-simplified version of the “VSRADS” model shown in the above example video.

VSRADS stands for “Very Short Range Air Defence System” — it’s basically a mosquito zapper. It listens for the high-pitched whine of a mosquito flying by, calculates its position and trajectory, and zaps it with a low-frequency laser.

Our example project is a state machine simulator… given a series of states, a web page is generated to represent each one; and the state machine itself is turned into the navigation “user flow” between pages — i.e. the routes.

So let’s get started!

Step 1: Create a project with 3 top-level packages

Create a new, blank project in EA, and give it the following 3 packages (via “Add View” in the right-click menu):

tutorial2

 

This will become a familiar pattern… the “three amigos” for defining a new full-stack project

When the model is generated later, the elements in each of these packages will contribute to the generated application, as follows:

tutorial3

  • Each wireframe is turned into a React web page
  • The navigation state machine is turned into a set of routes
  • Each domain class (created in the Domain Model package) is turned into a MongoDB collection and REST API create/read/update/delete endpoint

Step 2: Draw the domain model

Under “Domain Model”, create a class diagram and populate it with some domain classes.

The complete VSRADS domain model looks like this:

 tutorial4

For this example you could just create a subset — just be sure to include Simulation Run, as we’ll be linking it to the UI and database.

Step 3: Design the UI Navigation

The idea is that you design individual screens as wireframes, and link them together via a “user flow” or navigation diagram; in this case we’ll draw the user flow as a state machine:

  • Each state represents a screen or page
  • Each transition (the arrows linking the states together) represents a navigation route

Navigation routes are triggered by things like clicking a link, or submitting a form — “create” or “update” actions.

To introduce the idea, here’s a “hello world” kind of example:

 tutorial5

 

Each generated page will be given its own URI (/login, /view_products etc) so can be individually bookmarked. However, the “Initial” pseudo-state is used to determine which page is displayed by default— the “navigation root” or home page.

Back to VSRADS though… this is a more complex state machine:

 tutorial6

 

Each transition arrow has been given a trigger, which is shown as a label in the diagram. To add a trigger, double-click on the transition:

 tutorial7

 

In EA, you don’t need to select the trigger type etc, you can just enter a name, to keep it simple.

The name needs to match up with the component name in the wireframe, e.g. a button called “Target Identified” — you’ll see some examples of this in the next section.

Usually, the trigger name is also prefixed with an event type, such as on click: or on create: . However, “on click” is the default, so can be omitted.

It’s also worth noting, if the button name is the same as the target page, then CodeBot will figure it out, so you then don’t even need to give the transition a name.

The following event prefixes are supported:

  • on click— e.g. “on click: Login”
  • on create — e.g. “on create: Target”
  • on update — e.g. “on update: Target”

The events all take place in the “source page”, i.e. the page that the transition arrow points from. The trigger will, as you’d expect, result in the app navigating to the “target page”.

The create and update events are triggered when a form is submitted in the “source page”.

Now that you have the overall website or application designed, it’s a good time to create a wireframe for each one.

Step 4: Design the wireframes

EA has a UI wireframe designer built-in. Because the wireframes are fully integrated into the UML model, you can link together wireframe elements, classes, states and other elements… so everything fits together in the generated project.

The VSRADS model has 8 wireframes in total. For this article we’ll focus on two of them, Set Up Simulation (the start page), and Listening for Mosquitoes.

Creating a Wireframe

Right-click on the Wireframes package and choose New Diagram:

tutorial8

In the new wireframe, you need to create a top-level frame which serves as the page-size boundary. This may seem less relevant for websites, but will become important when CodeBot also generates other platforms such as mobile apps. (New feature coming soon!!)

 tutorial9

Always add a “Client Area” to represent the page boundary, and fit all the wireframe components inside it

Next, add some components to the page!

  tutorial10a

Currently with the Early Access release, CodeBot recognises a subset of all the available components. So for now, be sure to only add from the Controls and Website Controls tool palettes.

Position and size the components to match your page design. CodeBot will translate this into a responsive website layout; e.g. it’ll detect grids of label/textfield pairs, alignment of individual labels or buttons, etc.

You can also supply hints to influence how the page is generated. In EA, this is done via tagged values — you can find these on the Tags tab in the Properties panel:

 tutorial11

In the above screenshot, the Set up Simulation title has been given a tag called css class, with the value h1 (“Heading 1”). To add more than one CSS class, separate them with spaces.

The generated website uses the popular React-Bootstrap project, meaning you can specify any “Bootstrap-standard” CSS classes here.

Another useful tag is variant. This conforms to the Bootstrap 4 colour variants:

 tutorial12

For example, the Run Simulation button is given the “primary” variant (the exact case doesn’t matter) via a tagged value, so will be rendered in the page with a solid-blue background:

 tutorial13

In this way, it’s possible to adhere to Bootstrap’s design language—the “primary” variant represents the main or default action, etc.

For future platforms even if they don’t use Bootstrap, CodeBot will adapt the same “Bootstrappy” tagged values to the target platform, so you’ll only have to draw the wireframes once in order to get a generated website, mobile app, desktop app etc.

Just to illustrate another page in the same UX design, here’s the Listening for Mosquitoes wireframe:

 tutorial14

The Image component can display any image type normally supported in web browsers (jpeg, gif, png). Just include a url tag with the complete URL where the image can be loaded from.

Step 5: Define actions on UI elements

In the previous screenshot, the Run Simulation button also has a tag called action, with the value create.

As long as the button resides in a container panel with form components (text fields etc), when the button is clicked, the form will be submitted to the generated REST API. What happens next depends on the value of the action tag:

  • create (create a new record in the database)
  • update (update the current record)

The form elements do need to be linked to a particular domain class, though; so let’s do that next.

Step 6: Link UI elements to the domain model

There are two ways to associate UI elements with a particular domain class:

  1. Use the domain tag
  2. Draw a dependency relationship from the UI element to the domain class

Which one you use is entirely up to you; the effect on the generated code is exactly the same. It’s more of a stylistic choice, as some people appreciate the visual aspect of seeing a link on the diagram, while others prefer the detail to be tucked away.

Domain tag

Click on the form component you’d like to link, and add a tag as follows:

tutorial 16a

The domain tagged value uses the form:

Class Name.attribute name

e.g. Simulation Run (the domain class), a dot, then name (the attribute name).

As a time saver, you can also just add the domain class name to the parent container panel:

 tutorial17a

The “child” form components are then auto-linked to the domain attributes, by matching each component name with an attribute name.

Once this linking-up is done, then when the generated form is submitted, it’ll automatically call the correct REST API endpoint for that domain class.

Dependency arrow

As an alternative to the domain tag, simply drag the relevant domain class from the package explorer onto the wireframe. Then draw a dependency arrow from the container panel to the class:

 tutorial17

You can also link the individual text fields to the class, if preferred.

To emphasize again, this has exactly the same effect as using the domain class; which you use is just a personal preference.

 

Step 7: Generate the application

If you have the CodeBot add-in installed in EA, right-click on the root (“Model”) package in the package browser. Then choose:

Specialize > Parallel Agile > Generate Project

If you can’t run the add-in for any reason (e.g. you’re on a Mac using a Windows VM), another way to run CodeBot is as follows:

  1. Make sure you’ve selected the root (“Model”) package, then from EA’s ribbon menu, choose:
    Publish > Export-XML -> Export XML for Current Package
  2. Login into the CodeBot Web Console at parallelagile.net, and choose Upload XMI:

 tutorial18

tutorial19

CodeBot will detect that the model contains wireframes, and automatically generate a Bootstrap-React project. You can find it in the downloaded zipfile, in the UX/React folder.

 

Step 8: Run the React app!

You can optionally elect the generated application to be hosted — just make sure the “Publish to our cloud service” checkbox in the above screenshot is ticked.

In this case, CodeBot will automatically build the React app, and then publish the full website, REST API and database to our secure cloud service.

To access the hosted website, click the blue Visit Website button (visible in the above screenshot).

The Set up Simulation page will load in a separate tab:

 tutorial20

 

When you enter some form details and click Run Simulation, the following series of events take place:

  1. Due to the action tag and the linked domain class, the React app submits the form to the REST API
  2. The REST API validates the form data against the generated JSON Schema (based on the domain class and attributes), then creates the new record in the MongoDB database
  3. Due to the on create: Run Simulation trigger on the navigation state machine, the React app will detect that a “create” just happened linked to the Run Simulation button. So (as the trigger is on a transition), the browser navigates to the next page, Listening for Mosquitoes:

 tutorial21

In closing…

CodeBot UX radically shortens the iterative feedback loop when developing new software. When domain modeling, you can now quickly create a working prototype, use the prototype to elicit new or changed requirements, feed the updates back into the model, rinse and repeat…

… often several times in the same workshop session, with the customer or domain expert right there in the room (or on the same Zoom call).

CodeBot UX is available now for Early Access customers. To request access, please email us at: This email address is being protected from spambots. You need JavaScript enabled to view it. — we’ll welcome your feedback!

Published in Tutorials
Wednesday, 25 November 2020 08:43

CodeBot UX is available to early access users

FOR IMMEDIATE RELEASE:  November 23, 2020

Urvashi Prakash Parallel Agile

This email address is being protected from spambots. You need JavaScript enabled to view it.

No Code App Generator, CodeBot UX is available to early access users 

 

November, 2020, Los Angeles, CA: Parallel Agile’s full-stack application generator, CodeBot UX, is now available to early access users. With CodeBot you can already generate full-stack applications from a domain model, while its newly engineered UX components allow users a smoother and far more nuanced and centralized approach towards app generation.

Codebot UX supports Enterprise Architect UML models including class diagrams, state machines and wireframes. From these, CodeBot generates a database schema, API documentation, server-side code, client-side code including domain classes, CRUD functions and usage examples. While supporting both SQL and non-SQL databases, CodeBot also generates all three layers of the MVC framework.

CodeBot can also automatically host your generated web application in the cloud, at the click of a button.

According to Matt Stephens, Director of Development for Parallel Agile: "Our ability to link screens to an auto-generated database access API and to drive UI navigation from state machines effectively makes MBSE models executable, fulfilling a vision originally set out in 2002 when Steve Mellor wrote Executable UML".

With this early access release, the following React UI components are ready for users to try out: Panel, Button, Label, Text field, Table and Video Player.

CodeBot UX initially targets React, but will soon build equivalent user interfaces for React Native, Vue.js and Angular.  Video illustrating CodeBot UX (MBSE: CodeBot for Software Intensive Systems) is available on YouTube.

Doug Rosenberg, Parallel Agile CTO, states: "CodeBot UX’s ability to generate working screens from wireframes to full stack code generation and automatically host the working application, introduces a new model-driven development paradigm where CodeBot effectively serves as a UML compiler, producing running applications directly from UML or SysML models."

 More about the company:

Parallel Agile addresses the underlying technical issues with integrating work done by large teams in addition to the management issues – specifically enabling large teams of developers to collaborate efficiently and reduce schedule time on projects.   The company offers training in UML, SysML, MBSE, and Agile development in addition to its full-stack application generator, CodeBot.

Early Access Program

Parallel Agile’s early access program allows CodeBot licensees to gain access to a growing range of new features and capabilities.  New CodeBot customers can request early access when they purchase their license.

CodeBot UX is available immediately for early access users.

For more information on CodeBot, please visit www.parallelagile.com or email us at: This email address is being protected from spambots. You need JavaScript enabled to view it.

###

Published in News
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
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

 

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