XP and UML? Clearly the Wrong Question to be Asking
- Can you use UML with XP? Yes. You can apply the artifacts of the UML – activity diagrams, class diagrams, collaboration diagrams, component diagrams, deployment diagrams, sequence diagrams, statechart diagrams, and use case diagrams – when you are taking an XP approach to development.
- How do you use UML with XP? Minimally you should apply AM’s practice of Apply the Right Artifact(s) and use UML artifacts on your XP initiative only where appropriate. Ideally you should apply all of the principles and practices of AM when doing so.
Wait a minute. One of AM’s principles is Multiple Models, which tells you that you need to have modeling skills pertaining to a wide variety of artifacts within your intellectual tool kit. Yes, the artifacts of the UML are a good start but unfortunately not enough: As I argue in the article Be Realistic About the UML the UML is not sufficient for the real-world needs of business application developers, although luckily the article Artifacts for Agile Modeling: The UML and Beyond shows we have far more than the artifacts of the UML at our disposal. Seems to me that we have a problem here. If the UML is not sufficient for the development of business applications, and if you trying to develop such an application following the XP methodology, then perhaps How do you use UML with XP? is the wrong question to be asking. One of the problems with the buzzword approach to software development is that when you limit your vocabulary to buzzwords you correspondingly limit your solution space to whatever can be described by those buzzwords. Therefore, I believe that two more questions need to be added to the buzzword approach: “Is using buzzword1 with buzzword2 the right question to be asking?” and if not “What is the right question?” When you ask these questions about XP and UML you quickly realize that the right question to be asking is more along the lines of “How do you model effectively on an XP team?” This is a question addressed by AM, and in particular the article Agile Modeling (AM) and eXtreme Programming (XP).
Another interesting question to is is whether all of the UML artifacts are appropriate for an XP team. I suspect not. User stories are an important part of XP – user stories form the foundation of the requirements for your system, they are a primary input into your team planning efforts (referred to as The Planning Game), they are the primary artifact used to define what your team will be working on in a given construction iteration, and they are used to drive the development of your acceptance test cases. The UML does not include user stories but instead describes an artifact called a Use Case Diagram that depicts the interrelationships between actors that interact with the system and use cases which describe usage-based requirements for your system. As I argue in the article Artifacts for Agile Modeling: The UML and Beyond use cases and user stories are alternatives to each other, if you are using one you very likely won’t be using another. The implication is that because user stories are an integral part of XP you clearly will not want to apply use cases, hence you will not need to create UML use case diagrams. Once again, remember to follow the AM practice Apply the Right Artifact(s).
Another interesting buzzword combination to consider is how do you use the Model Driven Architecture (MDA) approach with XP?The MDA is part of the Object Management Group (OMG)’s vision to support interoperability with specifications, defining the relationships among OMG standards (such as the UML and CORBA) and how they can be used together in a coordinated manner. The MDA defines an approach to system specification that distinguishes between platform independent models (PIMs) that specify the system in a manner that abstracts away technical details, models that are in turn realized by platform specific models (PSMs) that take into account technical considerations. The MDA also distinguishes between formal models and informal models. Formal models are based on a language, such as the UML, that has a well-defined syntax and semantics and possibly a defined way to show the validity of its constructs such as rules of analysis, inference, or proof. Informal models, as you would expect, do not have a sufficient definition behind them. The MDA requires the use of formal models and not informal ones because of its focus on specifying the interoperability between systems. In short, the MDA defines a set of guidelines for structuring system specifications expressed as formal models.
Now to my question “Can XP and the MDA be used together?” Following the strict definition of the MDA, the answer would have to be no. Models such as Class Responsibility Collaborator (CRC) cards and user stories are an integral part of the XP development process and because they are not formerly defined that academically disallows the use of MDA and XP. Practically, however, the answer may in fact be yes. The MDA is being used by CASE tool companies as a conceptual framework from which they are borrowing ideas, frankly the idea of having platform independent and platform specific models has been around for decades, and conceivably it will be common to see MDA-compliant tools just as well see UML-compliant tools today. Just like UML-compliancy is in the eye of the beholder, every CASE tool has its idiosyncratic implementation of the UML, we will also see the same thing with the MDA. Because an XP team is free to adopt any tool that it wishes, granted that it should be a tool that improves the productivity of the people using it, an XP team could in fact work with an MDA-compliant tool if the situation warrants it. Of course that MDA-compliant tool would need to automate user stories and CRC cards in such a way as to not lose the benefits that these artifacts currently provide, many of which are derived from the fact that these artifacts are created using simple tools such as index cards, leading me to suspect that in practice the answer will likely still prove to be no.