During software development, agile modeling practices prevent a split of focus and keeps the practitioner's mind...
clean, ready to immerse into the next work step. Agile modeling's lean approaches, representations and techniques work in everyday use without unnecessary overhead.
This tip offers tips for doing modeling well, including five best practices I've learned while externalizing some concepts first set forth in David Allen's GTD (Getting Things Done). I also cover some historical ground, looking at when and who synthesized Agile modeling practicies; such as data-congruent programming, data modeling and Unified Modeling Language (UML).
Agile modeling's balanced mix of diagrams and text or code facilitates communication with colleagues or project stakeholders. On the flip side, in modeling that doesn't use or shallowly uses lean approaches, notation bloat can occur later in projects, which started lean at first and clog up later. Perhaps that's why the software industry on average still does little 'programming in diagrams'.
Less is more in agile, so how much is good enough? IT today is nearly as mature as other industries, and GTD is as applicable here as elsewhere. Model size and detail shall allow repeated walkthroughs, updates and communication among colleagues. PC-based tools, of course, push the limits, just like in mainstream GTD, but they can't remove limits. Further automation -- code generation from UML diagrams or business process execution/simulation -- usually entails more model detail on one hand; but also a one-construct, one-representation model keeps notation bloat down.
Automation is easier if the project goes for a couple of essential diagram types only. In many apps, complete class diagrams and state diagrams -- including sent and received messages/events -- are enough to generate code. Other diagrams improve architecture, documentation, understanding, requirement communication and more, rather than code generation.
An often-overlooked GTD trick is plain encapsulation into components, web services, extended platforms, high-level LINQ functions, open-source programs and so on. Even patterns and domain-specific modeling (DSM) are close to this, but need often additional fleshing-out. Once the functionality is available and reliable, it can be used wherever needed, without modeling it anew. That functionality would be self evident, if it weren't for all the congruent structured programs (Figure 1) crammed with processing that should be, and often is, already dealt with in compilers, code generators, database engines (figure 2) or operating systems. Also, watch out for UML diagrams crammed with object interactions (fig. 3, alt. 1) that should be, and often are, already dealt with in stored SQL procedures, LINQ queries, Java Hibernate/N-Hibernate for C#., or elsewhere (fig. 3, alt. 2).
Modeler's five architectural rules of thumb
- Stay agile and remember GTD. A lean up-to-date model that is widely read and understood can add more value than an extremely-detailed one read by an expert only.
- In core object design, keep it lazy. Call neighbors for processing. Reuse before design, having the design result at "one place but good," as GTD suggests. Complexity can be encapsulated, tested, and hidden more often than we realize.
- Look at patterns and domain-specific models without becoming obsessed by them. Even where they don't make a complete fit, they can still take the work a bit of the way.
- Doubt, doubled effort and cost often come from past problems in test tools for high-level/business-level expressions and components. If this is true in your case, make them a priority early on. Find tools with good references in fault detection, test, animation of powerful declarative expressions or high-level functions, etc. Seeing visually how the component or expression executes in run time improves usability and acceptance. This is equally important in business process models.
- Establish a system boundary up front. State explicitly for each project team what they're going to design and what is not already at hand. Note that UML Use Case diagrams work fine in scoping an interactive app, but there are other techniques as well.
Let's move on now to some revelations about the evolution of agile modeling, briefly examining the histories of data-congruent programming, data modeling and UML.
In 1980, the efforts of J. D. Warnier, Ken Orr, and M. A. Jackson were finally rewarded in terms of acceptance and practical use. They established that arbitrarily-complex programs can be inferred step by step from input/output structures and modeled using three basic structural elements (sequence, iteration, selection). Their requirements launch notations that model both data structures and structured programs and design blueprints of software finally obtain some recognition.
Without the data-congruent programming structure created by Warnier, Orr and Jackson, these questions plagued development:
- How come you've no special notation for parallelism and clusters that are weak, unordered sequences?
- What about co-routines, able to resume complex processing from their recent state?
- And multiple-step input evaluation or searches, with backtracking?
- What about inter-process communication diagrams?
For data-congruent programming to work, modeling tools, code generators, test tools and training have to keep up with a number of extensions.
In 1985, work by Edgar Codd and Chris Date was extended into diagram notations plus an increasingly computing-independent view of information as a non-technical asset. Soon, the inventive ideas of Codd and Date are lost in a jungle of proprietary notations including, for example, almost 10 ways of depicting the same cardinality in a relationship. In effect, a standardized Structured Query Language Data Definition Language (SQL DDL) is "improved" by poorly standardized diagrams.
Since data models omit the dynamics of processing in business or software, good models use a mix of non-standard programming notations and equally non-standard data modeling. Whereas data redundancy drops to a minimum due to SQL and relational databases, most program libraries still remain as redundancy-prone as ever, and the imbalance persists until standardization comes from a third party, the object community.
Unified Modeling Language
The Unified Modeling Language (UML) is approved as an Object Management Group (OMG) standard in 1997, pruning a jungle of non-standard object notations. This happens thanks to the groundbreaking development work and lobbying of Grady Booch, Ivar Jacobson and James Rumbaugh.
UML models both processing and data, the object way, and brings models to a broader software community independent of domains/apps and methods. Class, sequence and state diagrams from one standard improve correctness, lead time and cooperation, as compared to proprietary data models, network diagrams -- each one trying to get out -- and Jackson or Warnier-Orr diagrams.
The UML 1.x, in general, was applied in a prevalently agile way in the beginning, stressing motivation, education, cooperation, communication and pushing aside tool and processes issues. But from there, it gradually evolves into a pretty substantial smorgasbord. The number of heavy dishes -- diagram types -- reaches 13, as some 50 companies jointly author UML 2. Lean projects still keep cherry-picking two-to-five types out of 13. Notation bloat creeps in, although within one standard under a common "grammar book" or meta model. Steps and measures back to lean are taken later by the OMG however, in the SysML standard (2006).
About the author: Milan Kratochvil is an independent advisor and trainer who focuses on software requirements, modeling, architecture, and particularly, variance, customization or configurability issues. He is the author of the books, "UML Xtra Light - How to Specify Your Software Requirements" (Cambridge) and "Growing Modular - Mass Customization of Complex Products, Services and Software" (Springer). He's been working in the software development industry for 32 years and lives near Stockholm, Sweden.