Application Development : In Defense of UML, RUP

“Heavy” or not, a good methodology can be the key to success for a project. But using it properly requires practice, understanding, and communication.

Most technologists who build enterprise-wide business systems would agree that one of the hardest, yet most important, parts of the job is the task of gaining an understanding of business requirements. Translating requirements into design artifacts useful for implementing systems is an art as well as a science, and implementing business systems is as much about communication as it is about technology. Using Unified Modeling Language (UML) in conjunction with Rational Unified Process (RUP) provides more than enough guidance. However, like any language or methodology, it requires commitment and practice. Methodology as Foundation The seasoned architect looks at a project from a holistic perspective and tends to minimize the technical challenges while maximizing the other issues: unrealistic deadlines, weak project management, poorly written requirements, and so on. After all, in most business-systems projects, the technical architecture is usually well-known and documented. However, the lack of a realistic project plan or methodology can really doom a project. Take, for example, a recent project in which I was involved as the architect. Since the project was making the transition from the requirements phase to design, I was initially involved with resolving requirements and assisting management in its effort to estimate project timelines and associated resource loading. At a meeting with company management, we discussed the complexity of the project and our expectations for when it might be completed. Yes, the project was complex, but the only artifact we could really point to was the functional design document. We really had no technical plan that would demonstrate complexity, so we were, essentially, in a defenseless position. After the meeting, I marshaled the senior technical people in an attempt to create a detailed plan using a bottom-up approach. Although they really didn’t feel that this was part of their job, good architects know that building a software system is not just about using design patterns and writing code. A useful, detailed plan and methodology organizes tasks as well as task responsibilities in a logical sequence. Moreover, a detailed plan can provide sizing information that will help answer the paramount concern of management: How long is it going to take? The project plan we developed was for an enterprise-grade J2EE project for which we would loosely follow the four phases of RUP: inception, elaboration, construction, and transition. Not Heavy, But Solid RUP has a reputation for being a “heavy” methodology that requires a solid understanding of UML, which is why so many organizations find ways to avoid it. However, not having a plan or a methodology is not just unprofessional—it’s plain foolish. I have worked with quite a few methodologies, from Coopers & Lybrand’s Summit S and D to CSC’s Catalyst. They too were heavy, but when they were used appropriately, I always found they contributed significantly to project success. The main problem with methodologies is that organizations don’t embrace them. They don’t work with them enough or give them enough time to hit their stride within the development group. As an organization gains expertise, it learns the tricks of the trade and when and where shortcuts can be taken. In my opinion, reactionary organizations that do not take project management seriously never really know the complexity or size of a project until it is under way. These types of organizations tend to add resources in a just-in-time fashion, and those resources are perpetually in a “hover” position, since management doesn’t really know how long the project will take or how to size it. Project Approach and Methodology RUP is a powerful methodology and useful for most object-oriented business systems projects, but I believe you need to level it for the type of project and complexity you are facing. The venerable Summit, from Coopers & Lybrand, incorporated a useful concept called “route mapping,” in which, depending on certain project characteristics such as whether the application being implemented was targeted for a mainframe or a PC, certain artifacts or tasks could be optional. The basic methodology stayed intact, although it could be tailored to the unique needs of the project. In effect, RUP can be used in the same way. Some functionality may need only a simple high-level UML sequence diagram and no view of participating classes (VOPC). Other projects with more complex workflows might need state-transition diagrams. However, it is my understanding that RUP has never adopted a “route mapping” concept, so Activity, Sequence, Class, State, Transition, and the like seem to be necessary for all functionality. Agile is another example of a methodology that uses the concept of route mapping. One of the fundamental ideas of eXtreme Programming (XP) is that there is no process that fits every situation, so the relevant tasks for each type of project need to be tailored to its individual needs. Route maps can be used in order to determine which structured method fragments should be used for a particular project. Object-oriented purists might say that not exercising all artifacts is a bastardization of the methodology and not what its authors intended. That is, that all use cases should be realized in the form of sequence diagrams; and that sequence diagrams should be used to drive out class behavior; and that all sequence diagrams should have a VOPC, etc. I don’t agree with that, either. Mindlessly following RUP as a cookbook is exactly what has given it a less than stellar reputation and contributed to its reputation as being heavy. I believe that, given the limited time project managers usually allot for design, choosing design artifacts that will have the most impact is the best approach. In any case, a certain amount of methodology—and not just a veneer of methodology—is better than none at all. Design Artifacts I have found that even a basic set of sequence diagrams with well-defined method signatures can go a long way toward clarifying design. Take an application that imports an Excel file, parses the data in the incoming spreadsheet, persists the data to a database management system, and then asynchronously notifies Java Message Service (JMS) that there is a batch to be processed. (See Fig. 1.) In a typical project, several resources would be needed to realize the implementation of the design; the model is the first step in the collaboration effort. On large teams, the consumers of UML artifacts are, for the most part, other team members. However, don’t make the mistake of thinking that UML is truly a universal language, as the name implies, and that all technologists have embraced it. Offshoring projects that rely on UML as the lingua franca assume that the human resources they’re communicating with have an understanding of UML. Not true. Today’s software development teams tend to be very eclectic, whereas resources can be language-challenged. On one recent project, I naively thought that if I created UML artifacts I would overcome the native language weakness with a common language construct (that is, the Unified Modeling Language). However, UML still requires an understanding of language, as well as rigorous conceptual skills that need to be learned over time. In the end, it took brute force to complete the project, since no one on the team really understood the artifacts. I would recommend interviewing project resources on their UML fundamentals or, better yet, have them create a design for you. Recently I spoke with a project manager who observed that design was useful mainly for communication among project participants. While that is most definitely true, I take umbrage at the idea that design is useful only for that purpose. That type of attitude toward design relegates it to an activity that you perform in preparation for offshoring the implementation. At best, a good design artifact can allow for what NASA calls static design testing, where the design is robust enough to test prior to construction. At a minimum, a view of the system as a well-defined set of objects can provide scope and responsibility for application components to be implemented. In my opinion, UML is a good notation for getting ideas out of your head and down on paper in an organized manner. The process of committing your ideas to paper or a design tool is very much a part of the design process. For example, constructs that might appear simple at first may turn out to be complex, and vice versa. Many projects go wrong because of the belief that a UML tool can emit a design through the XML Metadata Interchange (XMI) interface, and that the exported design can be used directly as working code. XMI is an Object Management Group (OMG) standard for exchanging metadata information via eXtensible Markup Language (XML). It can be used for any metadata whose meta-model can be expressed in Meta-Object Facility (MOF). The most common use of XMI is as an interchange format for UML models, though it can also be used for the serialization of models of other languages. Not that this isn’t achievable or that object prototypes can’t be emitted from a tool; many tools, such as IBM’s Rational XDE or realMethods, are capable of forward and reverse engineering. It is the typical developer’s lack of experience that is really the weak link: the promise or expectation of generating working code directly from a design artifact is usually more than they can deliver. A successful design phase should not be measured by the amount of code generated from the design tool. Bottom-Up Project Planning Let’s go back now to my recent project. Several days were spent creating a detailed plan that embodied our approach, describing the tasks involved along with some concept of the resources necessary. That plan was then passed on to the project manager. The technical team now felt comfortable about the scope of the project, and we felt more prepared for our second meeting with management. We now believed we had a defensible position that was substantiated by a realistic plan. About halfway through the design phase, however, a project manager came on board and recommended that we use the Agile methodology. Forgive a digression, but it appears to me that the main reason Agile is compelling to management is its stark simplicity. Essentially, it uses only a handful of operative words: iteration, scrum, dynamic method adaptation, and a few others, and it is now being extolled as being analogous to the way software was written in the past. As an object-oriented technologist, I have no interest in returning to the languages of the past, such as Assembler or FORTRAN, so I don’t really identify with this statement. Basically, we created scrums and iterations from the existing project plan. (Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices.) Since some of the designs were complete, we then initiated full lifecycle iterations: that is, design to code complete. The early iterations went fairly well, which seemed to corroborate the success and usefulness of the methodology. I was assured early on during the effort that for subsequent iterations we would complete the design first; however, that never happened. We ended up completing the design the old-fashioned way, by having ad hoc whiteboard discussions of the object interaction and workflow behavior. I also found that the concept of moving back and forth between design and coding is somewhat awkward. Design time is when you get away from computers, to a degree, and conceptually create the proposed system. In fact, being encumbered by the immediate implementation (e.g. Java, C++, etc.) can destroy creative forward engineering. Additionally, not having an end-to-end complete design can result in inconsistent applications; the design “model” needs to be completed as a single body of work, not something that can be incrementally carved up into iterations. In reality, some organizations mistake activity, in particular coding, for progress; time spent actually designing is simply not appreciated. Implications Today’s technologists are more interested in learning implementation than in learning design. I further submit that with the advent of anti-methodologies, such as Agile, the design ineptness of software development organizations has been further exacerbated—not remedied. Although I truly believe that the best designers understand implementation as well as design, it is their ability to negotiate the feedback loop between design and implementation that results in the most effective approach to software development. As my statistics professor cautioned at the university, a little bit of statistics is a dangerous thing. The same can be said about methodology.