Features of Architecture Description Languages

Abstract

The characteristic approach in mature engineering disciplines (e.g. civil and chemical engineering) is to build systems (e.g., buildings or chemical plants) from known solutions such as proven designs and existing components [Shaw90,D'Ippolito89]]. Engineers in mature disciplines also put great emphasis on proactively avoiding costly problems by evaluating the system before it is built [Liu87]. Models of the system's architecture are important tools for applying known solutions and doing early evaluation in mature engineering disciplines. In software engineering, the corollary is modelling the software architecture. By software architecture, we mean the components into which a system is divided at the level of system organization, and the ways in which those components communicate, interact, and coordinate with each other [Garlan93] [Shaw95]. Examples of components include modules, processes or tasks, subsystems, Ada packages, or Unix filters. Examples of coordination mechanisms include procedure call (remote or otherwise), synchronization (e.g., rendezvous), data sharing, message passing, event broadcast and subscription schemes, and Unix pipes. The architectural view of a system separates the concerns of components' functionality (or computation) from the ways in which components interact to cooperatively perform the system's job (or coordination). The architecture represents the first mapping from requirements to computational components and, hence, it becomes possible, at a high level, to evaluate the feasibility of achieving the requirements with the proposed design. In addition, architectural decisions represent substantial resource commitments. The selection of components and connections, as well as the allocation of functionality to each component, is a codification of the earliest design decisions about a project. Thus these decisions are the hardest to change. The choice of components is institutionalized in developing organization's team structure , work assignments, management units, schedule and work breakdown structures, integration plans, test plans, and maintenance processes. Once it is made, an architectural decision is extremely difficult to retract. In addition to its organizational implications, an architecture can either permit or preclude the achievement of most of a system's targeted quality attributes. Modifiability, for example, depends extensively on the system's modularization, which in turn, reflects the encapsulation strategies. Likewise reusability of components depends on how strongly coupled they are with other components in the system. In addition performance depends largely upon the volume and complexity of intercomponent communication and coordination, especially if the components are physically distributed processes.