Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What is Agile MDA?
To some, the notion of putting "agile" and "modeling" in the same sentence makes no sense. The modelers worry that "agile" is a synonym for "hacker" in its most pejorative sense, while the agilists see lumbering heavyweight processes (and quite possibly lumbering heavyweight methodologists) that deliver the wrong system late at great expense.
One reason for the disconnect is the recognition of the verification gap. This gap comes about when we write documents that cannot execute. Certainly, we can review them and draw conclusions about their correctness, but until we have something that runs we cannot know for a fact that they really do exactly what is needed. In addition, in the time it takes to deliver a solution, the market and the technology have moved on, making the delivered system, even if it is correct, irrelevant. Worse, some systems are "wicked," in that the existence of a solution changes the (perception of the) problem, which makes a complete and detailed specification document somewhat futile.
Agile methods propose to address these problems by delivering small slices of working code as soon as possible. This working functionality is immediately useful to the customer, and it can be interacted with, possibly improving understanding of the system that needs to be built. As these delivery cycles can be short (a week or two), the systems' development process is able to adapt to changing conditions and deliver just what the customer wants.
To increase customer involvement, agile processes encourage customer participation even while programming, but no one suggests they help write assembly code for it is at too low a level of abstraction. Of course, customers aren't stupid: they certainly could learn assembly code, but they wouldn't (and shouldn't) want to, because this language is alien to their concerns, involving register allocation and heap management, and all sorts of interesting tricks far removed from banking, telephony, a copier, or whatever the customer's application is.
Java, Smalltalk, and C++ are higher level, but they still call for consideration of concepts of no interest to a customer: list structure, distribution strategies, the niceties of remote procedure calls and so on. To eliminate the verification gap and enable immediate delivery of fragments of the system, what we need is a highly abstract modeling language that can more readily represent the content of interest to the customer, and yet is concrete enough to enable a modeler to specify an executable model. Such an executable model is at a higher level of language abstraction than Java and Smalltalk, just as Java and Smalltalk are at a higher level of abstraction than C or assembly code.
Executable models are neither sketches nor blueprints; as their name suggests, executable models run. This fact eliminates the verification gap, and allows us to deliver a running system in small increments in direct communication with customers. In this sense, executable models act just like code, though they provide the ability to interact better with the customer because the language's higher level of abstraction is closer to the customer's concerns. The executable model is independent of the software platforms that dominate development today; thus, in the parlance of MDA, it is a Platform-Independent Model (PIM).