home of Why Xumda?
Xumda is a significantly different way to plan and produce systems. It represents what might just be a fundamental change in the software profession.
The Challenges
Get It Right
For many organizations, the analysis process is long, costly, and disappointing. The people with the requirements don't understand all the consequences of those requirements. Often they have conflicting requirements. It's hard to get the facts and even harder to be sure they're right.
Get It All
Schedule pressures and a mistaken notion that “analysis is high-level and design is detailed” lead to developers having to start with incomplete information and to fill in the gaps as they’re building the software.
Get it Now
Hand-coding means that developers effectively have to re-enter and then coordinate the same information in several different places. Not only does this have the potential to introduce errors, it can also obscure analysis errors. The analysis information quickly gets out-of-sync with the actual system code. Changes for any reason are difficult and costly.
Raising the Level of Abstraction
Over the years the most profound changes in our industry have occurred when programming moves closer to the problem itself. We call this “raising the level of abstraction.” From plugboards to assembly code to 3GLs to models, each rise in the level of abstraction improves the way we partition a problem, organize the project, code the components, and combine those components into a system.
Executable models are the next level of abstraction. But they are far more than just a higher-level graphical programming language. An executable model completely specifies the semantics of a problem in the language of the problem, but is devoid of many of the elements we normally associate with programming.
Diagrammatic representations are widely used in the planning and design of software systems. But in many cases, these are merely high-level and advisory sketches.
True models, on the other hand, are more than just pretty pictures. They have defined semantics, meaning that every element has a very specific meaning.
Executable models mean more effective analysis. A sketch can illustrate a point and developing a sketch can help to think about a problem. But complete models can help you to think more completely with less heft and more meaning than text documents.
Model Compilers are highly configurable tools that turn executable models into software systems. But unlike the old one-size-fits-all visual modeling tools of the past, there are many different model compilers for different system architectures. Model compilers do not just produce code frameworks; they produce complete running systems.
Executable models and model compilers have been used successfully on software systems large and small and in applications as diverse as loan origination and hand-held medical devices.
Executable models give everyone—customers, analysts, developers, and project managers—a common vocabulary and way of thinking about the problem. When you streamline the language, you streamline the communication. Everyone becomes more effective.
Clearer Path from Concept to Code
Once you have models, what do you do with them?
If you’re like most groups, you print out the models, give the printed models to the developers, and the developers write the code by elaborating—adding detail to—the models.
And therein lays the problem.
In business, the analogy would be printing out customer orders from the order entry system just to re-enter them in the inventory and shipping systems.
But in software development, this happens all the time.
Once information is in a machine representation, we shouldn’t have to print it out only to re-enter the same information in a different form.
This sort of rework is not only rather inefficient; it introduces developer errors and obscures analyst errors. The analysts aren’t really required to produce complete and consistent models. The developers aren’t just adding platform detail to the models; they‘re changing them as well. The developers wind up completing the analysis by coding. Traceability is lost.
A bad sketch can always be coded into a good system. A bad model will execute badly. Developing executable models requires moving more formality and rigor back into the process. That’s a good thing. The formal treatment of the application is done by people who actually know the business rules.
Faster, Cheaper, Better
Of course, before you adopt new technologies and processes, you need to know how they will benefit your business, what the initial startup costs will be, and how long it will take for you to see the benefits of the new development approaches.
In today’s intensively competitive world, complex systems need to be developed quickly. Incremental model-based development produces real working systems right away. When the models are the code, there’s no waiting around for long analysis–design–code–cycles.
Conventional wisdom states that it is cheaper to catch an error in design than in deployment. Executable models, because they are verifiable, can be tested directly to provide immediate feedback and to catch analysis errors and omissions much earlier.
The process of creating executable models yields a very thorough analysis. But analysis paralysis can be avoided by taking an incremental approach. Model the most important features, compile the models into a working system, and deliver that system into the business. Develop incrementally, continually test and verify, and build only what you need when you need it.
We’ve found in practice that deploying a system, however small, changes the game. Features originally thought to be essential are relegated to less importance, while the business chooses to capitalize on some other innovation introduced by the new system.
Model compilers automate the process of transforming models into working systems. Such immediate turnaround means that systems can truly be developed incrementally. The model compilers themselves can be modified to incorporate new technologies, software architectures, and performance improvements. Change is expected; it is no longer something to be feared and avoided. Such responsiveness to the needs of the business means that systems deliver the essentials and avoid adding unneeded features.
So we can build better systems, but will the change be good for the bottom line?
Get into model-driven development as a long-term commitment. There is a significant initial investment: the cost of training, the cost of tools, and the cost of buying, building, and adapting model compilers. For instance, it takes about three weeks of training and intense mentoring for a team to learn how to model effectively. A software architecture assessment takes about as long. Real proficiency and independence requires several project cycles.
But over time, the early verification of executable models, the reuse introduced by an aspect-oriented approach, and the regularity and consistency of compiled executable models will begin to yield real benefits in the form of lower costs and shorter times-to-market.
Benefits
Xumda is the smartest path from concept to code, period.
It is precise...
Plain text is notoriously ambiguous. The Xumda models are written in a succinct graphical notation based upon a well-defined set of rules that enable a modeler to capture a lot of information, unambiguously, in a very small space.
It is collaborative…
Modeling with Xumda enables all members of a project team to develop and share a common understanding of business and system requirements.
It is agile…
The Xumda Method is truly iterative and incremental with a tolerance for incompleteness but an intolerance of sloppiness.
It is responsive…
Using tooling
to transform models into executable code, the chance of
interpretation and translation errors is reduced, and the coding
phase is shortened. It's simply easier and faster to make changes.
It is formal…
The models are based upon a uniform set of semantics that are formally defined with a meta-model. In short, Xumda is modeled with Xumda.
It is manageable…
Xumda provides extensive lifecycle coverage with specific, well-defined transitions between the traditional analysis, design, and implementation phases. (There are no “fuzzy gray areas.”)
It just makes sense
Forget binderware and dead-end deliverables. The Xumda Method is
all about capturing the right relevant information at the right time
in the most succinct and precise ways possible.