Rational Rose

Requirement Management tools will increase requirements definition phase by:

providing more administrative functions for BA's

overcomplicating the simple analyst activities (Adam & eve stages of scratching around drawing models)

creates more documents

decreases productivity with unnecessary system burdens

employing a very user unfriendly interface for end users

irritating to use, very idiosyncratic

Other points: Respected industry professionals steer clear of these tools (such as Craig Larman)

Software development is not predictive manufacturing but new product development, therefore re-use at best is negligible

Low tech tools such as paper and pens are faster, easy to use and can be performed anywhere

BA's typically talk, workshop and write up requirements, therefore MS Word is perfect for this

Customers buy working software, not glossy specs or models

Facilitates documentation development, not software development!

Software development is about great people working close, not great tools working for "me".

In the wash up it won't improve software end products for customers. People and OO training do!

Creates: beaurocratic steps just to set up and maintain documents

has many unnecessary "add ins" such as advanced traceability and version control.

most source code it generates is unusable

Cons: Doesn't control scope, just creates more hurdles to document and maintain scope

Are over-priced drawing tools with sub standard workflow

Is incredibly expensive per staff head

Conflicts with many departments use of a document repository

Description: Rational Rose is a UML-based CASE tool. It a tool to help with the RationalUnifiedProcess. It is made by the RationalCompany. More information at http://www.rational.com

ArgoUml is an OpenSource alternative.

(I just attempted some RationalRoseRefactoring -- DavidSaff)

Question: I've just started using Rose and it feels like it gets in the way much more than it helps. Does anyone have any positive experiences that I can use to sooth my frustration? -- Anon.

Bad Experience: Maybe the problem isn't Rose, but UML. I came into a project that was using UML for its initial architecture, with all the properties one finds in a MasterPlan. It proved to be a great way to codify inaccurate information with great precision. We re-did the design using CrcCards and coded from them. It was a small project: about 6 people and a few tens of thousands of lines of code.

Maybe Rose and UML are good for drawing AsBuilts, but even the value of that would seem to depend on a misplaced assumption that software is at some time Done. -- JimCoplien

Bad experience: I don't think Rose was a better tool before UML; as a CASE tool it always seemed to me to leave a lot to be desired. PeterCoad's TogetherSoft Tools strike me a lot better, but really the benefit these add isn't a lot more than you'd get from a browser like Cygnus's mostly-free SourceNavigator.

The whole full-cycle engineering malarkey that the UmlCaseVultures push never works; perhaps if one of these tools was able to reverse-engineer library/builtin types into stereotypes you might still be able to see the design in there somewhere, but seeing they don't all you get from reverse-engineering is an impenetrable mess.

As to code-generation, perhaps you really do want to have a tool to generate data members and accessors for you if you do a lot of BigDesignUpFront. But if you have an ounce of sense you won't want to do such a thing, and then code-generation becomes nonsense. You'd do much better to invest a few days of your time in familiarizing yourself with a decent text editor - vim or emacs - than to shell out for member/accessor generation.

Now Rose is trying to add value by integrating with every other build tool under the sun. Perhaps you need this integration ... but I like simple tools that do well-defined jobs in a flexible way rather than lumping megalithic tools that do things just one way and no other way.

So I think it's best to regard things like Rose as drawing tools - and shell out for them only when they price the same as drawing tools. --PeterMerel

Commentary: Right -- the drawing tool angle is a different slant on what I was trying to say. I think most CASE tools suffer from AlbertisLaw.

Question: Thanks. I'm also interested in experiences with code-generation from Rose. Particularly when it becomes a project convention that all classes are created and managed through the tool. Right now, it seems hairy, indirect, and unnatural. -- Anon.

Alternative: While I'm an admirer of XP/CRC, I too use diagrams generated by a UML tool, preferably PeterCoad's TogetherTools. I find the diagrams useful both for pedagogy and for refactoring. But I don't maintain them; I draw little ones and then throw them away afterwards. I suspect that even with XP I'll be drawing diagrams occasionally. But I'm very much of the opinion that BigModelsAreUseless. --PeterMerel.

Bad experience: My first use of ROSE in anger was a real eye-opener. From a very simple model (which ROSE's reporting said was valid) it generated code nowhere near to compiling. This was to C++. A great deal of fiddling is required to make it do anything sensible.

These days I try to only use Rose when required, and only to produce throw away UML diagrams as Peter describes above. I wouldn't touch RoundTripEngineering with a barge-pole. --KeithBraithwaite

Good experience: I have used Rose for about four years, and I really like it, with certain caveats. It is very easy to just "whip out" a diagram expressing certain fundamental truths about a big design. It is also very easy to change a design -- one can do so at the design stage without having to worry so much about introducing bugs in the code, which means that many more designs can be considered (in their full implications) before actually producing code. I have found that my development cycle with Rational Rose tends to work out to something like: two months to design (thinking time is part of this, this is not all done using the CASE tool), one week to implement. (By the time I actually get down to implementing the code, I know exactly what each piece will do, so I can write code as fast as I can type.) When the implementation is that quick, it is rather easy to change the design substantially and just reimplement the affected parts, tweak the unit tests a bit, and re-run them, so refactoring is quite easy.

By far, the most valuable part of the Rose model is the ability to have it produce design documentation which can be reviewed by other software engineers. It is much easier to fix design defects which are discovered in a Rose Model than it is to fix them once they have been implemented in code (without a Rose Model), because the changes can be automatically propagated to wherever they need to go.

As much as possible, I try to avoid introducing redundancy between my code and my Rose model. For instance, I never modify method and/or class comments or signatures in code -- I always modify them in the Rose model, regenerate the code, and then cut-and-paste it into the existing (modified) code (either manually or using a Perl script of mine to do it automatically).

On the other hand, Rose's code generation and code reverse engineering are both rather poor, IMHO, and tend to litter your code with extra comments that make it harder to read. I am currently doing code generation (in Java) with a modified version of a RoseBasic script that was created by a third party, and which I pulled off of Rational's website. This gives me more control over the code generation process. (I see little value in doing reverse engineering, except to import a new model into code. Reverse engineering implies that I have been doing work in text files, where working is inefficient, instead of in Rose, where working is efficient, and where I can use automatic scripts to detect errors without having to search for them by hand.)

In any case, Rose forces me to write far more RoseBasic scripts than I would like -- I think that it should be capable of, for instance, automatically detecting that in Java I can't inherit from two classes at the same time. Still, I like the tool, and nowadays, I feel unprepared when I don't have at least some kind of UML CASE tool available for my use. Coding by hand seems so error-prone and wasteful (modifying large areas of source code to introduce relatively simple design changes takes so much TIME) that I really find myself avoiding it.

--DerekFoster?

Commentary: See my comment in IdealUmlCaseTool

DougSerres

Bad experience: In a previous life (fall 1998), I took RationalRose training. While our RationalRose instructor was struggling through a reverse-engineering example in C++, I was trying to follow along with a Java example. When I tried to reverse engineer my Java code, RationalRose put up a dialog saying something like "Error occurred: %s". Yes, there really was a "%s" in the dialog -- how'd that slip through QA?

Disgusted, I gave up on Rose. While the instructor struggled to get RationalRose to reverse engineer the contrived example in the course materials, I downloaded and installed TogetherJava, and finished reverse engineering my Java example before the instructor. In fact, my friend sitting next to me saw what I did, and proceeded to download TogetherCeePlusPlus, and reverse engineer the C++ example we were going over in class. He also finished before the instructor.

-- JohnBrewer

Bad experience: I'm a very firm believer in high level visible technical documentation -- like UML diagrams. But I found Rose's ability to reverse engineer and regenerate C++ limited -- unless you're willing to spend a few weeks making your code conform to its limited understanding of C++. -- JeffGrigg

Commentary: (All tools in the marketplace have similar limitations: The problem is that CaseToolVultures? salesmen give top management the impression that the tools will do everything -- any problems must be because your people are stupid.)

Good experience: I have been using Rose in all C++ projects for 3+ years and have recently started using it for Java. I use Rose throughout the life-cycle of the project including code generation (and maintenance). If you want to do this you will have to accept some basic constraints.

Reverse engineering will not work to your liking, edit the model and regenerate instead.
Leave the code markers. Rose needs these to regenerate over existing code. Similarly only make edits between preserve=yes blocks.

If you are unwilling to do this (and I was at first too), then Rational is only useful for drawing pictures. Visio is better at that, and there are free tools that are configured for UML, but have bad/no code generation. I have tried to use Together, but found it slow, buggy, and had trouble bringing in my existing code base. I will be evaluating ilogix soon (http://www.ilogix.com/modeler)-- they claim to be able to read Rose models.

--LouFranco

Bad experience: I can see how you may be able to use Rose as a forward engineering tool but we bought it only to reverse engineer our code and generate a few throw-away diagrams. I've given up on that because the drawing tools, formatting and printing are just so unbelievably pathetic. Who wrote this crap? Maybe they used Rose to write Rose, that would explain it.

--Andrew Queisser

Good experience: If you buy into the idea of OO modeling in general, and the UML in particular, then you've probably got some nontrivial problems to solve (as I have had). Big models are just inherent to some solutions, though big model diagrams can sure be useless, and a sign of excessive coupling.

Rational Rose has been good for me because

it performance-scales to very large models (e.g. IbmSanFrancisco) where other tools do not (a benefit of its having been around a long while, for sure)
its drawing functionality is fast and stable, where that of other is not
it exposes the underlying metamodel through its built-in script

I have not used its reverse-engineering features, nor its built-in forward-engineering ones. Writing in RoseScript is godawful, so I wrote just one script that writes the model out as a Java metamodel instance, enabling all other tools to be written in Java, principally code and documentation generators.

I've used this arrangement on some complex business object design models. Business logic methods must still be handwritten, but all business state code can be generated for the component model of implementation. So for BO systems, at least, using Rose allows me spend most of my time operating at the design-level, since much of the design implementation work is automated.

--PerisBrodsky

Mixed Experience- As a tool Rose is OK. I agree the interface is a bit clunky and you can do most things in Visio. It is really useful in conveying ideas to other people. Reverse engineering cannot be done on auto-pilot and no case tool can work backwards from umpteen generations of bad code and make it better. The analyst, or whatever title you wish, must decide what the design and function of the old code was, whether it performed as designed or not. Unless we have made great strides in AI, I don't believe we can do it. We are still in the Stone Age. Case tools are not auto-doctors or magic wands.

The practical end of this business requires us to write two models. The BIG model which makes the customer, who cannot understand a words that are coming out of our mouths(sorry Chris Tucker), comfortable spending their money and the SMALL model which in a sense is more of a philosophy or protocol. The BIG model is supposed to be very complicated and incomprehensible so the manager types can say "Wow, I have a really complex system!" and have bragging rights in the executive washroom. Most projects I have been on (too many to count) get into trouble because every new person tries to adapt the design the way they see fit. This leads to a hodgepodge of styles and inevitably a maintenance nightmare. Nobody pays attention to standards. So instead of trying to enforce conformity and order on the universe we need to come up with a way to deal with software entropy (as the project progresses the code gets more disordered).

I am waiting for the big black monolith to land and show me the way.

--MarkSpanglet

PS. It is now 3 years later and not much has changed. UML is still a language people refuse to learn and most who learn it abuse it. Just because you can draw an impossible scenario does not mean you can build it. (see Escher). IBM's aquisition of Rational has not helped much, but the XDE is much improved over the original interface. Is the medium the message?

Peter - There's a message in my alphabits. It says "oooooooo". Brian - Peter, those are Cherrios.

Is it just that programmers are less disciplined than "regular", ie electrical, mechanical, chemical engineers? The latter are able to create and translate complex diagrams into implementations 1-1, and keep evolution of design and implementation in sync. It may seem easier to saw an I-beam to dimensions on a drawing than fill out the details of class diagram methods but there are many "behind the scenes" calculations for that beam ie moment of inertia etc that must match with the diagram. The machinist may scribble on the diagram in pencil and make changes, send it back to the engineer to recalculate and update AutoCad, but they all are able to keep the theory and manifestation choreographed. Why can't a programming team?

I work in an environment (building assembly lines) where mechanical, electrical and software engineering all work more or less at the same time so I have a little bit of insight into the differences between engineering disciplines. I don't want to make assumptions how other companies work but this is what I'm seeing:

Rose sucks, CAD rocks.
The end product of the ME is the document (drawing or solid model). The ME makes changes by changing the document. The programmer changes something by changing the code, updating the diagram is an afterthought.
The immediate cost of changing software is so low that programmers have less incentive to stick to the current plan. The cost of changing metal is high.

Having said that, our drawings, especially electrical drawings are never completely up to date either. There's a lot of hacking in the production phase of a mechanical design as well, especially the first instance.

--AndrewQueisser

See AsBuilt.

Bad experience: bad code generation bad, bad user interface (specially for people who are lazy to move their hands from keyboard to mouse and prefer one device browsing), limited formatting (layout) capabilities.

Good experience: You can add lot of functionality with RoseScript (if you do not have allergy to basic and co.). I mean you can add the rest of 90% of necessary functionality for quicker, better and more productive work. Also you can write scripts for intelligent formatting (Layout). But take care: try to model your scripts also. Otherwise you loose control.

I propose you to play with the word Rational Rose like as we were kids: get hold your tongue and say Rational Rose. The result is: NationalNose?, or for more novices NationalNoise?. (MihalyElekes?: after a day of working with NationalNoise?)

Bad experience: RR 2003 Enterprise couldn't distinguish between aggregation (open diamond) and aggregation by composition (closed diamond) when reverese engineering about 50 LOC ( C++ ). It was a simple implementation of the Factory Method or the Strategy Design Pattern, just to test RR. Perhaps bad luck. But really, I don't care. This shouldn't be happening. Why bother adding reverse engineering in this tool?

- Axel Bosman

Good Experience: Rational Rose is being used by a client of ours for round-trip engineering of large C++ code base. Some of the required features are supported using REI scripts. For example, verification of modeling guidelines.

- Ajith P N

CategorySoftwareTool