You still have time (until May 22) to influence in the development of the new version of the UML (UML 3.0).
Michael Jesse Chonoles (in the SysML forum mailing list ) has perfectly summarized what the OMG wants to hear about:
- How you currently use UML . And if you don’t why NOT?
- Desired uses OF UML . What doesn’t it do now for you — what do you have to tailor or misuse to get it work for you. What non-standard features do you depend on.
- Business case for change . Why would your suggested fixes help your organization? Would they help the spread of UML, MDA, SysML…Would they help the world of System / Software development?
- Advice on the scope (of applicability) of UML , e.g., what should be part of UML vs profiles. Is UML too large,too small. Are there too many dialects? Should UML be capable of representing only OO languages, any language? Should any sort of processor configuration be supported? Should programming features be separated from logical features? Should there be formal executable semantics?
- Technical evolution recommendations . Profiles, subsetting, packet merge,..
- Views on the process for changing UML Is a major 3.0 UML needed? When? Do we need a regression test suite? Would your suggested changes cause temporary havoc? Should we have separate dialects of UML for each programming language/purpose?
Responses may be from any organization (or individual) via the OMG RFI
process. You need not be a member of OMG. Responses may be on any of
the above areas (the more the better). More details here . As always, feel free to also give your opinion as a comment to this post. I’d love TO know your opinions ON this!.
My quick answer would be that I don’t see the need for a UML 3.0. In fact, I didn’t even need/want a UML 2.0. FOR the kind OF applications that I usually model (DATA-intensive applications) UML 2.0 did NOT provide ANY major contribution wrt the 1.5 (I think the ONLY new features I use ARE SOME OF the improvements IN the sequence diagrams) but it did ADD a lot OF “noise” (you just need TO compare the SIZE OF the official UML 2.0 superstructure AND infrastructure specification WITH that OF the previous version). So, please keep UML generic (FOR specific tasks/domains we already have DOMAIN-specific languages) but simple AND usable. If we want practitioners TO adopt the UML, we cannot give them a 700 hundred pages specification TO READ!.
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
UML 1 was way too loose for full semantic application generation, but it was really good for “up-front” modeling. UML 2 has much more semantic rigidity, enabling MDA-like approaches, but it has also become more complex and difficult to use.
There may be a need for a UML 3 that would better allow the complete modeling lifecycle, with relaxed semantics at the beginning and the possibility of tightening these as you progress through the lifecycle. Basically, the ability to have a low-semantic, “sketching” capability and defined routes to drive to a higher semantic model that could be used to generate applications.
Perhaps fantasy?
I like your point of what I’d call different compliance levels FOR UML models. AS an example, consider the use OF sequence diagrams. AT the beginning I just want TO sketch SOME interaction scenarios (AND thus, FOR instance, I don’t care if the messages between the objects correspond to existing operations in the classes). Later, I may want to have a perfectly consistent sequence diagram, where all the messages and parameters match the operations’ signatures
IN my opinion UML provides different models FOR different purpose.
For high LEVEL interaction AND relationship modeling use Use Cases.
For detailed processes but limited interaction modeling the activity diagrams ARE great.
For detailed interaction you want TO use sequence diagrams.
There are enough companies out there who have not adopted the basics of modern software development. A more complicated UML standard won’t help that, but lead TO the fact that less companies will use the standard.
The OMG needs TO focus ON broaden the USAGE AND adoption OF the 2.0 standard. Just a few people need a 3.0 standard. But if the community gets smaller AND smaller it IS NOT worth it.
Also the tools should extend their adoption of the UML 2.0 standard. Many of them still ignore some of the UML 2.0 constructs (well, even some of the UML 1.0 elements).
Guys, let’s admit that UML was a complete failure. People who designed UML never looked at the problem(s) they were supposed to solve. They never looked at providing the semantics that people need to do their day job better.
With UML you can’t create an effective representation of:
– information models (CIM, mappings, identity, …)
– business entity lifecycles (WTF, no action in a state diagram?)
– sequence diagrams can’t effectively represent orchestrations
– message formats (WTF, UML has no concept of projection (to project an information model into a message format)?)
– systems (PowerPoint is better)
– requirements
– test cases (BDD)
UML should focus at a minimum on “visualizing” code if it can’t be helpful in the design phase.
Total waste of people’s time.
> business entity lifecycles (WTF, no action in a state diagram?)
What do you mean by “action” here, Jean-Jacques? State machines can definitely have blocks of behavior composed of actions.
> information models (CIM, mappings, identity, …)
I actually find UML ability for modeling information to be great, if not perfect. What exact limitations are you missing?
Sometimes I think I am the only person that actually likes UML. As a programmer that appreciates being able to model a domain with proper language support for key concepts such as associations, state machines, constraints, events (which usually need to be emulated in other languages), I think UML is the best “conceptual programming”/”detailed modeling” language around. I am not saying it is perfect, just that currently there is no better alternative (see also: http://blog.abstratt.com/2010/02/08/uml-may-suck-but-is-there-anything-better/).
Yes, I understand that it is buried “someware” in the UML metamodel, but I have never seen a tool, let alone a single state diagram where actions where associated to transitions.
It’s pointless to discuss whether it is good or bad. The only discussion we should have should be around the problems UML solve:
– what are the problems that UML solves well?
– what are the problems that UML attempts to solve, but fails to?
– what are the problems UML must/should solve but doesn’t?
(executable UML being the most insane attempt to solve a problem that nobody needs to be solved)
> I have never seen a tool, let alone a single
> state diagram where actions where associated to transitions
Here goes an example:
http://www.stickyminds.com/article/state-transition-diagrams
Many more examples:
https://www.google.com/search?q=state+diagram+action+transition&tbm=isch
> The only discussion we should have should be around the problems UML solve
The problem is UML has the most diverse target audience any software language will ever have. The answers to those questions will be radically different depending on what camp you are coming from.
Case in point:
> (executable UML being the most insane attempt to solve
> a problem that nobody needs to be solved)
Executable UML models solve the *primary* problem people in *my* camp need solved (even if not all may realize): proper separation of concerns and level of abstraction in application development. For that, there is only one other game in town: DSM.
So, IMO, what UML (or its replacement) needs is to become a family of much smaller specialized languages which are easily composable.
Clarification on Orchestration/Choreography (as requested)
In a world driven by APIs sequence diagrams are very useful. However, very often there will be at least one component (but often several) that will orchestrate all the other (atomic) APIs.
It would be really useful to allow people to create sequence diagrams that include a view of these orchestrations (within one lifeline). The sum would be a choreography + orchestration. That roughly amount to combining an activity diagram (for the orchestration) with a sequence diagram.
I have documented that pattern as far back as 2002: http://www.ebpml.org/epbml2.2.doc, it’s everywhere today.
In the end that’s the fundamental problem of UML: a combination of bloated semantics, hard to learn, impossible to use and a visual partition of these semantics in diagrams that are vastly incomplete to convey designs with the precision that would be required.
In the end people will realize that UML is an M3 not an M2. Tool vendors should use UML as constraint to the tools they create to help people do their job better. UML in itself is not appropriate to create tools. I believe it should be clear to any software professional today, unless you are emotionally or financially attached to it.
There’s an upcoming webniar coming up by the OMG some of you might be interested in
https://www.brighttalk.com/webcast/12231/246845?platform=hootsuite