Up Button in Font

Generation QR in Font Up Button

13. George T. Heineman and William T. Councill, Component-Based Software Engineering: Putting the Pieces Together (Boston: Addison-Wesley Professional, 2001, p. 308).

Connector diagrams have a certain similarity with circuit diagrams, modeling components as software integrated circuits (ICs) sporting input and output connection points. OMG later used the early style of Connector diagrams, with output arrows attached to lollipops, as the basis for the UML 2 Component Wiring diagram.

Summary

With so many different types of diagrams out there, you might think there is no room for improvement. UML certainly dominates the landscape of software diagrams, but many people are starting to feel that UML has gotten too complex that it is trying to solve too many problems at once. Is it a modeling language, a set of diagramming conventions, or a high-level programming language Depending on how you use it, it can be all three. When dealing with event-based designs, a circuitoriented diagram is often a good choice. Event notifications travel around the system like signals in an electrical circuit, so it makes sense to depict the system using the same kinds of concepts adopted in hardware diagrams. The next chapter is dedicated to a new kind of diagram developed specifically for event-based systems.

n this section, I ll show you a new type of software design diagram called Signal Wiring diagram, usually abbreviated as wiring diagram. This type of diagram depicts a system focusing not on the structure of its components and objects, but rather on the signals they exchange. Existing diagrams, such as UML Collaboration diagrams, Interaction diagrams, and Component Wiring diagrams, show how selected parts of the system are connected or interoperate, but sometimes those diagrams can be either too detailed or not detailed enough. Wiring diagrams rely on a hardware metaphor, describing the connectivity of a system in ways similar to hardware-schematic diagrams. They also act like maps, showing the itineraries that signals follow to go from one place to another. In digital systems, most functionality usually comes from integrated circuits (ICs). Wiring diagrams show objects and components in a role very similar to the ICs on schematic diagrams.

The notion of objects as software ICs is not new. In the early days of the object-oriented programming tide, it was recognized that objects might be used in ways conceptually similar to the integrated circuits used in the hardware world.1 The software IC idea was intuitive and widely publicized, but there were a number of problems at the time that were waiting for a solution. One problem was coupling between classes: Rarely were classes completely decoupled from others. If a class was coupled to others, then it represented an inseparable part of a larger system. To use a single class C1 that was coupled to others, say C2 and C3, you had to have C2 and C3. But C2 and C3 might have been coupled to other classes, which in turn might have been coupled to others. In the end, sometimes you were required to include an entire class framework into a design, even if you needed only one class in it. Another problem was that the event concept hadn t taken hold yet. At the time, there were no languages that natively supported what we would call events. Also, it wasn t clear what the software equivalent of an output signal was. The software IC concept was simply ahead of its time, and software ICs became another idea that came and went. Wiring diagrams resurrect Brad Cox s idea, showing objects as boxes with pins attached to wires. Obviously, the pins and wires are diagrammatic abstractions, but they are easy to understand conceptually, and the diagrams are easy to follow. The diagrams make no assumptions on exactly how pins are implemented.

1. Brad J.Cox, Object-Oriented Programming: An Evolutionary Approach (Boston: Addison-Wesley Professional, 1986).