Mechanical CAD and electronic schematic capture tools have been around much longer than graphical software tools.  This is primarily because physical objects are more naturally represented as components in a computer-aided design program, and it was more obvious how to design those technologies at the time. The “soft” in software modeling tools is what complicated their development.

Universal Modeling Language (UML) started to gain popularity over 15 years ago (first draft January 1997).  It has been used (and misused) by countless software engineers, over the years, for requirements capture, analysis, design, traceability, prototyping, simulation, documentation generation, and even code generation, among other things.  The introduction of a standard modeling notation, which could be used in software development, provided a common means to capture and communicate design information.  Standardization led to more rapid modeling tool development and accelerated the use of modeling in software development.

So, UML is a great thing, right?  Not so fast.  There are definitely drawbacks as well as advantages.  Learning the notation and its nuances has been a challenge to many including the idea of understanding how UML notation in design corresponds to the related code at the implementation level.  UML is like a Swiss Army knife, in that there are many different subsets of syntax and semantics within the notation, each with its own application focus (static structure, deployment, dependencies, artifact organization, reuse, functional analysis, dynamic analysis, etc.).  However, learning the syntax of the notation is not the least of the drawbacks.  Knowing what the tool does only brings you halfway there.  Learning how to effectively use the tool is a second obstacle.  Needless to say, adopting the use of UML in a development organization can be problematic if not done carefully.

Stay tuned for Part 2 of this entry to be available on Thursday.