Exemplary Design Deficiencies

Design Deficiency Problem

In component-based and service-oriented architectures, two components or services should exchange data only via data transfer objects. A transfer object is a data class that contains only the data that is needed for a specific task and no additional behavior. The only methods of a transfer object are getters and setters for the contained data.

In contrast to common practice in object-oriented programming, communication by exchanging objects which are not transfer objects should be avoided. This has two main reasons: First, passing an object reference to another component in order to allow access to that object’s data is a security risk and breaks its encapsulation. It inadvertently offers the receiving component the opportunity to invoke arbitrary methods of the exposed object. Second, as each component can be deployed independently, each method call may possibly be a remote call that incurs a significant communication overhead. Polling data by invoking a number of getters on a remote component can therefore be inefficient.

Thus, transfer objects should be used that can be filled with the relevant data and then be sent to the receiving component as a whole.

Example

Let us assume the convention that in this system all transfer objects should be marked by appending the suffix “TO” to their names. It consists of three components, Accounting, Controlling, and Store. The components Store and Controlling provide the interfaces IStoreQuery and IReporting which are both required by the Accounting component.

The system contains two Transfer Object Ignorance occurrences which are marked by labeled ellipses. Occurrence no. 1 is between the components Accounting and Store while occurrence no. 2 is between Accounting and Controlling. The Accounting component contains a class Assets which is able to calculate the total value of the items that are currently in store. To do this, the method calculateValue accesses the method getInventory of the IStoryQuery interface. In the example, this method returns an instance of the class Inventory which is then used to calculate the value of the stored items. This behavior of the example system constitutes an occurrence of the Transfer Object Ignorance design deficiency. By receiving an instance of Inventory, the Accounting component
cannot only access the data contained in the inventory object but it could also add and remove items from the inventory and call non-accessor methods like checkStock. Instead, the class StoreQuery should create a transfer object, populate it with data from the Inventory and return it to the Accounting component.

Occurrence no. 2 is another variant of the deficiency. Instead of a exposing an object by returning it, a non-transfer object is passed as a parameter. The Accounting component can send a Report to the Controlling component by calling the method sendReport of the class Reporting. Here, the Report object is passed to another component. Although Report looks very much like a transfer object, it lacks the appropriate suffix “TO”.

Reengineering Strategy

In order to remove the first Transfer Object Ignorance deficiency, the functionality could be moved somewhere else. Calculating the total value of all stored items should be the responsibility of the Store component. So the calculateValue method could be moved to the class StoreQuery in the Store component. Afterwards, it could be added to the interface IStoreQuery and all calls in the Accounting component could be redirected to this new interface method. This way, only the calculated total value would have to be sent to the Accounting component.
The other deficiency could be simply removed the adding the suffix “TO” to the Report class and thereby marking it explicitly as a transfer object. Note that every reengineering strategy has its pros and cons. Moving the behavior and extending the interface as described above removes the occurrence of the Transfer Object Ignorance deficiency. But extending the interface of course has an influence on every class that implements that interface. The software developers have to keep that in mind when applying this strategy.

Another possibility to remove this deficiency is to create a new data class for the transfer object, e.g., InventoryTO.
This would need attributes for all relevant data that is required by the Assets class. To find out which data is required, the reengineer would have to analyze the calculateValue method. Afterwards, the method getInventory would have to be adapted, to create an instance of InventoryTO, populate it with the necessary data and return it instead of the Inventory instance itself. Because analyzing which data is used by the Accounting component is very complex, it is hard to create an automatic transformation that performs this reengineering.

Design Deficiency Problem

Components in a good component-oriented architecture are supposed to communicate exclusively via their interfaces. Thus, if two classes are part of different components, they can only invoke operations of each other which are provided by their counterpart's interfaces. This leads to a good decoupling of the components. Only classes which reside in the same component can directly access each other's operations and attributes which results in a high coupling. If classes from different components invoke operations which
are not part of their corresponding interface, this is called an interface violation.

An existing interface violation has a direct impact on the architecture reconstruction. Two classes which communicate with each other in a way that violates their interfaces are strongly coupled. Hence, they are probably assigned to the same component by a clustering-based reverse engineering approach.

Example

As an example, consider the two classes Assets and StoreQuery. StoreQuery implements the interface IStoreQuery. If Assets only communicated with StoreQuery via IStoreQuery, Assets would be clustered into another component than StoreQuery. However, if A accesses the method getInventory() of StoreQuery which is not provided by IStoreQuery, it bypasses the interface. This leads to a direct coupling between Assets and StoreQuery, which consequently may be grouped together into the same component, even if they do not belong together conceptually.

Reengineering Strategy

There are several removal strategies to remove interface violations.

• As a first possibility, the interface IStoreQuery could be extended and the method call in calculateValue() can be modified such that the method provided by the interface is called and the class StoreQuery is not accessed directly. As a consequence, all other classes that implement IStoreQuery have to be adapted, too.

• Second, instead of extending IStoreQuery, a completely new interface could be introduced and accessed instead of the class StoreQuery. This way, other classes would not have to be adapted.

• Another way would be to simply remove the violating call. But this obviously results in a changed behavior of the system.

Design Deficiency Problem

In contrast to an interface violation, an unauthorized call is an invocation of an operation which is provided by an interface but which may not be called because the calling component is not connected to the called component.

In programming languages which do not explicitly support the concept of components, e.g., plain Java, it is easy to introduce unauthorized calls accidentally because strict interface communication is not enforced by the language. This is especially for component's that are connected by some interface. Developers may only remember that those components are connected somehow and may then introduce the unauthorized call.

Example

In the figure above, the components Accounting and Store are connected via the interface IStoreQuery. Thus, the method getInventory() may be called by classes in the Accounting component. The Accounting component, on the other hand, provides the reportOrder() method on its interface IPurchaseLog. However, this does not allow classes in the Store component,e.g., Inventory, to call reportOrder() because the Store component does not require that interface.

Still, developers may be tempted to call the method anyway, especially because the components are already connected. In the absence of component frameworks which prevent this, the deficiency may be introduced quickly.

Reengineering Strategies

Essentially, the Unauthorized Call deficiency is a special kind of Interface Violation. However, it is easier to remove. The called method is provided by an interface. So one reengineering strategy is to make the use of that interface explicit. If that is not desired, however, the call has to be removed and some other way to provide the functionality has to be conceived of.

Design Deficiency Problem

Inheritance relations between classes result in dependencies in the implementation and thereby lead to a tight coupling between the super class and the sub class. If the super class changes, then the sub class has to be changed, too.

According to the component definition by Szyperski, a "component is a unit of independent deployment". Therefore, such a dependency must not exist between classes that are part of different components. If one class is an extension of another, the components cannot be reused independently.

Example

In the example, the class StoreReport in the Store component extends the class Report in the Accounting component. Therefore, Store cannot be deployed without Accounting anymore.

Reengineering Strategy

In contrast to the other deficiencies presented here, there are no reengineering strategies for the Inheritance between Components deficiency. the placement of the classes in different components is a result of the automatic architecture reconstruction. Thus, something in the implementation of the system compelled the clustering algorithm to assign the classes to different components. This something, however, can be a combination of several reasons that ultimately influenced the clustering.

Therefore, the Inheritance between Components deficiency is not so much a design deficiency but it is a deficiency of the reconstructed architecture. Its occurrence can serve as a warning that the reconstruction may have made a mistake at that point and that the reconstructed components should be reviewed by the reengineer.