Why Model?

In the context of software engineering, a model is an abstract diagrammatic representation of the form, structure, and intent of a software application using a standard notation. Typically, this standard notation is the UML.

It is not mandatory to use the UML for defining a model. However, the UML has become firmly established as the de facto standard for software modeling since it was first formalized by the famous trio of Booch, Rumbaugh, and Jacobson, collectively known as the three amigos.

Models make it possible to describe the pertinent aspects of a system's architecture clearly and accurately, and serve as a rich communication medium. Here are some of the things you can represent with a model:

• Understanding and describing the problem domain

• Software structure, organization, and constraints

• Object and component collaboration

• Information flow

• System state

• Database structure, organization, and constraints

• Packaging and deployment of the application components

Models offer a mechanism for communicating the system design to all members of the project and help build a common understanding of the system. They also assist in the process of validating the ability of the design to meet the customer's requirements.

Communication

Most people are familiar with models of one form or another. I'm not referring to software models but to the type more commonly built by children with a little help from a responsible adult, usually to prevent any serious damage with the modeling knife or to stop tiny fingers from becoming glued together.

Children build models because it is fun and educational. Moreover, they lack the skills and resources necessary build the real thing. My first such model was a reconstruction of a World War II Spitfire, constructed using a plastic modeling kit, a sharp knife, and some glue.

The finished model could be shown to school friends to explain how a real Spitfire worked. The model perfectly illustrated where the pilot sat, the location of the guns in the wings, and how the propeller spun and pulled the aircraft through the air.

When it comes to modeling software as opposed to toy aircraft, the same benefits apply. UML diagrams help construct low-cost models of the software and enable the communication of system design and behavior quickly, accurately, and succinctly.

Communication with the Customer

By modeling the system requirements, an analyst can convey to the customer his or her understanding of the business functionality the application must exhibit. A carefully constructed software model highlights any areas of ambiguity, thereby allowing them to be addressed during the initial stages of the development process with input from the customer.

Communication with the Project Team

When modeling the design of the application, the same benefits apply. A low-cost model of the design provides an excellent mechanism for communicating all aspects of the design to both customers and colleagues. With the UML, ideas and possible design solutions can be sketched out on a whiteboard where they can be readily discussed and refined among the design team.

A Common Vocabulary

In this manner, the UML serves as a common vocabulary for the effective communication of solutions. Representing designs in this format is a significantly faster process than producing reams of written documentation and is less ambiguous.

The benefits of the UML as a common vocabulary that can span language and cultural barriers should not be understated. Given the business practice of moving development work offshore, software engineers are finding themselves in the position of having to work as part of virtual teams, where team members are geographically remote. In order for this project structure to work successfully, accurate communication of technical information between team members and a common understanding of the system is imperative.

Validation

Children and software engineers are not the only people who build models. The practice is commonplace in the engineering profession. Going back to the example of the model aircraft, real aircraft designers employ a similar technique as part of the design process and build a mockup of the final aircraft.

The aircraft designer's model is made from a malleable material like clay and is built to prove the viability of a new plane's design. By placing the clay model in a wind tunnel, metrics can be obtained as to how the real plane will perform once it leaves the drawing board. In this way, the designer can get an early indication of whether the design meets the specifications for the plane in terms of speed, stability, and load-bearing qualities.

Software models provide the same benefits. UML interaction diagrams enable the software engineer to determine if the various components that make up the design are capable of collaborating in order to execute each of the system's use cases.

Design validation has two main benefits: it helps drive out risk, and it enables change on the project to be measured and controlled.

Driving Out Risk

Models are inexpensive to build. By being able to test a model early in the development process, the risk of a design failing to meet a significant customer requirement is drastically reduced.

Finding shortcomings in the software architecture later rather than sooner can be an expensive and time-consuming business. Though refactoring tools for making sweeping changes to the code are of considerable value, time savings can be made if the number of refactorings an application must undergo are kept to a minimum.

Controlling Change

Change is endemic to the software development process. A model is an effective mechanism for assessing the impact of any change on the design and hence the final system.

Like the clay models of the aircraft designer, software models are also malleable. We can update our model in light of the change and then revalidate the model. If it transpires that one of the use cases is no longer supported by the original design, then we can go back to the model and refine it further. Thus, the model can be used to experiment without the need to write lines and lines of code.

Models and Prototypes

Models are complementary to the development of prototypes on projects. Models can highlight areas of the system that require further investigation, thereby promoting the development of prototypes that target the major design risks to the system.