Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process is a good article about two topics - architecture in RUP and Rational's new Software Architecture tool (IRSA). While it looks long on first appearance, it's a pretty quick read because the text is illustrated with lots of screenshots on IRSA in action.

IBM Rational Software Architect
Having been involved in a RUP project that made extensive use of Rational Rose for modelling, it's great to see that IRSA implements many of the tips and techniques that Rational talk about when they teach RUP. At my last company, we worked with some really good process consultants who were experts in both RUP and Rational Rose, having consulted on and seen many projects in the past. Subsequently, they were able to provide us with guidance and advice on the best practices that they'd seen/created over the years. Specifically, this included recommendations on how to best structure your UML model in Rose around the various views, which diagrams to create, what those diagrams should be called and how make the model easily navigable. Regardless of whether you agree with RUP as a methodology, I think it's great that IRSA templates have implemented some of this best practice, gearing it much more towards using RUP in the real world. So while that's all good, there are a couple of points that I wanted to talk about.

Iterative development
One of the common misunderstandings I find when I talk to people about iterative development is that it always gets [superimposed on | mistaken for] the waterfall model. RUP, in particular, suffers from this because of it's seemingly high portion of big upfront requirements, architecture and design. I think I'll save that for another time, but Going Over the Waterfall with the RUP summarizes this problem well. So, while the article hints at iterative development and refining the artifacts throughout the project, I don't think the message is strong enough. For me, the elaboration phase of RUP is all about fleshing out the architecture, based around the architecturally significant use cases (i.e. those use cases that affect the architecture). However, rather than build up analysis and design models for all of these use cases, I'd probably just choose the main flows through them, leaving the others for another iteration, particularly if they don't affect the architecture.

Level of detail
The other point I'd like to mention is the level of detail - typically I wouldn't go down to the level that shows all attributes and methods of a class, not in the elaboration phase anyway. Ultimately, my goal would be to design and prove the architecture with code, because that's what the executable reference architecture is all about. Actually, I'm not sure I'd go down to this level of detail anyway, but then that's just because I try to take a pragmatic approach to architecture.

I've been reading Iterative and Agile Development by Craig Larman recently and something that I never really grasped is that the RUP creators never intended for RUP to be as heavy as most people make it. Similar to agile methods, there's supposed to be a feeling of "just enough" and "do it if it adds value". With this in mind, it's really easy to see how you can scale down the amount of ceremony. Some might call it agile, some might just call it pragmatic.

Anyway, if you get a spare 15 minutes I think you'll find Developing a J2EE Architecture with Rational Software Architect Using the Rational Unified Process an interesting read.

Responses[3]

Posted by Simon Brown on 25 August 2005 22:56:33 BST #