Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm looking for some guidance on CASE tools and whether my concerns are valid.

Recently I was in a meeting between my employer and an external software company which have a CASE tool currently in beta. They demonstrated this tool to us, showing how you build a UML model in Enterprise Architect (or something like it) and then, through their tool, that UML model is transformed into a Visual Studio project, with C# files, stored procedures for SQL Server, code for the data layer, WCF stuff, logging code and allsorts.

Now, admittedly, I don't see the point in this, as in I'm not convinced it will save that much time (plus it feels like overkill). The tool authors said that a trial of the tool at another company had saved a team there 5 weeks of development time (from 6 weeks down to about 1 week) using this tool. I find the accuracy of that estimate hard to believe.

My main concern is whether using this tool is going slow down my productivity. For example - Say I have a UML model which I built a VS solution from. Now, I want to rename a class method to something else; will this mean having to update the UML model first and then rebuilding the code? Is this how case tools normally work?

Something I will need to check with the authors is the structure of the generated VS solution. I like the Domain Driven Design way of project structure - Infrstructure, Services, Model, etc. I doubt very much this tool will do that.

Also, I've been playing around with Entity Framework Code First and think it's a great way to build the data model. I have nice repositories, unit of work classes and other design patterns that work well with EF. I have data anootations and stuff like that working great. By not having EF (the CASE tool uses it's own data layer code) I'm concerned that this tool's data layer code might not be a nice to integrate in the UoW pattern, repositories, etc. This I will need to verify when I get a closer look at the generated code.

What are other people's experiences with CASE tools? Am I being paranoid about nothing? Am I being unfair - are my negativities unfounded?

EDIT: I like to use TDD/BDD for building my code, and using a CASE tool looks like it will make this difficult. Again, any feedback on this would be great.

Cheers. Jas.

share|improve this question
5  
Good grief, I thought the last of the CASE tools had been staked through the heart and buried at a crossroads at midnight late last millenium. Somebody get the garlic and holy water! –  David Thornley Mar 4 '11 at 21:28
5  
I'm sure the CASE tool will save you 5 weeks of development time. It'll just also cost you 5 months of maintenance time after the fact. –  GrandmasterB Mar 4 '11 at 21:51

6 Answers 6

"CASE" is a four letter word. If you are looking for arguments against it, I recommend the first couple of chapters of Martin Fowler's UML Distilled.

I say trust your instinct on this one. The danger is that you might build a project using some monstrosity, and it becomes a maintenance nightmare.

eta: the primary reason to use CASE tools is to make communication/documentation easier*, not to save time developing the application.


*valid for some definitions of "easier".

share|improve this answer
1  
Don't get me wrong, I like the idea of using UML to document the code/model. But I prefer to think of the UML tool using my source code to build the diagram, not the other way around. But yes, I'm not that keen on the whole CASE thing. We've not committed to using the tool though, so it's not like we're 100% going to use it. –  Jason Evans Mar 4 '11 at 21:22
1  
@jason evans - Unlike my post sounded, I really don't hate UML. :) I have a UML cert from OMG; however, I really believe UML is best used as sketches on a whiteboard or notepad. CASE tools are notorious for making tons of documentation that no one reads. I guess it depends on the project. NASA space shuttle code may require it. Bob's Widget selling website, probably won't. –  davidhaskins Mar 4 '11 at 21:28

I've had mixed success with CASE tools. I agree that you should have misgivings about the time savings involved.

The one place where it worked well was in an embedded device: we developed it in Rhapsody (was from I-Logix, then Telelogic, then IBM). The same functionality was ported from a ThreadX device to a VxWorks device to a Linux device with good speed, though this might have been due to Rhapsody's nice "platform agnostic" framework rather than CASE specifically.

share|improve this answer
1  
Yeah, Rhapsody is/was nice, and it was targeted to embedded systems. I think that for other applications, UML just isn't expressive enough to provide a great deal of value for forward engineering. I would suggest that the poster give it a miss for anything else. –  Marcin Mar 4 '11 at 22:23

Say I have a UML model which I built a VS solution from. Now, I want to rename a class method to something else; will this mean having to update the UML model first and then rebuilding the code? Is this how case tools normally work?

There's no "Normally". There's one-way engineering -- diagram to code. There's round-trip engineering -- diagram to code back to diagram for further editing.

I like the Domain Driven Design way of project structure - Infrstructure, Services, Model, etc. I doubt very much this tool will do that.

Why do you doubt this? Most UML and CASE tools depict this layered architecture very, very nicely.

I'm concerned that this tool's data layer code might not be a nice to integrate in the UoW pattern, repositories, etc. This I will need to verify when I get a closer look at the generated code.

Good approach. Frameworks have big advantages over tools. Stick to the framework more than the tool.

I like to use TDD/BDD for building my code, and using a CASE tool looks like it will make this difficult.

WHy do you say that? You document the BDD information in the tool and generate some code.

You write test cases and test the code. The tests fail, so you fix the diagram and fix the code.

It sounds like the CASE tool might do this very nicely.


The issue with programming through pictures is the "density" issue.

It's harder to put line-of-code level details into a picture than it is into text.

Text is dense, but lacks visual overviews.

Programming in Pictures is sparse but provides a nice overview.

For certain classes of problems, it can be effective. You won't know if your problem is the sweet spot of programming in pictures until you've tried it.

share|improve this answer

I'm very skeptical of CASE tools, and graphical code generation in general. I have seen several CASE tools arrive with much hype, only to be largely abandoned. They look great in demos to non-technical management, but the demo only shows the initial production of a trivial application. To build a real system, all the user requirements must be represented in some language. Using a CASE tool won't reduce the complexity of the requirements. All a CASE tool can do is provide a different language for building the system -- a minimally tested, proprietary language with limited documentation, and a small user community.

Often the sales pitch is that objects and schema and other artifacts can all be generated from a single diagram. But the duplication between those artifacts should not be present -- it arises because the language and framework are insufficiently powerful.

Using text, we can both deliver and receive information much faster than we can via diagrams. Using a CASE tool to build software is like trying to write a full-length novel in comic book form.

share|improve this answer

I've had mixed success.

In my experience, most CASE tools are good in one direction: from model to code in one shot. They tend to be worse at keeping the two synchronized. IF you're using something nonstandard from a small vendor for a specific domain, it is more likely that "accidents" will happen.

My experience is also that if they are useful, they are useful in both small cases and larger cases. If they're offering a trial, why not just play with it for half an hour, generate some model similar in principle to what you're trying to do, then make changes on both sides and see what happens?

share|improve this answer

I had the same problem because UML was wasting my time and delaying my project as soon as the generated code needed to be changed. I switched to Omondo and I don't have this problem anymore. EclipseUML Omondo only works with Java, this is not an MDA tool but it does what it says.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.