ASM Community

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?

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.

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.

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.

Yes, tell that to the project coordinator.



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.



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.



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?

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

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.