Consider a car company that is specifying the information display system for several car models. The company plans to use a wide range of features from the basic speed, engine rotation, and temperature indicators to parking cameras, a GPS system, and so on. Our example will cover three different models, from the low to the high end version of a information display system.
5.2.1
Structural model in UML 2.0
Our example will be presented in UML using component diagrams, one for each of the three component assemblies that correspond to the three car models. Before describing
in some detail the different component assemblies, we start by a quick remark on nota- tion. In these component diagrams, some interfaces are decorated with the <<event>> stereotype, to represent produced and consumed events. So, for example, in compo- nent assembly A (5.1), Clock produces a TimerTick event which is then consumed by the LED_Display and the Engine components. Other specification formalisms, such as the CCM have specific model elements for expressing this concept, but that is not the case with UML 2.0.
Figures 5.1 through 5.3 present the configurations used, from the lower-end car model, to the higher-end one.
Assembly A (figure 5.1) uses a LED (Light-Emitting Diode) display, with the typical instruments of a car: a velocimeter, a fuel gauge, a coolant temperature gauge, engine warning lights, and a clock. To keep our example small and simple we will assume that:
• there is a Clock component providing all the time information required by the assembly;
• the Engine component wraps all the car engine diagnosis instruments;
• these components neither provide, nor require, any additional interfaces, other than those presented here.
Figure 5.1: Low-end car model configuration (assembly A)
Assembly B (figure 5.2) is similar to assembly A, except for the display component. Rather than a LED-based instrument panel, assembly B uses a colored TFT LCD(Thin Film Transistor Liquid Crystal Display) video display. All the information made avail- able to the LED-based instrument panel can also be displayed with the video display. However, the video display has a higher flexibility with respect to the information it can present. It can be connected to a GPS (Global Positioning System) device, through its required Location interface, to an external device, such as a DVD (Digital Versatile Disc) player, through the ExternalDevice interface, to a Terra Trip device (a device often used in vehicles to allow a detailed registration of distances traveled by the vehi- cle during all-terrain competitions), through the TerraTrip interface, and to a parking camera (used to help parking the car, through the Camera interface. In assembly B,
although the video display supports all the above mentioned interfaces, it keeps on using only the same sources of information as in assembly A.
Figure 5.2: Middle-range car model configuration (assembly B)
Assembly C (figure 5.3) keeps the characteristics of assembly B, and adds to them the usage of some of the devices which can be plugged in the Video_Display compo- nent. In particular, it integrates a GPS device, as well as a parking camera.
Figure 5.3: High-end car model configuration (assembly C)
Figure 5.4 presents the interfaces used in our car model examples. The details of these interfaces, concerning how adequate they would be in reality, are not particularly relevant for our discussion, as we are only interested in measuring some properties of those interfaces.
The TimerTick interface only has one method, and is used for the sake of the Clock component firing a timing event to be consumed by other components. The Time in- terface has a set of typical operations on a data type representing time in terms of
year, month, day, hours, minutes and seconds. The Diagnostics interface condenses the information made available by the car engine, such as current speed, engine ro- tations, oil level, temperature and remaining fuel. The Location interface is used for geo-referential information. The Camera interface is used for video streaming, so that a parking camera can be connected to the vehicle and the images captured by the camera can be displayed to the driver. The ExternalDevice interface extends the basic Camera interface with the operations required for video playback. Finally, the TerraTrip inter- face allows the connection of a Terra Trip device.
Figure 5.4: Interfaces used in our car example
5.2.2
Structural model, in CCM
Figures 5.5 through 5.7 present the component assemblies of our three different car models. With the exception of a few notation details, when compared to their UML 2.0 counterparts, they are essentially similar. Note that, unlike what happens with UML 2.0, the CCM has a specific notation for representing events in these diagrams.
Figure 5.6: Middle-end car model assembly, in CCM
Figure 5.7: High-end car model assembly, in CCM
In this component model, the interfaces are defined using a Common Interface
Description Language (CIDL). Listing 5.1 presents the definition of the ICamera in- terface, for illustration purposes. All these interfaces are essentially similar, in what concerns their signature, to those presented earlier for this example in UML 2.0 (see figure 5.4). As with the UML 2.0 assembly description, the existence of an Image type is assumed, rather than modeled here.
Listing 5.1: ICamera interface, in CIDL.
i n t e r f a c e I C a m e r a {
void s e t F r a m e R a t e ( in int fr ); void s e t H R e s ( in int res ); void s e t V R e s ( in int res ); int g e t F r a m e R a t e ();
int g e t H R e s (); int g e t F r a m e R a t e (); Image g e t C u r r e n t F r a m e (); }
5.2.3
Concerns addressed in our example
• In component-based development, available components often do not exactly match the requirements they are to fulfill, either because they lack functionality, or because they have functionalities that are not used by the assembly they are put into. The question we will try to answer is how well do the components fit into the component assembly, with respect to the actual usage of their interfaces. • The complexity of interfaces, either provided or required, varies significantly. This may have an impact in the usability of components, from the component in- tegrator’s point of view. An over-simplistic interface may be easy to understand and use, but lacks the flexibility for allowing a high level of customizability of the component. Conversely, a complex interface may provide that flexibility at the expense of the interface’s understandability.
The architectural mismatches between available and required resources may result in two kinds of problems:
• The functionalities required by the components will not be fully available. In our example, this is mostly noticeable in assembly B, where the video display supports several other devices, which are not present in this assembly.
• Some functionalities provided by the components in this assembly are not used. If these components were not to be reused in other assemblies, this would imply that effort would have been spent in the developed of unused functionalities. In our examples, all provided interfaces are required by at least one component. With respect to the complexity of the interfaces, we deliberately kept them fairly simple, to facilitate comparison. We used an inconsistent naming policy in one of the interfaces (Time) by using different names for, essentially, the same arguments. As such, day, month, and year, in the setCurrentDate method correspond to newDay, newMonth, and newYear, in setDay, setMonth, and setYear, respectively. This will allow us to explore how one of the metrics used in this chapter can help developers to detect such inconsistencies.