Adventures in User Interface Design and Code Generation – Part 1

Doug Rosenberg

Parallel Agile

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

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

We’re busy these days teaching CodeBot how to generate fully functional web applications from UML models, with as little coding as possible (and ideally with no coding at all).  The basic steps involved are

1. Develop a domain model and code generate database and API
2. Wireframe the screens and link them to the API
3. Develop a UX Navigation State Machine that defines the sequence in which screens appear
4. Code Generate and automatically host the generated database, API, and web app code
5. Test, iterate, and refine

We’re using a Location Based Advertising (LBA) System to test CodeBot’s performance on a real project.  LBA is a geofenced coupon delivery system and its web application allows advertisers to Register for an Account, Login, and Publish Coupons.  These coupons are then received by a mobile app that’s connected to the hosted API when a geofence is entered.

CodeBot Generates UI Code

CodeBot generates React/Bootstrap code from wireframes as shown in Figure 1.

Figure 1 - No coding is needed to create the Registration Page – because it’s generated from a wireframe

The screens are linked to the API using UML Tagged Values, and both Registration and Login are done securely on the server-side using JWT authentication, as CodeBot generates Login and Register methods in the API automatically. The sequencing of the generated screens is defined using a UX Navigation State Machine as shown in Figure 2.

Figure 2 - First draft UX Navigation state machine is simplistic

At first glance, the initial state machine makes sense; first you Register and then you Login, right?  But when you code generate the project and start using the hosted web app, you quickly realize that whoops, once I’m signed up, I don’t want to see the Registration page anymore.  I want the web app to take me to the Login page first, and if I’m a new user, allow me to Register, then take me back to Login.

Which comes first, the chicken or the egg?

From a use case standpoint, it’s a pretty simple modeling decision…does Register <precede> Login or does Login <invoke> Register?  If you reflect on it for a few seconds, it’s pretty clear that Login needs to invoke Register (Figure 3). This is where the rapid iteration between design, generated code, and hosted application that CodeBot enables really shows its power. 

Figure 3 - In a real system, Login <invokes> Register, because you only Register once

Developing at the speed of thought

An ideal scenario would be to make these changes to the application at the speed of thought…just re-wire my state machine (Figure 4), make a couple of changes to the Register and Login wireframes, press the button and have CodeBot automatically re-generate the entire web application and host it in the cloud.

Figure 4 – Ah, that’s better: re-wiring the state machine to start with Login

As “developing at the speed of thought” is the goal of CodeBot, that’s exactly how it works. The re-wired state machine now starts with Login and handles transitions between Login and Register Pages.

Figure 5 – Modified Login wireframe allows us to Register new users

While we’re re-wiring the navigation state machine, we also update the Login wireframe to take new users to the Register page (Figure 5) and similarly update the registration page.  After a quick visit to the CodeBot web console we’ve got a re-deployed web application as shown in Figure 6.

Figure 6 - Ah, that's even more better.  CodeBot makes quick work of generating and hosting the new web app.  It’s up and running in minutes!

The real power of CodeBot driven UX development is the ability to rapidly generate and deploy new versions of an application in minutes to get the feedback-driven benefits of agile development.  Short iterations are the key to developing a refined and customer-tested user interface (and associated access-controlled database).

How do we manage one developer per use case?

If you’ve been reading anything about Parallel Agile you already know that we like to enable projects to get done quickly by having developers work in parallel.  So we might have one developer working on the Login and Register wireframes and another working on the UX Navigation state machine.

Figure 7 - Working in parallel requires good version control

What if each of our developers were working on a separate UML model?  We’d need some way to manage and merge versions of the model.

Like branches on a tree

We’ve recently discovered a companion product to CodeBot that manages branching of UML models in a way we’ve always wanted to see – with visual differencing on diagrams. That product is called LemonTree, from LieberLieber software. We’re pretty excited about the potential of using CodeBot and LemonTree together (more on that coming soon).

Figure 8 - LemonTree does visual differencing on state machine diagrams

Figure 9 - Visual differencing on wireframes enables parallel development

With visual differencing and model versioning, the “one developer per use case” paradigm of Parallel Agile becomes quick and easy to manage.

The Need for Speed

Our mission at Parallel Agile is to help you to develop software radically faster while simultaneously improving its quality.   Our approach is to systematically remove obstacles from from an idealized process of “developing at the speed of thought”.

At a macro level, speed improvements are made possible by encouraging a scalable one-developer-per-use-case paradigm.  This is enabled by CodeBot’s automatic generation of database, API, and API documentation from an easy-to-understand domain model. Incorporation of things like JWT tokenized Registration and Login and Role Based Access Control into CodeBot’s API generation simplifies handling of data privacy issues.

At a more-fine grained level (within each use case) CodeBot’s generation of web applications from wireframes and state machines gets your system up and running in a big hurry, then short iterations of an automatically hosted and deployed application allow for rapid refinement of the system to make sure it meets customer needs.  Management of a highly parallel development process where “the model is the code” is facilitated by LemonTree’s visual differencing and merge capabilities.

If you need to develop software faster and all of this catches your interest, we’d love to hear from you.  User Interface code generation is currently available in pre-release for our Early Access customers (Early Access is available on request for all paid CodeBot licensees).  Watch for announcements coming soon.

Dive in deeper

Video: CodeBot - Generating complete web apps including UI and database

Here are a few links for further exploration:

Parallel Agile Blog: https://medium.com/parallel-agile-blog

Parallel Agile Book on Amazon: https://www.amazon.com/Parallel-Agile-faster-delivery-defects/dp/303030700X

Training on the Parallel Agile Process: http://parallelagile.com/training.html

Parallel Agile CodeBot Home Page: https://parallelagile.net/

LemonTree from LieberLieber: https://www.lieberlieber.com/lemontree/en/

Webinar: Model Management for Low Code Projects: https://www.lieberlieber.com/en/webinar-model-management-for-low-code-projects/

The need for speed

With the recent passing of General Chuck Yeager as well as the beginning of 2021, I thought it might be a good time to reflect on the never ending quest for speed. General Yeager, of course, was the man who broke the sound barrier in his Bell X-1 aircraft on October 14, 1947.

It’s always worthwhile trying to do things faster and better — that’s what drives progress and innovation. In the software industry we’re talking about a less death-defying problem than the airspeed pioneers faced, but an important one nonetheless: how fast we can develop software?

Chuck Yeager and the Bell X-1 that broke the sound barrier, Glamorous Glennis

Our primary mission at Parallel Agile is to help companies accelerate the development of high-quality systems — so projects are both faster and cheaper, without sacrificing quality. (Yes, it really can be done!). Maybe in a few years we’ll look back at today’s software engineering techniques with similar nostalgia as we’d look at 1940s subsonic aircraft design.

What makes software slow?

Let’s start by looking at what’s holding a typical software project back from getting itself done quickly:

Many factors can slow down your project — here are a few chronic causes of software getting done slowly

So, what makes software slow? First of all, the common perception that it’s not possible to develop with bigger teams because of communication overhead. Second, typical agile development processes tend to favor feedback over planning, resulting in under-planned systems that spend lots of time on retrospectives and refactoring. Additional factors relate to a general state-of-the-practice of most code being written by hand — often driven by a general mistrust of generated code. Everything from fundamental database access functions to basic UI functionality is most often still coded by hand. Add in modern requirements for data privacy and database security (things that often don’t fit well into 2 week sprints) and you’ve got lots of time spent writing code the hard way — labor-intensive development. Finally, with CI/CD we’ve got deployment pipelines that get executed on a continuous basis.

How do you go supersonic with your dev process?

So, what’s the right stuff that can help you accelerate your software project? Parallel Agile as a development process, and CodeBot as its primary enabler, offer a different vision for software engineering where the speed limiters shown above are systematically removed. You can remove some of the speed limiters and go faster than before, but it’s really removing the whole set of forced-slowdown practices that yields the most dramatic results.

If your project is being slowed down by anything on the list above, we can help.

Project development is organized by scenario In the first place, from a process perspective, with Parallel Agile you organize your project with a developer responsible for each scenario (hence the “Parallel” part of PA).

It’s simple: assign a developer to each scenario (scale as needed)

You don’t have to work in small teams (although you still can if you prefer to). Communication overhead is reduced by virtue of a shared (executable) domain model among developers. Rather than time slicing development into 2 week sprints (with time on each end for planning and retrospectives), you can allow each use case to evolve along a simplified spiral model starting with proof of concept, moving on to minimum viable product (MVP) and then through as many optimization cycles as needed.

Each scenario (aka use case) evolves asynchronously along it’s own spiral model

How CodeBot shatters the team-size barrier

Back when General Yeager was pioneering flight faster than the speed of sound, it was a dangerous activity because aircraft tended to shake apart due to excessive vibration at Mach 1. But advances in aerodynamics eventually overcame the sound barrier.

What’s the analogy to large team software development? Consider the case where several use case scenarios make use of the same domain object. If you assign a different developer to each scenario, each of those developers needs a common understanding of the data structure (JSON) that comprises that domain object. If you allow each scenario to evolve independently you’ve got a communication and coordination problem to deal with. Having the domain model documented on a UML diagram helps, but it isn’t enough.

We discovered the solution to this problem during the early years of our research into parallel development — to be specific, between 2014 and 2016. During that time we were experimenting with an early version of CodeBot that generated a database access API (and API documentation) from a domain model. We discovered that our developers were able to collaborate easily, even when some were working on mobile apps and others working on web apps. Our first test project involved 47 graduate students working in parallel, on a location-based advertising system (LBA).

We also found that most of the evolution of domain class schema happened during Proof of Concept, and that using a NoSQL database allowed multiple developers to evolve the schema independently. Later, we added switchable schema validation to CodeBot, allowing more free-wheeling changes during prototyping but then providing the ability to lock things down as we moved forward into MVP. We also made updated API docs immediately available online. This ability to rapidly generate a new API along with updated API documentation as changes happen in the shared domain model allows projects to be staffed elastically — your team can be “right-sized” to the problem at hand rather than constrained by pre-imposed limits. This lets you go a lot faster.

CodeBot turns your domain model into a working database, accessible by a REST API, in moments

Inside the use cases: Getting WIRED

We’ve found that it makes sense to organize the project along use case boundaries, with larger teams of developers each working their own use case, interfacing to a shared domain-driven database API (or event-based model, etc). But what happens inside the use cases? Do we need to do a lot of formal use case modeling? Not necessarily…

We think the fastest way to proceed within each use case is to wireframe up the screens that participate in the use case, connect the wireframes to the executable domain model, and then code generate the screens. Think of this as Wireframe-driven, Iterative, Rapid, Enterprise-ready Development (WIRED).

You might recognize a Model-View-Controller pattern in CodeBot’s generated UI code

We use the CodeBot full-stack application generator to do this code generation for us. In fact, CodeBot is optimized towards PA’s highly iterative process. In short, you can use CodeBot to generate working user interface code (e.g. React JS) from wireframes, where the UI navigation or user flow is driven from a UML state machine, and the screens connect to the database using the API. It all happens automatically, and it happens very quickly with CodeBot UX.

CodeBot UX is the fastest way to get from an EA wireframe to a running web application

Being Enterprise-ready means Security is baked in

To be Enterprise-ready in 2021, you need to deal with requirements for data privacy.  This means avoiding threats from hackers, making your applications fully security-aware, and implementing best practices for secure development. From an app development standpoint, dealing with security concerns slows you down, and complicates hiring and staffing your project as not all developers are expert at security-related issues.

CodeBot-generated APIs come with an Access Control Layer that helps prevent unauthorized access

Over the last year we’ve spent massive amounts of effort building security infrastructure into CodeBot. Capabilities like server-side registration and login automatically generated as part of the API, fully-tokenized (JWT) access, and Role Based Access Control (RBAC) are built-in to the database access API as an access control layer when the model is code generated. The resulting time and cost savings all accrue to your benefit. And if you consider the cost of getting your database hacked…it’s a pretty easy decision to make.

Rapid Iterations come with auto-deployment

To fully realize the promise of agile, feedback-driven development, you need to iterate the project’s use cases quickly to gain immediate feedback from clients. CodeBot enables this capability through automatic deployment of both the UI and the back-end database/API.

With CodeBot UX you go from a UML model to a running (and hosted) web app in under 5 minutes

At present, CodeBot can generate and deploy a securely hosted full-stack web application from a UML model in approximately 4 minutes. This capability makes it quick and easy for each use case to evolve through its spiral model and to quickly test in the context of a deployed system.

So, how fast do you want to go?

Are you content with the pace of small-team, short-sprint agile development, or would you like to deploy a larger team on a more complex problem and get the project done more quickly? Are you happy with the pace of writing database access code by hand, and wrapping the common database functions in a REST API, by hand? Is it quick and easy to turn a set of wireframes into fully-functional user interface code, where the screens are automatically linked to the database? Are you happy with the pace of adding Security to your applications? And finally, does it take you longer than 4-minutes to build and deploy a fully-working application? If you’d like to get your projects done faster and less expensively, but without sacrificing quality… contact us at This email address is being protected from spambots. You need JavaScript enabled to view it..

Application Lifecycle Management (ALM) can move IT and Business to a position of congruency and shift IT from application thinking to process (and service) thinking and in Business, from service to IT. The gulf between Business and IT exists on a relationship from a time past, when there was little contact between the two parties following a commission from Business to IT for services and/or products.

Before the availability of ALM, the window on the progress of development projects lacked transparency for most managers, right to the point when business took delivery. Whatever visibility the managers had, was gathered from assumptions rather than from objective data.

Sparx Systems attended the Gartner Enterprise Architecture Summit in National Harbor during May 2016 where Enterprise Architecture was reviewed as a “catalyst for Digital Tranformation.” and two “big” challenges were identified, as the transformation moves forward. These were, managing the connections within complex ecosystems of communications, partners, platforms, services and technologies and working with New Development methodologies such as Agile, DevOps and Continuous Delivery.

ALM makes IT development visible to upper management and reinforces the requirements of Business to demonstrate Governance, Risk Management and Compliance. On a competitive level it assists in the reduction of development costs, increases innovation and effectively supports change management. As a business process for the management of end to end software development ALM promises benefits in terms of increased project success rates, improved quality of deliverables and reduced development timescales.

Between IT and Business, ALM creates and supports a bridge which embodies a set of processes and methods, including software development, operations, and services, to enhance communication and collaboration between departments. It also aligns the business, development and operations capabilities of the organization, by providing the ability to integrate different tools used and the activities performed within each.

While this establishes a culture of more frequent software builds, tests and releases, the pressure to manage application delivery is growing ,as is the complexity. The need to co-ordinate and automate the process of delivering these projects, with collaborative planning and reporting activities has become critical. Sparx Systems recognises that this requirement makes ALM processes essential to the delivery of worlds best development practices.

"DevOps is a culture that supports improvements
in the software development lifecycle through
automation, best practice and collaboration."

Tight coupling of the stages of the application lifecycle is a key to increasing productivity in application development and establishing traceability and accountability across multiple processes, locations and tool types, in the stages of development and delivery. This completeness of functionality leads to increased quality, reduces time to market and promotes a culture of business agility. By coordinating activity and facilitating communication, ALM provides real time transparency and traceability, proactive change management and error mitigation.

We hear a lot about cultural change in the discussions about DevOps. We also hear a lot about people. Not so much about enabling technology. There is an accepted notion that DevOps is about drawing together people in DEVelopment and people in OPerations with the goal of shortening delivery time through the elimination of constraints that naturally exist between functional silos.

DevOps is a culture that supports improvements in the software development lifecycle through automation, best practice and collaboration. DevOps is about changing culture and the responsibility for this lies with executive management. To realise a cultural change of automation, best practice and collaboration, is to expose the organisation to DevOps benefits,- agility and productivity. As a key enabler of DevOps, Continuous Delivery supports automation of software development, testing and deployment which are in turn supported by agile planning and execution tools.

In an article by Madison Martin, published recently in SD Times, the impact that DevOps and Agile are having on application lifecycle management (ALM). She states that “Those looking to refine their application life cycle are sifting through the marketplace to find the right tool—one that will give their company agile feature functionality and help them move toward a more continuous way of working. A business can no longer look at just the planning and the building of software; they have to monitor every step in between to make sure the software delivered meets the expectations of the user.”

ALM is accepted as the management of end to end software development and as a business process it promises benefits in terms of increased project success rates, improved quality of deliverables and reduced development timescales. Due to the absence of a common industry standard, ALM deployment is interpreted differently by different stakeholders.

The ALM tools market has seen a continuous evolution over the greater part of the last decade. The change is demonstrated by various benchmarks conducted by Gartner. As recently as July 2016 Gartner has announced their decision to retire “the ADLM MQ and focus on a new MQ for Agile planning and execution tools.” The leading reason cited for this decision is “Shifts in the market due to DevOps.”

Between 2012 and 2013 Gartner blogged that work had begun on the update to the Magic Quadrant for ALM stating “We are subtly shifting our terminology for the market from Application Lifecycle Management to Application Development Lifecycle Management. We feel this is a more accurate depiction of what the tools in this space are focused on.”

In 2008 Gartner published the “Marketscope for Application Lifecycle Management”. This document was described ALM as the practices, processes and tools that aid in the application management lifecycle, specifically the workflow of producing or maintaining an application. This document identified a number of key capabilities that an ALM offering should include. These capabilities have been listed later in this document.

Sparx Systems ALM

In 2015 Sparx Systems was named in the 2015 SD Times 100 for its excellence in the ALM and Development Tools category. When using separate tools in development, there can be a lack of integration between the tools used in each phase of the process and due to the absence of a common industry standard, ALM deployment is interpreted differently by different stakeholders.

However, when using Enterprise Architect, an integration of all the key features of ALM is provided in an “out of the box” tool set, which uses a single repository as the common data source. Within the integrated Enterprise Architect project workspace, you can view and update artifacts with version control, code review, and continuous integration tools. This is the level of functionality that defines Enterprise Architect as a leading ALM solution.

Key ALM Capabilities

• Requirements definition and management
• Change and configuration management
• Agile project planning
• Work item management
• Quality management, including defect management
• Reporting
• Workflow
• Integration to version management
• Support for wikis and collaboration
• Integration to other ALM tools

This is the first of a series of related articles on DevOps and ALM