Breaking through the software - system communications barriers

image

Figure 1

Modeling languages have struggled to gain traction across most software engineering teams. In an article on why more developers don't use these modeling languages, Paulo Merson, of the SEI, asks: "Do you want settle for a programming job anywhere, or work for Google on the Android team?". "Bubbles don't crash" is a famous phrase from Bertrand Meyer, which means you'll still have to be good at coding your design. have trouble switching back and forth between the language and the code which implements it.

Such languages help systems and software engineers improve their design at a modular level, since a design process should focus on the important abstractions for the system of interest, and leave out the tedious details for as long as possible. These languages aren't silver bullets, serve to communicating a well-formed set of views necessary to achieve some defined purpose. UML class diagrams show easily how coupling is reduced in a design after applying a design pattern (and these patterns are usually documented with UML). I'd postulate it's going to be harder to use OO design patterns in a team if you don't know UML. But these patterns are still only a model.

Developers struggle to balance the time they have available to model levels and layers. Working at different levels of abstraction is hard, and concerns about pouring too much energy into abstractions (which may result in delaying the start of coding) won't help a business ship version 1.0. You might possibly lose your job if you don't produce enough code that actually runs. So, because of market pressures, the difficulty of the task, and lack of easy-to-use (and affordable) tools, modeling and design go by the wayside. Once this behavior gets institutionalized into a cultural pattern, it becomes a rut that's hard to get out of. That doesn't mean modeling won't be useful or isn't needed. But the halls of academic institutions and the cultures in dev shops don't react very quickly to such shifts.

As the industry sought to establish a Universal Modeling Framework way back in 2008, Jeff Grady noted the industry had been 'tremendously creative' in inventing new models and frameworks. Unfortunately, industry's effectiveness in integrating and applying these approaches has been rather limited.  He pointed out then that there was no single language (let alone framework) from which all properties necessary for good modeling can be derived. This has led to many different efforts to facilitate system integration.

An example may illustrate how the misuse of a modeling constructs can create a vicious, rather than virtuous, cycle. Consider the differences between compositions and aggregations by examining the relationships between the geometric constructs of circles and points. Circles can be represented in terms of a center coordinate and a radius. If a modeler defines a circle instance, the fact that its center is involved may be encapsulated, or hidden when a new instance of a circle was created. The part created by this new instance would have both the circle as a whole, and its center as an encapsulated element of each circle. This encapsulated center instance would only be useful within the context of its containing circle instance. 

If a modeler defined a circle instance, the fact that a point was involved may be encapsulated, or hidden when a new instance of a circle was created. The part created by this new instance would have both the circle as a whole, and its center as an encapsulated element of each circle. This encapsulated center instance would only be useful within the context of its containing circle instance. If an instance of a circle was destroyed, its center would no longer have relevance. This type of association is a composition. In such compositions, the whole is the 'owner' of its parts. The whole creates and destroys the part. A part has no use outside the whole.

If an instance of a circle was destroyed, its center would no longer have relevance. This type of association is a composition. In such compositions, the whole is the 'owner' of its parts. The whole creates and destroys the part. A part has no use outside the whole. The constructs are important are other circumstances when an entity's existence is independent of the lifecycle of it's parts. In this case we have an Aggregation. How the whole handles the life cycle of its parts is what differentiates aggregation from composition: In the composition relationship is the whole the one that creates/destroys its parts instances, while in the aggregation relationships the whole just uses the part (no creation/destruction involved).

Programmers often use tools like Visio to draw lines and boxes, and make up their own notational conventions. Unfortunately, Visio will let you draw a line between objects, regardless of whether such a connection can be made. Behind the scenes, Visio draws lines and objects with stensils; each object . office layout, detailed shapes for site plans, updated shapes for floor plans, modern shapes for home plans, IEEE compliant shapes for electrical diagrams

Circles are defined in terms of their radius and their center coordinate.

Unfortunately, no clear consensus on a framework for these models has emerged. As a result, each tool vendor implementing such constructs is challenged to present a distinctive interface to perform this chunking. UML has implemented style guidelines for logical architectures, whereas each individual tool vendor has its own recommended workflow. 

Rating: