A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am a self taught amateur programmer (started in 1982) who is now doing a degree to formalise my knowledge and shed some bad habits, but I really cannot believe what I am being told about UML and the Unified Process.
I realise that there is a gap between academia and reality, but the whole rigmarole surrounding the Unified Process astounds me. In projects that I have done so far (I have written several small apps for small businesses and for employers, mostly using fairly simple SQL / VB / Java) I have used a "Top Level Tasks Spec" which describes to the customer what tasks they can expect the product to perform, followed by various levels of spec for my own usage breaking the tasks out into sub tasks which then form the basis of code tests. This might be a very naive way of working, but I've always found it very effective.
My question is, can anyone, with their hand on their heart and a straight face, say that they have developed an application using the whole Unified Modelling Mallarky, and written specs for customers in UML, complete with little stick men?
Paul, it sounds like you have a nice, "Lite" process which works for both you and your customers. Stay with it.
UML, and the Unified Process, are the latest attempts from Rational to get their tools adopted as the industry standard. The problem is that UML came from joining three very different camps -- Booch, Jacobson, and Rumbaugh. The resulting unholy mess will take years to settle out.
The result is that very few companies use the entire thing. Many companies use various subsets. And Scott Ambler has written books on "Agile Modeling" which seeks to select subsets of UML and say when they are useful.
The latest attempts to generate systems of code from UML diagrams have revealed that UML is not suited for the low-level of development -- unless used in the ways Ambler suggests. Currently UML is being modified (AGAIN!) to put in place the low-level hooks necessary for it to drive code generation. But it's still not there yet.
Tuesday, September 27, 2005
My software engineering course was taught by a senior developer from IBM's Rational division. A student asked a question about their RUP software, to which the instructor answered, "I have no idea. I've never used it." That spoke volumes.
Tuesday, September 27, 2005
"can anyone ... say that they have developed an application ... and written specs for customers in UML"
You can write specs in UML, but most of the time it's a waste of time. What most UML diagrams are useful for, though, is getting a clear picture and communicationg concepts to others.
Tuesday, September 27, 2005
In my experience, the most useful parts of UML are the class diagram, state diagram, sequence diagram and use case diagram. These diagrams are used in support of the requirements documents that are generated at various levels, along with ER diagrams to show the database structure. We use a waterfall model, with three levels of specifications as follows:
Feature specification - Created by product management to detail what the customer expects. Use case diagrams are useful here.
System specification - Created by the architect and systems engineers to define how the problem should be solved. This includes high-level class diagrams (if necessary, expanded use case diagrams, etc.
Software specification - Created by the software engineer to describe how the program (module, etc) will operate to fulfill the system (and therefore feature) specification.
We currently use Rational tools, ClearCase and ClearQuest, and have considered using Requisite Pro to allow traceability through this process (and to the various levels of testing that occur). If anyone has used Requisite Pro ... I'd be interested in feedback!
Speaking of Scott Ambler, I was just yesterday at a conference workshop he was giving where he quoted Joel on something, and then immediately went into rant on how bad BDUF is. I was going to call him on it, but he was too busy answering real-world questions by saying "well, in that case, you have to do something different, but in general [insert XP speak]".
My only experience with the Unified Process was using a trial of Rational Rose sometime in the late 90's.
The program was big, slow, buggy, and crashed when attempting to read a file that it itself generated.
My conclusion: either Rational itself doesn't use the process, or they did, and this POS was what the ended up with.
Either way, it didn't say a lot about the value of said process or tools.
My first impression of RUP was "Wow! This is great! Now we can follow this process and everything will just fall into place."
My astounding naiviety aside, it wasn't long before I realized "Hey, I'm spending weeks and weeks on a bunch of paper documents and I really don't understand what I'm doing any better."
I know; there is some good to RUP and I certainly wasn't schooled on it enough to use it effectively, but I found the entire process to be so crushing as to be useless. At least for my version of the real world.
Tuesday, September 27, 2005
>My conclusion: either Rational itself doesn't use the process
Chris, see my comment above about the SW Engineering instructor. IIRC, he worked for Rational before the acquisition, then continued on with IBM. To be fair, he didn't elaborate, but the implication was that they didn't eat ther own dogfood.
Wednesday, September 28, 2005
Glad to see it isn't just me, then. My course (with the OU) uses Rational Rose which is quite useful for drawing class diagrams, but not significantly better than Illustrator, PowerPoint or even the computing Swiss Army knife, Excel.
The thing that scares me the most is the long, drawn out specification process that they recommend; The project that I am working on at the moment is a full Food Safety / Technical system to integrate with a DBII based mainframe using a combination of VB6 and an MSSQL server. The project will probably take another three months of work, not including final testing and implementation, and to spec out this system to the senior team I was given ... 2 weeks. Those 2 weeks had to include meetings with four different departments at manager and user levels, legal research and user shadowing followed by a day of furious typing to create the "Task Spec". I'm sure that some developers get months to write beautiful specifications, but most of us just don't have that luxury.
Just as people are saying that you should only use parts of the UML, the same is true of the Unified Process. dX, a minimal implementation of the RUP is described here http://www.objectmentor.com/resources/articles/RUPvsXP.pdf
If you think the UML process is a bunch of malarky just wait until you get bogged down in the CMM stuff.
Wednesday, September 28, 2005
RUP is a huge abstract wafty thing that tries to meet all process needs in a single model.
If you do consider using it then you really should consider customising it for your own shop/project. It was never meant to be applied in full straight out of the box, and customisation guidelines are a part of the documentation.
Some P's seem to confuse RUP with UML. UML is not a process model but a set of inter-related diagrams that express various artifacts that happen to exist within RUP (and elsewhere), such as architecture, design, and implementation models. RUP is 'how you do it', UML is 'what you do' wihtn a particular part of the overall process.
Wednesday, September 28, 2005
Well, here is how someone explained one little piece of it to me.
association -- A uses a B
-- line from A to B with open arrowhead at B
composition -- A owns a B
-- line from A to B with filled diamond at A and open arrowhead at B
aggregation -- A has a B
-- line from A to B with open diamond at A and open arrowhead at B
This was said with a straight face. I tried to get this straight but never could.
Then I read "UML distilled," which says, "Aggregation is strictly meaningless and I suggest you ignore it in your own diagrams. If you see it in other people's diagrams you'll need to dig deeper to find out what they mean by it. …"
My experience is that in every discipline there are people who earn a lot of money by saying things that don't make sense, and saying it in such an obscure way that they seem like geniuses to the gullible.
Which is not to say that process, planning, and visual presentation of concepts are not important in software development.
Within the Delphi world I hear more and more about the Eco UML tool that enables "model driven" applications. It ships only with Architect version of Delphi 2005, but with Delphi 2006 later this year it will filter down to the professional version.
People are apparently doing real work with it, and most people who use it seem to love it:
It's available only for Delphi.NET or C# within the Delphi IDE (i.e., not Win32 Delphi) but I believe it's going to be available as a VS.NET plugin sometime in the future.
I don't know if Eco itself is the future. But I wouldn't be surprised to find tools like this becoming more and more as "model driven architecture" tools become more mature. Maybe not. But I wouldn't bet against it; the general level of programming abstraction is slowly creeping up over time.
My company writes software specs. that are easy to read in English. We define what the software will do as well as what it will not do.
We create a feature list. How it will be implemented: C/C++, HTML, HTTPS, SOAP, FTP transfer files here and Unzip, etc...
We get buy in from stake holders (Customer, engineering, programmers) all in agreement.
Sometimes deadlines slip but our process allows us to be expeditious and we nearly always keep the ball in the customer's court when things slip.
RUP, UML, I've heard the names but never bothered to look into them much.
We use version control and bug tracking software to manage the coding efforts. We even use version control (subversion + tortise) to version our written documents.
my 2 cents...
Thursday, September 29, 2005
I had a large amount written then something else took down the browser. Argh. Anyway, one of the early steps in RUP is to tailor RUP to the needs of the particular project, so no fair complaining about how much it encompasses.
We had a large rollout here a few years ago. I liked the emphasis on mitigating risk by running out prototypes to address identified risk items. I also liked the fact that it was every team member's right to add items to the risk list. This helped me reign in scope creep. Unfortuately, a group of non-developers got hold of the 'process' here and added insane amoutnts of ceremony. You would not believe me if I told you how much we spent on the internal website supporting RUP alone. Iterations proved very nice on the pilot, but the company didn't think to change the project financial model. So our projects were financed and estimated according to a waterfall model, then once kicked off we ran 'iterations.'
Today's flavor is 'Agile' in our company. You can't walk down the hall without being bowled over by a scrumm. Rup was good in that our level of software maturity is higher now than before the process was brought in. I find the SAD's useful and still create them for all of my projects. The contents differ with the project though.
Great quote about IBM not using Rational tools. We bought the entire suite. Rose was the only one that remotely worked. You'll get just as much benefit, heck maybe more because of the free-formness, from Dia, Sketch, or Visio.
Of course in the end, once the methodologist sells his or her soul to a company it's about the tool suite. There was a company even selling a case tool to do CRC cards!!!!
Friday, September 30, 2005
class diagrams, sequence diagrams, and activity diagrams are pretty much the ones you will use. Forget the rest of it.
Friday, September 30, 2005
All development in my company is controlled by architects who insist that every project is developed using RUP and UML. Unfortunately, we haven't had one project that could really be classed as succesful. Quality of the software produced has been mediocre at best, requiring extra funds to correct.
I'm aware that there are those who are happy using the UML/RUP/BDUF approach, even stating that it's impossible to develop 'properly' using an agile/XP approach. I'm not convinced....
One basic problem is that UML only goes as far as member variables and function declarations. When architects have produced a 100 page doc full of UML diagrams, the implication is that "we've done the hard work, the code will just fill in the gaps". So the plan has more design up front time and less code and test time.
However, the real work of any application is contained between the curly braces! Our projects contain detailed maths/physics equations and the UML never goes down this far. Yet our Project Managers believe that after Big Chief Architect has done his UML magic, the job is just about finsished. All we need is a couple of coding monkeys joining the dots for a couple of weeks. And then our troubles *really* begin.....
The problem is that UML can't really be verified. Every app I've ever seen developed by doing UML first, has terrible performance on first release. Then the app has to be redesigned and rediagrammed at great cost.
I know this sounds just like bad management and a bad implementation of what could be a decent process, but I believe that the UML/RUP marketing speak has led the non-tech managers and architects to work this way. And we're CMM 3, too, so we must be proper software engineers!
Monday, October 03, 2005
Don't confuse UML with RUP. Don't confuse how you've seen RUP used or how RUP is taught in a classroom with how it is useful in the real-world. Don't assume that the Rational tool-set can't be taken out of the RUP approach.
Any, _any_, process, modelling tool, design methodology etc. can be taken out of context and made worse than the problem it is intended to solve. Do people use RUP? Yes, but the sensible ones are capable of tailoring it to have value to them. They don't buy the damn thing as a product with a bunch of tools attached to it and enslave developers to useless procedures. RUP has its uses, XP has its uses, Waterfall has it's uses.
I believe we get paid to be capable of seeing the context where each may have value. Screwing your face up at the first element that doesn't suit you right now and declaring the whole shebang to be a waste of time pretty much puts you out of the club of people who can express a useful opinion about development methods. The fact that RUP is a bundled with some crappy tools and sold to clueless management types as a panacea and forced on people without consideration of the context doesn't help, but it pays to be open to the idea that there may be something worthwhile in there for you sometime.
Wednesday, October 05, 2005
I have been told that RUP is flexible enough to allow a team to adopt a waterfall development model, an iterative development, and XP model, or whatever model of development you want to follow.
Hearing this, it leads me to think that RUP is descriptive, not normative. And given that it's entirely separable from Rational's software products, RUP seems to be an abstract model--or schema--for describing software development methodologies. At some point you need to decide how to develop a product, and understanding the universe of possible ways of doing that is only so useful. What you really need is experience, knowledge, and skill.
So, it seems to me, RUP is neither necessary nor sufficient for creating a successful project. What sells RUP--the process and the tools--is the misapprehension of managers who think that RUP equals successful products.
I've seen RUP (and UML) bandied about by consulting companies that want to project an air of having a clue. In my experience, they never actually buy the Rational tools--they're astoundingly expensive--but instead use some piece of crap free software that allows them to create diagrams that give clients the warm fuzzies.
And the warms fuzzies are all the diagrams give clients, because it's not trivial to understand many types of UML diagrams. I'm puzzled by UML diagrams: if I need half a shelf full of books to understand them, what does that say about their utility when it comes to putting them in front of non-technical clients? I stick to two main sorts of diagrams for my work, and together they work well.
First, the trusty ERD; it's amazing how easy it is for almost any generally educated person to get the gist of an entity-relationship diagram. You can quickly move from simple boxes with lines to boxes with attributes in them and lines with named relationships and cardinality.
Remember what Fred Brooks wrote: "Show me your flow charts and conceal your tables and I shall continue to be mystified, show me your tables and I won't usually need your flow charts; they'll be obvious." ERDs are a wonderful tool for transferring knowledge from domain experts, customers, and others, to technical people who lack a complete understanding of the problem domain. They're easy to draw by hand, and can almost as easily be made pretty in a drawing tool. I can't say enough good things about ERDs.
The other type of diagram I use is essentially a GUI flow chart. Imagine a screen shot of a application window, web page, or other user interface object annotated with flow charts describing how the various elements of the interface work. Sometimes I draw high-level flow charts, where a box represents a page. Other times, I draw low-level charts, where several pages are dedicated to the same page, showing what happens when a link is clicked.
Again, pretty much everyone can understand the basics of flow charts, and the addition of UI objects has never presented a problem for any technical or lay people I've worked with. You need about three flow chart symbols: a rectangle to indicate a process, a diamond to indicate decisions, and a cylinder to represent that database.
I see product development as a fundamentally human activity. It's not really about technology. It's about transferring knowledge between different people and creating shared understandings among people from completely different backgrounds. Sure, some coding happens along the way, but finding simple, expressive languages is the key to bringing products to life. I've worked in a lot of environments: start-ups, consulting companies, huge pharmaceutical companies, and I have yet to see anyone use anything like Rational's tools, RUP, or UML in a way that displayed any unique advantages to the rampant ad-hoc-ery that I've also seen.
Again, if it's neither necessary nor sufficient, what is the point?
Thursday, October 06, 2005
IBM have apparently just donated bits of the RUP to the open source community. [ http://www.theregister.co.uk/2005/10/12/ibm_open_source_blueprints/ ]
As an OSS developer, I can quite clearly state that we have been doing perfectly well without it. We may not do many UML Diagrams, but test-centric development and apache gump to run a nightly integration build of all the main OSS Java projects means that the code quality of the OSS projects I've worked on are better than any of the stuff I've seen in house. I also find that the source itself is really well documented -apart from the stuff contributed by vendors (including IBM), who are used to projects where if something needs explaining, the original author is a few rooms away.
Wednesday, October 12, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz