The following sub-sections discuss some of the limitations and weaknesses in both the overall strategy and the current implementation of the framework.
7.2.1
Concerns Related to Specifying Architectures
A fundamental aspect of the PANDArch approach is that its driver is a specification of the software architecture. This is expected because for any technique that checks architecture conformance, an architecture specification is the starting point. However, there are significant variations among languages, notations, and techniques employed for modelling software architectures. There also is the case where in practice architectures are often described informally and in diagrammatic form. Therefore, in these conditions, an immediate first concern is whether PANDArch is too tightly coupled with Grasp for the framework to be adopted in non-trivial software development. This concern is addressed earlier in the discussion related to achieving notation independence. While PANDArch is notation agnostic by design, the implemented framework can be considered coupled with the conceptual component-connector modelling paradigm adopted in Grasp. Modelling software architectures using discrete components connected through interfaces is a popular technique. Furthermore, the extracted architectures of the three open source systems in the earlier case studies show that component-oriented designs can be easily, if not loosely, implemented by a mainstream language like Java. However, other architecture paradigms such as service- orientation [163] are also popular in the industry, and being a generic conformance monitoring framework, PANDArch should extend support for these paradigms as well.
At the very foundation of the PANDArch approach are conformance rules. An important quality of conformance rules is that, although they are derived from some architecture property, the rules do not contain any architecturally significant information. A conformance rule specifies some constraint, dynamic or otherwise, that should hold only in the implementation, rather that in the architecture. The framework generates conformance rules for a number of architecture properties, but once created, the rules are independent of the architecture (except that they may refer back to corresponding architecture elements for error reporting purposes). As a consequence of this detachment, it should be possible to generate conformance rules for any architecture property (or concept), provided that such a property can be implemented by a programmer. Furthermore, new conformance rules can be introduced to support additional architecture properties. Therefore, it can be reasonably assumed that the design of PANDArch is not only independent of architecture modelling notations, but it is also independent of architecture paradigms. The conformance checker, which operates only on conformance rules, expects a rule generator capable of processing some architecture specification to extract the appropriate
7.2. LIMITATIONS AND WEAKNESSES 157
conformance rules from that specification. The conformance verification process from that point onwards remains unchanged. However, until the framework implementation has been extended with these capabilities and sufficiently evaluated, this assumption is treated as conjecture. Another challenge related to describing architectures is its lack of prevalence. As argued in Chapter 2, ADLs and other specification techniques are not well adopted in the industry [147]. One possible reason for this is the precision and the completeness required, when only a few architectural concepts are practised in the industry [147]. Furthermore, contemporary development methodologies such as agile techniques employ very little high-level design, and the design is continually refined as development progresses. In this context, PANDArch has the potential to motivate the adoption of architecture specifications as they could prove useful in conformance verification. Not requiring a full description of the architecture or accepting partial specifications could also make the framework useful for agile software projects.
7.2.2
Concerns Related to Implementation Mappings
Besides specifying the architecture of the target application, mapping elements in the specified architecture to programming constructs in the implementation is a crucial aspect of PANDArch. Without implementation mappings the framework has no means of checking whether the
implemented software conforms to what is prescribed in the architecture. With Grasp,
annotations provide the means for associating various mapping configurations with elements in the architecture. This approach complies with the principle of being specification-driven, where mapping information is required to be part of the architecture specification. However, embedding implementation mappings may not always be possible with other ADLs or architecture modelling techniques. They may not have a capability similar to Grasp annotations or other means to link architectural constructs to program code. Therefore, even if PANDArch offers an extensible design to deal with architectures modelled with notations other than Grasp, implementing this capability is likely to be challenging in some ADLs. A possible solution in such cases is to use another artefact to hold the mapping details needed for bridging the architecture and the implementation. However, doing so might require devising a new notation.
A shortcoming in the way PANDArch currently deals with implementation mappings is that it views the entire implementation as a logical entity. As a result, architectural concepts cannot be mapped to physical elements of the implementation. For instance, mapping a component in the architecture to a Java JAR file that implements the component is currently not possible. Instead the component in this case needs to be mapped to every class packaged within the JAR file. However, doing so may restrict the conformance checker from verifying the physical deployment constraints prescribed in the architecture, as information related to their physical deployment are
not available in Java classes. For instance, a Java class does not carry the name of the JAR file in which it has been packaged. Since verifying whether an implementation satisfies the physical constraints specified in the intended architecture is also important, the framework should be extended to incorporate this capability.
From a practical standpoint, embedding implementation mappings within an architecture specification could sometimes lead to readability and maintainability problems in the model. These issues could be particularly adverse with textual ADLs such as Grasp. Noise created by mapping descriptions can make the model harder to read and comprehend. An obvious solution to address this problem is to use modelling tools or special editors that filter out mappings in the specification when required. However, a larger related concern is the effort required for defining and maintaining implementation mappings. Updating these mappings has the potential to impose a considerable burden, particularly during the early stages of development when programmers develop code at a fast pace. The overhead required to keep the architecture mapped to the implementation under these conditions may discourage the use of PANDArch, and therefore remains a weakness of this approach.