Displaying items by tag: mean stack development
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.
How To Go From Domain Model to Fully Deployed Microservice in 60 Seconds with Parallel Agile CodeBot™
Managing a student project with Enterprise Architect - Part 4
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.