i personally like the combination of uml and my own customized diagrams to give me a good view of the system.

i am not particularly fond of doing everything in uml as the tools from ibm rational and borland seem to be pushing.

what about you?
Posted on 2004-05-18 18:01:00 by clippy
I have heard of it for first time when on my university when I saw it as a requirement on some job advertisement but never saw it in action. If you were to point me to some place to start from, what would it be? Point me :) I actually dont know what uml is appart from the meaning of this acronym.
Posted on 2004-05-18 18:25:33 by Milos
mmm you can have a variety of way to develop (or attack) problems. Also ways of understand it.

Also you have a variety of ways in what you can express a solution.

For express you use an algorithm or a more generic or extended a rule of calcule (IIRC). That express a solution directly, for example how to add 2 numbers or n :)

Now, you have other point of view, classes, relations, and others, instead of describe how you will do the calculations, you describe how diferent things are related to others, in this case, you only write the names(methods, members) relations and others, instead of specify the algorithm.


Also I supose that you can still use a description of an algorithm, but you need take care of more things ;).


That is what I know... not much sure...


Have a nice day or night.
Posted on 2004-05-18 18:42:26 by rea

I have heard of it for first time when on my university when I saw it as a requirement on some job advertisement but never saw it in action. If you were to point me to some place to start from, what would it be? Point me :) I actually dont know what uml is appart from the meaning of this acronym.


try the book - 'The Unified Modelling User Guide' by grady booch

or search the web. i am sure you will find lots of great information.
Posted on 2004-05-18 19:08:07 by clippy
This is something I was not fond of before doing my SOEN 341 course. That one course prooved it is useful for team projects, any team size really. The larger the team, the more meticulous the class diagrams and UCD's should be. You don't start building a house or sky-scraper without first developing blue-prints, why should you start building a medium/large project without decent UML diagrams? Well, you can always build a tool shed or dog shed without any papers thouhg.
Posted on 2004-06-13 04:11:03 by FearHQ
I think UML is really useful to show the relations and interaction between classes, something which can not be seen as easily from the code itself. With complex projects (which don't even have to be very large), and especially in teams it works fine. But personally I don't think defining *everything* in UML is a good idea. It's not that interesting to specify every method in UML (you can even define the code of a method in UML if you want too).

Thomas
Posted on 2004-06-13 04:27:07 by Thomas
I am forced to use UML on my current project.
It is retarded because the project itself is very small, it only has a handful of classes which are painfully obvious anyway. It costs us a lot of time to document our test program entirely with UML, and it is useless since it is just that: a test program. We only use it to check our algorithms, and then we throw it away. Nobody else will ever use it, so why bother documenting its design at all? (I consider the test-program a dog-shed or tool-shed, as mentioned before :)).
The REAL problem in the project is the complex mathematical algorithms that are in each object. And you cannot model that with UML at all. For some things UML may be nice, but not for small project with complex maths or such. And my project coordinator is just a stupid inexperienced jerk who doesn't understand what we are doing.

He also said my documentation on a certain algo was not good, because he couldn't understand it. I said it was a very complex algo and was only to be understood by experienced specialists in the field, and I can't help it if he lacks the specialist knowledge and experience to understand the algo. That doesn't mean the docs themselves are necessarily bad. What an idiot.

To answer the question: I think UML is overrated, and it is stupid to do EVERYTHING in UML. Instead of UML, people should focus more on algorithms and such as well.
UML can be helpful for parts of the program that need to interact together though... Say you have a plugin system, then UML would be a nice way to document how the plugin fits into the rest of the system.
And if you work in a team, each part of the team will work on one 'plugin', so that would be the same. But every little irrelevant, obvious class, that only one person uses somewhere deep inside the program, which is never seen by others? No, that's stupid.
Posted on 2004-06-13 05:28:39 by Scali
You raise a vaild point Scali. However, you aren't taking UML for what it was meant to do. You were never intended to draw up diagrams of every "helper" class out there, and certainely are not to touch algorithmic discussions - that's implementation detail. This is what comments in code and source code documentation are for imo. Ideally you start out with the UML classes and have possibly a vague concept of the implementation, but you focus on a design that is workable. If you were to find out that implementing something would be better done in another way, then you should go back to re-designing the project in UML (or do the touch-ups...). I guess ideally the UML shouldn't really change (makes me thing of COM interfaces), but we all make mistakes in judgment... If you get caught up by the algorightms, you probably won't have a robust maintainable design. While this may apply ideally to cases that you have had prior experience in (hence design foresight), when you venture on new coding watters, UML might not work as well. And your code would probably end up like the tower of Pizza :)
Posted on 2004-06-13 06:05:17 by FearHQ
However, you aren't taking UML for what it was meant to do.


Yes, tell that to the project coordinator.

You were never intended to draw up diagrams of every "helper" class out there, and certainely are not to touch algorithmic discussions - that's implementation detail.


In my project the only useful information is the implementation detail. That is why I don't get why we have to spend so much time on UML, and the implementation is not given so much attention. That is what I am trying to say. UML cannot document implementation. For simple programs, this may not be a problem, because the implementation is trivial. But in our case, the object model is trivial and the implementation is what matters. So UML has no use.

Also, I think that implementation and design are not completely independent. Especially in our case, where the exact implementation is not known yet, because we have never done this before, and we have no info of if anyone else ever did this, and if so, how. This is why we made the test-program. It's the only way to figure out how to implement it, and then we can figure out how to fit it in the design, and create a clean implementation.
It's completely backwards to try and document the design when we don't know what it should be like. It changes all the time.

This is what comments in code and source code documentation are for imo.


The algorithms need to be documented completely independently of the sourcecode imho. And the comments in the sourcecode should point to the documentation. So if you have read the docs, you can see in the sourcecode what part of the docs each block of code refers to. Some parts of an algo are never found in the sourcecode again, so the sourcecode itself cannot document an algo.

when you venture on new coding watters, UML might not work as well.


Yes, this is exactly the problem that we are having. As I said before, our program's function is mainly to test the algorithms that we are developing. We don't know exactly what the algorithms will look like, and what input and output they will need. The test application is a tool to find that out. It merely visualizes the output of our algorithms... and while implementing the algorithms, we find new problems, and solutions... So the program's function is to determine what the final version will look like, that's why it's so stupid to document this test program.
You cannot apply the rules so neatly here... You don't want encapsulation, because you don't know what you may need to access, or where. I tend to leave all data public in such a situation... And when the routine is finished, I close it up. But now we are supposed to encapsulate before we know what to encapsulate, or where, or else it will be a bad UML design... So what?!

Don't you just hate it when you have to work for people who don't have a clue?
Posted on 2004-06-13 06:20:35 by Scali
haha welcome to the rest of your life :P

such is the state of the world sadly. You'll work for dumber people who'll make twice as much as you and who'll do everything they can (not) possibly think of to make your life miserable. ;)
Posted on 2004-06-13 12:37:38 by Hiroshimator
Don't worry, I'll set up my own company asap, if I can't find a decent place to work at :)
Posted on 2004-06-13 13:07:48 by Scali
Well, so far I've never worked for a real company or created any piece of commercial software since I am only a 2nd year Software Engineer... All my projects were academic so far, but I was able to pick up on these UML strong and weak points fairly simply. UML will make it easier to work in a team and prevent the project from dying/not being robust, but you MUST have prior experience before you can start designing your classes and such. I don't really see how you can OOP when you have no clue what you're doing and if it will work. I did this in one of my projects - a write-n-compile way of doing thinhs. Think of something, write it, test it, come up with better design, re-write it. UML is really bad for this haha. We were in a team of 7 where I was the only one coding and everyone else was (trying) to document what I was doing and model it. But I would restart the project from ground-up quite frequently (obviously using what I already had as a basis). To always follow the design pattern, now that's just silly.
Posted on 2004-06-13 14:52:36 by FearHQ

Don't worry, I'll set up my own company asap, if I can't find a decent place to work at :)

if u do please give me a job? :p
Posted on 2004-06-13 15:20:41 by x86asm
I don't really see how you can OOP when you have no clue what you're doing and if it will work. I did this in one of my projects - a write-n-compile way of doing thinhs. Think of something, write it, test it, come up with better design, re-write it. UML is really bad for this haha.


Yup, problem is that I'm the only one on our team who realizes this.
Posted on 2004-06-13 15:55:00 by Scali
Well, I'm working on a project with about 60-70 classes, of those there are about 40-50 classes that are shared with two other projects.

We use UML for most (not all) of the classes, and I can not imagine not using it.

Doxygen is good for making some web based documentation, and some very primitive UML diagrams.
Posted on 2004-06-13 22:45:24 by gorshing