UML, OO Analysis and SDM and such
-
Is System Design like: UML, OO Analysis and SDM done much by Software Developers?
A lot of people I spoke to said they don't do that, they just start programming. I often got answers like:
"We don't do that, we don't have time for that."
"No software developer I know uses UML."
But at school it gets hammered into you.
Does it depend on the size of the project?
Or is it just not done in the real world?
-
@Ice^^Heat said:
Is System Design like: UML, OO Analysis and SDM done much by Software Developers?
A lot of people I spoke to said they don't do that, they just start programming. I often got answers like:
"We don't do that, we don't have time for that."
"No software developer I know uses UML."
But at school it gets hammered into you.
Does it depend on the size of the project?
Or is it just not done in the real world?
I've once really seen UML diagrams for a project, but they were formally incorrect (control flow in a class diagram or something like that) and nobody (but me, since I learned UML2 then) noticed.
In my experience, the most often used formal method is the ERD for database design.
-
Formal system design tools are good for big projects. For smaller, you don't really *need* them. They do involve some overhead and might be overkill for smaller or medium projects. It depends, really.
But this:
"A lot of people I spoke to said they don't do that, they just start programming."
Is utter crap. No good can come of this. Any program, any system, benefits from putting a few things on paper.
Out in "the real world", where you work with others on a single project, you *will* define a plan before writing a single line of code.
Of course, in the real world, you have people for that. :)
-
I do, in fact, use OOA and UML regularly. However, I can understand *why* so many people don't: management pressure.
If you *ever* do *any* programming, you should plan ahead, and that means structured/functional decomposition and/or OO analysis. It also (hopefully) means UML. True, your plan will never actually reflect the final system, but the planning itself helps you formulate your thoughts and approach.
IIRC, D. Dwight Eisenhower once said something along the lines of "plans are useless but planning is indispensable."
-
@dhromed said:
Formal system design tools are good for big projects. For smaller, you don't really need them. They do involve some overhead and might be overkill for smaller or medium projects. It depends, really.
But this:
"A lot of people I spoke to said they don't do that, they just start programming."
Is utter crap. No good can come of this. Any program, any system, benefits from putting a few things on paper.
Out in "the real world", where you work with others on a single project, you will define a plan before writing a single line of code.
Of course, in the real world, you have people for that. :)
That's entirely true either. I just built a custom labeling/warehousing system without doing any up front design work on paper. Now to be fair, it was the fourth one I've written so I knew exactly what pieces were needed and how they interacted.
The preliminary artifacts might have been useful to show the other developers on the project, but I prefer to actually talk to them and show them how it works on a whiteboard when they have questions.
Now, for anything that I have not done before, I still do prefer to do the prelim stuff on paper. And I do UML at a very basic level for those projects. I'd do more with it, but I'm the only one at work that even knows what it is.
-
I have a real problem with UML. The problem is that I have no graphic design skills or aptitude.
I've tried using Visio to draw simple diagrams and even that is beyond my abilities.
I've tried taking a "NetG" course on UML. (If you're in a large corporation these courses may be available to you. They are also available to ACM members from the ACM web site.) It was useless. (All the NetG courses I've tried are useless. The "Web Design" course places great emphasis on knowing the hex codes for different colors by memory.)
As far as I know, nobody here uses UML anyway. We use an informal text-based OOA, mainly Use Cases.
-
Well, every software developer I know uses UML, so I guess it depends on who you associate with.
-
My big problem with UML (and nearly any kind of diagrammatic design) is that lots of people think "1 picture is worth 1,000 words", and then think that any picture is worth 1,000 useful words. And then they make a diagram that means nothing.
Class diagrams, to me, don't really represent design; they're either too high-level to provide any actual information, or too low-level to actually be design -- it's half-written by that point. I like sequence diagrams -- or at least, the attempt to describe the dynamic operation of a system. I snicker at the use case diagrams with the stick-people. Those are the worst ones, IMO -- sometimes, you just need words.
On the other hand, once upon a time, many companies and teams ago, my team used Rational Rose, and it certainly had some nifty stuff. Used it less for up-front design than showing and modifying the current system.
Now, in general, do people do design? Well, you either do it up front, and usually end up with better results, or you do it implicitly as you "just start programming", which usually results in lots of mediocrity and rework on anything of non-trivial size. Whether you follow a formal methodology or not, up-front thinking is A Good Thing. Remember the 6 P's: Proper Planning Prevents Piss-Poor Performance!
-
@AssimilatedByBorg said:
My big problem with UML (and nearly any kind of diagrammatic design) is that lots of people think "1 picture is worth 1,000 words", and then think that any picture is worth 1,000 useful words. And then they make a diagram that means nothing.
What you're trying to say is "A picture is worth 1000 words, but very few sets of 1000 words can be adequately represented with pictures."
Now, in general, do people do design? Well, you either do it up front, and usually end up with better results, or you do it implicitly as you "just start programming", which usually results in lots of mediocrity and rework on anything of non-trivial size.
My favourite methodology is this one:
Start building the thing as quickly as possible, usually in perl or ruby regardless of the nature of the application. No time wasted on testing or documenting, just get it working as quickly as possible. After 2-3 weeks, discard everything you've done so far, and then start planning how you're going to approach the problem.
People who jump right into the planning stage, with no previous experience on how to build the target application, generate a plan that is utterly worthless (and will have been discarded within the first month of attempting to implement it). You can't usefully plan something that you've never tried building. You need to sink some time into trying to build a useless prototype just to find out what the problem is really like.
(This does not satisfy 'plan to throw one away' - that still applies to the first one you really build. All you discover from your first experiments is how to plan it, not how to implement it)
-
@asuffield said:
People who jump right into the planning stage, with no previous experience on how to build the target application, generate a plan that is utterly worthless (and will have been discarded within the first month of attempting to implement it). You can't usefully plan something that you've never tried building. You need to sink some time into trying to build a useless prototype just to find out what the problem is really like.
homage
-
@Whiskey Tango Foxtrot? Over. said:
If you *ever* do *any* programming, you should plan ahead
I was going to say something about the tiny scripts youse for yourself and how these are tossed together without even any errors because they're so simple, so you don't really need any planning for those -- but then I thought of the JS graph writer I work on occasinally and realised that I kept planning and structuring the one-page script as I wrote it. It even has features now.
So yes.
*any* programming.
-
I think everybody plans ahead in sorts of their own. UML can be good for some but not suitable for others' mind. Software design comes from many sources of experience and knowledge. Oo¨ is only one among the resources. For example when start a real big system, I pull up experience from:
- Berkeley C style programming (especially with interfaces and drivers)
- the way how C program is organized in jpeg, mpeg coding
- dividing in modules and interfaces (modula-2, turbo pascal, corba's idl)
- using pure structured sql
- data structure and algorithm
- math algebra
- graph theory, petrinet
- bpmn, bpel
- process automation
- generic templates and reuse
- inheritance and late binding from oo
- and so
Using these vast resources of my experience I can assembly a real big system that would take a big team to do in rup/uml for a year or forever.
I can use very simple solution to tacke a real complex system and I know every bit in my software runtime, so never have to use debugging tools for my 14+ year career. I'm now teaching my employees that 'debugging and performance analyzis tools' are only for bad design. Good designed software never need debugging. You must be able to go to the line of code that causes the problem in less than 15 minutes.
-
Here's how my 'big' projects go:
I create a context diagram that shows which systems will need to interact and how those systems will connect
One of us creates a software architecture document that outlines the 'architectually significant' use cases, deployment views, etc
An integration analyst reviews the business requirements and then comes up with a simple spec for what the integration needs to do
A data analyst reviews the business requirements, source format and target format and then comes up with a data mapping document
I then come up with sample messages based on the data mapping. The data analyst will review these to make sure I'm on the right track. These sample messages then go to the other vendors we integrate with; they understand they need to match the spec or suffer.
I then create test classes that will pass when my code 'works', based on the business requirements.
I then code until my tests pass and commit
At times, especially when we're working on tricky parts of a system, we might come up with a sequence or activity diagram... this can be especially useful to determine what steps are needed so we can then figure out how to decompose the problem into something simpler, like a state machine.
------------------------------------------------
Flashback time. I was one of the lead app / integration architects on an $80mm software project. We did document and formalize things a lot more on that project simply because of all of the vendors involved (two development partners, one of which did 80% of their work offshore, plus internal developers). Even then, I tended to chastize anyone that bothered to come up with a class diagram. I've yet to find an instance where it wasn't faster to either define what you wanted with an interface or just create the shell of the class and then auto-create the diagram using any number of tools available.
-
I once worked on a project for a big corporation (CMM level 5 and other bureaucratic nonsense) that tried to get us to use Rational Rose. God, that was painful. If you "think" that way I can see how it might be useful for your own development, but forcing everyone to do it for procedural purposes is worthless. I'd much prefer a standard detailed design spec, with diagrams only where they actually simplify the discussion.
