Model-driven engineering
Optional reading, but this is how we do some of our development.
We don't talk so much about this any more, but it is true... NexJ uses model-driven engineering to improve enterprise software design, quality, organizational scalability, and productivity. What does this mean? Teams can model their entire enterprise environment with standard UML tools while actually building deployable business solutions. It allows designers to focus on what is important by separating functional and technical complexity. Other benefits include rapid prototyping, more refined designs, improved maintainability ... and it scales.
Model-driven engineering solves the problem of a solution implementation drifting away from its design. It allows for direct deployment and execution of the model, without intervening code development effort. With model-driven engineering, the design is the code. Model-driven engineering and model-driven design are practices that use abstract representations of the knowledge and activities that govern a particular application domain to create software applications. Often, UML is used as a tool for capturing and communicating the project requirements and expectations to all involved parties. This allows designers to focus on the business problems, while developers focus on implementation details.
In model-driven design, after the models are agreed to, the task of solving the technical complexities is passed to a development team who works to implement the agreed-to model. In the process of solving those complexities, problems may arise as the solution drifts from the original vision of the model.
NexJ applications make use of comprehensive model-driven engineering across all application layers, simultaneously capturing and implementing the application design.
We use this to aggregate data from multiple back office systems into a common business model on the server through an abstracted data layer. Services are defined against the common business model to automate business processes and enable cross-functional workflows across backend systems. Those services are then exposed to users through the portal components via desktop and mobile devices, or to developers and systems via service interfaces using a variety of protocols including XML/SOAP/JSON/REST.
The architecture separates each set of related modeling considerations into its own distinct layer. These layers are inter-related, but functionally independent. The separation into layers allows development teams to efficiently focus their attention and skills on the dimension of the application under consideration at a given time.
Models in this architecture are stored as a collection of XML files. These files are then visualized through editors using NexJ’s development environment, NexJ Studio. For example, properties of business model classes can be edited and viewed in the class editor or through interactive UML diagrams.
Why do it this way?
Traditionally, Product Management's design vision is recorded in a functional / technical design. This document may contain requirements, concepts and class diagrams, process flows, screen designs, report designs, business rules, database schema, and more. The design is given to Quality Assurance (QA) to start working on test plans; and to Development to build the application. The application is released when QA agrees that what Development has built is close enough to Product Management's vision and of sufficient quality. The problem is that even on the first day, the design document is an approximation of what is really in production. It then gets further out of sync with every patch or enhancement made. Additionally, some of the designers or developers move on. When it comes time to do the next big system change, it is a major effort to dust-off the documentation, verify it against production and understand where to start and how to avoid side effects. With MODL, the design is the application, so you always know what is in production and your investment is protected over time from changes in technology.