Critiques for A Classification and Comparison Framework for Software Architecture Description Language

A Classification and Comparison Framework for Software Architecture Description Language

This paper is about a “Classification and Comparison framework for ADLs”, which definitely provides a fair list of categories for comparing features, usability and usefulness of ADLs, in lieu of both general purpose requirements and special needs.

·          However, I seriously like the idea that the framework talks about comparing characteristics of frameworks that do perhaps not exist in many ADLs but have been identified in the literature as useful asset to architecture-based-development like traceability and refinement.

·         Besides all the positive points as mentioned by author about the framework, its criticism of “Clements’s strategy for using tool support and requirement’s modeling as classification criteria, is in contradiction to the features of the proposed framework i.e. ”Tool Support” and “ Understandability + Non-functional properties”.

·         The paper clearly differentiates ADL’s from other languages like UML, formal semantic theory like Z notation, State Charts, etc. clearly justifies the need for ADL.

o   For example, one can use extensions in UML but it would be highly unrealistic to model every aspect of ADL in UML as the abstraction provided by this design tool can actually raise components and connectors to top-level abstractions where as per the definition of ADL we propose to see only system level modeling and abstractions.

o   State charts does not model architectural configuration and “topology” by state charts can only be determined by studying its constituent components.

·         Overall, the way paper is categorized to include each and every aspect of ADL’s specification and properties like connectors, and reasons of inclusion and support of those categories (like in-line connectors don’t support evolution and semantics) is an abundant source of information for an architect who can pick and choose from these ADL’s as per the problem domain’s requirements.

·         The paper can act as a quick chart for a mid-level to experienced architect and as a starting point for igniting the thought process of evaluation of existing ADL’s to choose from.