Be Realistic About the UML: It's Simply Not Sufficient

The Unified Modeling Language (UML) defines the industry standard notation and semantics for properly applying that notation for software built using object-oriented (OO) or component-based technology. In fact it is difficult to find modeling books or tools that do not use the UML these days. The UML provides a common and consistent notation with which to describe OO and component software systems, decreasing the learning curve for developers because they only need to learn the one modeling language (in theory at least). The UML is clearly a step in the right direction, we are no longer fighting the “notation wars” of the mid-1990s, it isn’t perfect. In this article I argue that the UML as it stands today is not sufficient for the development of business software and that the vision of Executable UML is a little (okay, a lot) ahead of its time. Perhaps we should define the modeling languages which we use via open source, not via committee.

Be Realistic About the UML: It's Simply Not Sufficient

UML,. If you are not using it now you need to use it in the future. The best tool for organising you mission in IT

Google Image Result for http://www.agilemodeling.com/images/style/useCaseOnlineShopping.gif

This is the best UML book I have ever seen

Get more data here at UML 2 Use Case Diagramming Guidelines

UML 2 Use Case Diagramming Guidelines


Most people I have worked with don't generally use UML and that is a shame. Perhaps the simple drawing seems childish, perhaps the simple elegance of this mathematics of clear thinking confuses people. Yes requirements gathering, analysis and design can be this simple.

Look at the document up top. To many people this would simply seem like pointless truisms about a profess. And that is precisely what they are, and once you and the stakeholders have agreed the process can be quickly fixed in to a contract of business requirements. Requirements which can rapidly be converted to technical solutions.