08/02/2010 01:59:08 PM EST

Could it be that the profession is lapsing into a bit of illiteracy? Declarative work--saying what you're going to do, then doing it--is probably a bit harder to do than imperative work (just go off and do it). And does Agile, mis-applied, promote imperative, model-less work? Let's not assume that things are always getting better. Maybe coders need a swift kick in the butt so get back to modeling before coding. http://www.CharlesHammell.com

United StatesCharlie

08/03/2010 09:44:17 AM EST

How can a language that has nothing to say about exceptions/error conditions (identifying, signaling/raising, handling) be taken seriously as an 'architecture description language'?

United StatesDavid Emery

08/05/2010 02:35:27 AM EST

1) 2 David: UML does have concepts for modeling exceptions/errors (Signal), their handling (Signal Reception) and you can precisely model on what conditions they are raised either within some behavioral models (activity, state machine or interactions). It is more the failure of UML books, tutorials, and other educational materials that do not cover this subject very well. 2) UML has grown too large - it contains 248 modeling concepts (meta classes), which is a much larger amount of elements than in programming languages like Java, C# or others. I have taught UML in a large variety of companies from 20 countries and my opinion is that the understanding of UML is very shallow. But even the bigger problem is changing developers' mindset - lots of people try to do the same programming in UML with the same level of details. If you do not raise the level of abstraction, UML is not better than programming languages. My opinion is that UML is called de facto standard, but in reality it is not applied very productively, which brings some disappointments, and probably that is why it has lost the buzz... There is still a lot of work in order to use the full potential of UML. I absolutely agree that UML has to be simplified in order to achieve more productivity in applying it. Dr. Darius Silingas Principal Trainer/Consultant @ MagicDraw darius.silingas@nomagic.com

LithuaniaDarius Silingas

08/06/2010 04:45:31 PM EST

Charlie, maybe it's management that needs the swift kick. I have known too many managers that believe coding is all that matters. So developers spend most of their time coding. This is evident by the number of defects coming out of system and integration testing. Without design, there is more rework coding that goes on. David, either you are not familiar with the current state of UML, or I don't fully understand what you are talking about. My use of Rational Software Architect includes exceptions/error conditions, signaling and event handling, among many other constructs.

United StatesKirk

08/09/2010 03:56:06 PM EST

UML has earned the branding of being a second design problem. It looks to me to be an incomplete Model-Based-Design language, as was stated in a previous comment. Give a more complete MBD language, you could concentrate on the architecture, and finally code could be generated. Not so with UML, it's just a partial solution.

United StatesJohn S Wolter

08/14/2010 08:35:17 AM EST

I have worked with many development teams ( naturally, not only did these involve developers), yet at each team I encountered a different perception of the UML concepts and sometimes even the members of one team had different expectations of how the UML can help them. UML is so complex that at least one part of it can be useful for virtually any project; provided you are careful enough in selecting just the right part. And that is the point; many people believe that just 'drawing diagrams' is the right way to do design, while others simply cannot understand that UML 'does not work' the way C Sharp or Java does. Incorporating the UML design into organization's SDLC requires a clever, iterative and managed process that should be evaluated regularly; once you get there, you get your why's and how's clearly stated. Martin

Czech RepublicMartinigue