Unified Modeling Language

The Unified Modeling Language (UML) is an industry-standard notation used to communicate and capture the essence of a project's requirements and ultimately the design which is reflected in source code. It allows us to abstract away detail into a set of enterprise, application, and integration models.

uml_logo It also allows us to specify detail to produce design models. The semantic gap between UML and modern programming languages is now so small that many UML diagrams are able to represent compilable source code. This allows integrated development environments to provide round-trip engineering, which means, when you are modeling you are coding and when you are coding you are modeling. The standardization, acceptance and application of UML has played a major role in legitimizing software development as an engineering discipline.

By analogy the UML is to a software engineer what schematics are to an electronic engineer or blueprints to a civil engineer. The UML provides all stakeholders from the business analyst to the software architect to the programmer a common vocabulary for building and maintaining software systems.

The UML is very rich and comprehensive in scope. Therefore, it is important to apply careful judgment to only produce diagrams and diagram artifacts that are essential to the ultimate goal: deploying quality software on a production system. Remember that design is merely a means to an end, not an end in itself.

In mapping the problem space (place where the problem exists) to the solution space (place where you are modeling the problem - normally a computer) we must abstract away anything that does not impact the requirements of the incremental release under development. This concept is used by electronic engineers to linearize non-linear behavior in order to simplify the solution. For example, in circuit design the physics in the problem domain dictate the presence of parasitic inductance and capacitance effects between adjacent components. These effects must be taken into account at high frequencies. However, when designing a low to medium frequency circuit to regulate say, the case temperature of a laser diode, an engineer would not include these parasitic components in the schematic diagram since their effect is not important to the solution. Hence, what would normally be a very complex problem to analyze and design is made simple by neglecting unnecessary detail.

It is sometimes difficult to judge what must be modeled and what not. Basically, the more complicated the problem the more critical the need for communication between business, designer, and programmer. When in doubt, don't create the model or if the model already exists, don't add more detail. Just move on to the next task in the priority list. If, when in the implementation stage, the programmer (which could also be the designer) is trying to figure out what to build while programming (i.e. hacking), then you have your answer - go back to the architecture model and complete the missing detail.

Unified Modeling Language

Summary