A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
"We are currently investigating the feasibility of a new project and part of this study involves a scope definition of how people/developers currently actually use UML. So there it is: How do you use UML? Do you use it to have nice class diagrams to pin up to the wall so you/it just looks great or do you first model out every little detail into class and sequence diagrams before generating or writing even one line of code? Now for a moment, let's dream the UML dream. Do you think that in the future one could maybe even envisage software development where UML could simply replace all existing coding languages? One could argue that coding languages are merely formatting tools to implement the actual logic, which can be portrayed 'in a Unified way' using UML schemas. What are your ideas regarding the real merits of UML, currently and in the not so distant future?"
on behalf of someone else
Wednesday, September 06, 2006
> How do you use UML?
* Requirements+use cases
* Packages of classes (i.e software architecture; don't bother with a separate deployment diagram)
* Classes within each package
* Other diagrams (e.g. state and sequence diagrams) optional, depending on how worthwhile they are: where "worthwhile" depends on the application, and on how much value-add (ie. forward and reverse engineering) your UML tool can give you for that kind of diagram.
The reasons why UML is better than just source code are:
* Links between the requirement diagrams, and the class diagrams which implement the requirements -- this is useful when you want to know which clases implement a requirement, and when you want to know what requirements are associated with a class
* Descriptive text associated with a package (in source code you typically associate comments with classes and sub-elements of classes, but no comments at the higher level of packages of classes)
Round-trip engineering: UML and source and source to UML; if a UML tool can't round-trip, then I might prefer not to to bother with it (because using it could require maintaining the source code and the UML model separately).
> Do you use it to have nice class diagrams to pin up to the wall so you/it just looks great or do you first model out every little detail into class and sequence diagrams before generating or writing even one line of code?
1) High-level UML class diagram which lists:
* Each package, interface, and class
* Inheritance and important data members of each class
* Optionally some method names (typically, method names of interfaces but not of classes
2) Forward-engineer UML to source code
3) Implement details in source code: actual bodies of the methods, and undefined previously undeclared private methods and less-important private data
4) Reverse-engineer source back into the UML model
5) Tidy-up the resulting UML diagrams, to keep them readable (decide how much detail to show for each class on each diagram)
6) Forward-engineer again, and verify that resulting source is unaltered, to verify that source and model are in synch
7) The above is the initial implementation. Next, when I want to add a new feature, I start by adding to the model and then forward-engineering again; or, if I want to refactor, I start by changing the source and then reverse-enginnering again.
> Do you think that in the future one could maybe even envisage software development where UML could simply replace all existing coding languages?
You *can* use a sequence diagram to represent a flow-of-control call stack, but it's a *really* non-compact notation compared to source code. A high-level sequence diagram which ommits lots of details can be useful, but if you reverse-engineer real source code to a sequence diagram then the sequence diagram is huge and unreadable: so no I don't think so.
> What are your ideas regarding the real merits of UML...?
* Document the source
* Links between documentation and source
* There being standardized a notation permits the development of the corresponding CASE tool support.
I'm a contrarian on this topic. I've used, and seen used, many visual ETL tools. I find that when you get to the real life, complicated business logic, the diagrams created are worthy of a circuit diagram.
Nothing describes like words. I find complete sentences to be the best documentation tool (high level diagrams do add alot, I will say).
But then, that's me.
When I need to use these tools, I exclusively reverse engineer.
I use UML informally to sketch ideas:
I find formal and exhaustive use of UML not worth the time.
I agree with the other comments.
"on behalf," you're thinking along the same lines as Microsoft about UML and model-driven application (MDA) development. They like the idea, but think that it's better to go beyond the standard definition.
"Our vision is to change the way developers perceive the value of modeling. To shift their perception that modeling is a marginally useful activity that precedes real development, to recognition that modeling is an important mainstream development task and not an activity primarily focused on documentation. When models are regarded as first-class development artifacts, developers write less conventional code since more powerful application abstractions can be employed."
"To summarize, we would recommend using UML and UML-based tools for:
* White boarding.
* Conceptual drawings that do not directly relate to code."
"You might think of Software Factories as encompassing and extending MDA, where MDA is defined in a broader sense than the official definition..."
As an aside: I guess this means that Microsoft's new official term towards the competition is "encompass and extend," rather than "embrace, expand, and extinguish."
Wednesday, September 06, 2006
At my present job we use it as a language for discussion with other developers. Basically so we all understand what is to be built. It does not go down to anywhere near the level of executable code, however.
Wednesday, September 06, 2006
I use it to nothing.
UML make artfacts that take time to read and understand. There´s a big lack from UML design to real knowledge about how class interoperate, despite state diagrams, use cases or whatever. UML don´t describe software concepts, just strutural stuff.
A dev that is fluent in OOA can do better building a 'forever' class and document it.
MDA is a joke. Just CASE tools recycled from the 1990's. I worked on a major defense system built from the ground up using MDA, i.e. create UML models, and script behaviors using 'Action Semantic Language'. In the end you got empty shell classes automatically generated from the UML, some behaviorial logic scripted with ASL, and all the real work was done by writing C++ code inline called from the ASL. Of course, this broke the whole point of the project which was to create a platform independent model that would generate platform specific code by just invoking the appropriate compiler. Basically the Leaky Abstraction problem. With the additional problem that visual diagmrams are much more difficult work with since the amount of screen space you need to view a complex model is huge, compared to the information density available with text. We had to purchase an industrial plotter that generated plots 5' across to even begin to understand some of the models.
I don't and I can't see any benefit to it. Sure I draw diagrams on big sheets of paper, but they capture a snapshot of the state or perhaps how things are chained together
Friday, September 08, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz