xM
Exploratory Modelling is acronym-ed as xM, and the parallel with xP (eXtreme Programming) is not accidental: in a highly interactive development environment this modelling approach does for modelling what xP does for programming: it does away with procedures, documentation, or any activity that does not directly and visibly contribute to the end result. Moreover it cannot properly be categorised as modelling since the end result or deliverable of the xM effort is a running, executable software program. However, for the purpose of categorisation, but especially regarding the place of xM in the solution-realisation cycle, it can best be categorised as a modelling activity.
It empowers the development of Domain Specific Languages (DSL), and thus can be viewed as a DSL of DSL’s.
Xm is truly instance based programming, since the actual business experts or domain experts, facilitated by an xM moderator who directly incorporates the results of the ongoing discussion into software objects, play around with objects. These are actual instances of classes with the behaviour and state that was deemed relevant for them.
It is a perfect example of what Adele Goldberg referred to as “robust prototyping”. The modelling effort seamlessly results in running, validated business models.
Xm is very well suited for DDD (Domain Driven Design) since it is well suited for business models but less well suited for the technological layers which are also necessary in deployed customer solutions.
You can read other articles on this site about how to couple the domain with the technology components .
xM can be done in many environments/tools, with some essential functionality to facilitate the sessions, but the Smalltalk development environments are exceedingly well suited. We have used Naked Objects successfully as well, especially in projects that are strongly data-driven and rely on user interfaces that are form-oriented.
Sessions start by exploring the desired end result or goal of a typical use of the system, or preferably of the business that we are building a business model for. An example can be an insurance product: the goal is that this product is purchased by a customer. The first step might be to create an actual, visible instance of InsuranceProduct. The modelling team will see this object on the screen, and it may be adorned with an icon to designate as an insurance product. Also this object will typically stay alive during many modelling sessions, not just this one. It will grow, accumulate all kinds of different objects around it to extend its functionality and to complete the vision of the business about its business domain. This is an application of the Time Inversion Pattern.
The unfolding model is a living persistent entity, which will be enhanced in each subsequent modelling session.
At closing a modelling session the complete state is frozen to be unfrozen at the start of the next session.
These objects must be created on the fly, modified on the fly, and open to any kind of transformation or even morphed into totally different objects or classes, so the system needs to be extremely dynamic. We have worked with other environments (Java Eclipse, Microsoft VisualStudio) and from these experiences we know that xM is possible in these environments. However the Smalltalk environment and language has proven to be vastly superior in the context of these modelling sessions.
Since we categorise these sessions as modelling sessions, in spite of the fact that the result is an executable running application (albeit only for the business domain component), it has been necessary to deliver the modelling results to projects that need to implement it in any other environment. For this we have used a transformation engine that exports the system to XMI, which is used to generate C# or Java code for the domain model. This way other target platforms can easily be supported as well.
However nothing would prevent you from employing the Smalltalk classes built during the modelling sessions to implement a complete solution in Smalltalk itself, resulting in an executable component (one or more running Smalltalk images containing the business domain components). We have not yet had the opportunity to try this in any of our projects, but in a world where everything is easier to interoperate with web services, this seems to be a viable and probably very cost-effective solution.
Also, on the interoperability aspect, we made extensive use of creating many business objects from existing business data, by importing them and transforming them from Microsoft Access databases, SQL Server and others. Especially for business experts, who constitute these modelling teams, this creates a realistic and familiar environment. The goal of the simulated world is to be an accurate representation of the business domain.
An interesting aspect of the application of this modelling technique is the feedback from customers who participated as business experts in these sessions. They were exceedingly enthusiastic, showed no noticeable discomfort to work in an environment that was originally meant to be used only by software developers (although some tricks were applied to hide some of the programming language from them), and felt the exercise to be extremely productive.
Curious whether xM might help you improve your requirements engineering process? Dealing with a complex business domain? Contact me, I think I can help!
For a more extensive article on xM, please go to: eXploratory Modelling Explained.
