Slashdot Mirror
How Do You Use UML?
christophe.vg asks: "We are currently investigating the feasibility of a new (open source) 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?"
Please folks, especially if you're doing an ask slashdot, try to either expand your TLA's early on or make them clear from early context. Until I got to the end of the blurb I thought this was about user mode linux...and now, of course, I have no idea what it is. Background links welcome.
(this should answer the question of how I use UML...)
The only time I see formal UML is when it is generated by a reverse engineer tool that spits out UML for what has actually been coded.
If there were some actual useful UML tools I might use it a bit more, but as it stands I don't much care for any of the diagraming tools that are available.
[Set Cain on fire and steal his lute.]
It stands for "Three Letter Acronym."
-30-
Actually there is no such thing as a "calling convention" in assembly itself. In x86 machine code a call is pushing the instruction pointer to the stack and jumping to the adress of desired function. I guess it's about the same in other machine codes (anybody know?)
Deciding how to pass the parameters and the return code (the important things about a calling convetion) is up to the compiler. This can happen on the stack, in registers etc. in any order.
This is why you have to use such things as __declspec in Windows. It says "This function expects its parameters to be on the stack, in the order they apear in the declaration and puts its return value in eax". The C compiler knows what to do then but assembly is to low level to give a damn.
We know from history how well calling conventions are adhered to
They are adhered to very well when provided at the operation system level very poorly when left as an option. VMS being a great example where calling conventions and complex datastructures are defined at the OS level. The result is that a C function is callable in Cobol, VAX Basic, Fortran... and vice versa.
Do you have a clue? Few hours a week doing anything for 5 months doesn't get much done. Believe me.
I am currently a software technical lead at a well-established avionics company and have been involved with many UML-related discussions, training classes, meetings, and FAA certified projects, in addition to smaller at-home PC-based projects. I have taught UML and the Unified Process in house for more than a year and have also read and applied many of the key books on object-oriented design, business modeling, use-case modeling, the Unified Modeling Language (UML), and the Unified Process. I've seen and used UML used in quite a variety of ways (pc game, web-based genealogy database, quality system business modeling, embedded product design, embedded graphics driver design), with a variety of goals in mind, with engineers ranging from hardcore embedded avionics guys to throw-it-together PC app developers. On some projects UML has been very successful, and on others it has failed, but before I mention why, let me first address a misconception I've seen as I've read the posts above.
Many engineers new to UML mistakenly think that the UML dictates a process. However,
The UML is not a process, it is a modeling language
In other words, it isn't UML that dictates the activities and process of your software development. That is instead the job of a process like the Unified Software Development Process, or the standard waterfall, or rapid prototyping, or Extreme Programming, or DARTS/CODARTS, or structured analysis & design, or some other customized process. UML is a language for capturing the models and views of a system independent from any process your project may choose to follow. A process (such as the Unified Process) will customize and extend the available UML modeling elements and define the activities and resources necessary for developing those models. So, when you are having process issues (such as using too much of the UML or fleshing out too much design before starting implementation), don't assume that it's the fault of the UML--it is probably instead the result of a bad choice of development processes.
Strengths and Weaknesses of the UML
From my experience, UML excels at specifying requirements, documenting high level design, describing both the static and dynamic architecture of the system, highlighting core structures and key interfaces, bridging the gap between requirements and design, bridging the gap between business modeling and application design, bridging the gap between database design and application design, and facilitating communication between software developers and the users of the system. (I've actually used it in all of these ways.) UML encourages engineers to think through the problem before hacking together a solution. This doesn't mean that the design should be set in stone first. The requirements and design can and will change, sometimes significantly, over the course of a project. However, I've seen enormous gains in both quality and efficiency when the project team has done a prelimary design of the core structures first in UML, then tried to code them up in C++, learned more about the problem, revised the design in UML, then tried again. Sure there's a cost to documentation but it's cheap relative to the cost of getting the design wrong in C++. One last strength--UML is capable of supporting the development of a multiple layered system, even when that system spans business processes, multiple embedded products that must be integrated together, individual cards with separate software in those products, the layered subsystems in those cards, and on down as far as you care to go. Few if any other modeling languages could say the same.
UML is not so good at documenting low level design except when a certain complex key area needs to be discussed in depth with multiple engineers; "self-documenting" code with appropriate comments is much better at documenting low level design. I have also not seen much use yet for node or component diagrams.
In all the projects I've worked on from avionic