Abstract
Software architectures shift the focus of developers from lines-of-code to coarser-grained elements and their interconnection structure. Architecture description languages (ADLs) have been proposed as domain-specific languages for the domain of software architecture. There is still little consensus in the research community on what problems are most important to address in a study of software architecture, what aspects of an architecture should be modeled in an ADL, or even what an ADL is. To shed light on these issues, we provide a framework of architectural domains, or areas of concern in the study of software architectures. We evaluate existing ADLs with respect to the framework and study the relationship between architectural and application domains. One conclusion is that, while the architectural domains perspective enables one to approach architectures and ADLs in a new, more structured manner, further understanding of architectural domains, their tie to application domains, and their specific influence on ADLs is needed.
Keywords - software architecture, architecture description language, domain, domain-specific language, architectural domain
Contents
Software architecture is an aspect of software engineering directed at reducing costs of developing applications and increasing the potential for commonality among different members of a closely related product family [PW92, GS93]. Software development based on common architectural idioms has its focus shifted from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. This enables developers to abstract away the unnecessary details and focus on the "big picture:" system structure, high level communication protocols, assignment of software components and connectors to hardware components, development process, and so on.
Many researchers have realized that, to obtain the benefits of an architectural focus, software architecture must be provided with its own body of specification languages and analysis techniques [Gar95, GPT95, Wolf96]. Such languages are needed to demonstrate properties of a system upstream, thus minimizing the costs of errors. They are also needed to provide abstractions adequate for modeling a large system, while ensuring sufficient detail for establishing properties of interest. A large number of architecture description languages (ADLs) has been proposed, each of which embodies a particular approach to the specification and evolution of an architecture. Examples are Rapide [LKA+95, LV95], Aesop [GAO94], MetaH [Ves96], UniCon [SDK+95], Darwin [MDEK95, MK96], Wright [AG94a, AG94b], C2 [MTW96, MORT96, Med96], and SADL [MQR95]. Recently, initial work has been done on an architecture interchange language, ACME [GMW95, GMW97], which is intended to support mapping of architectural specifications from one ADL to another, and hence provide a bridge for their different foci and resulting support tools.
There is still very much a lack of consensus in the research community on what an ADL is, what aspects of an architecture should be modeled by an ADL, and what should be interchanged in an interchange language. This divergence has resulted in a wide variation of approaches found in this first generation of ADLs. Perhaps even more significantly, there is a wide difference of opinions as to what problems are most important to address in a study of software architecture.
In our previous research, we have provided a foundation for understanding, defining, classifying, and comparing ADLs [Med97, MT97]. In this paper, we build upon those results by identifying and characterizing architectural domains, the problems or areas of concern that need to be addressed by ADLs. Understanding these domains and their properties is a key to better understanding the needs of software architectures, architecture-based development, and architectural description and interchange. A study of architectural domains is also needed to guide the development of next-generation ADLs.
This paper presents a framework of architectural domains. We demonstrate that each existing ADL currently supports only a small subset of these domains, and we discuss possible reasons for that. Finally, we consider the relationship between architectural domains and application domains.
While we draw from previous ADL work and reference a number of ADLs, the most significant contribution of this paper is the framework of architectural domains. It provides structure to a field that has been approached largely in an ad-hoc fashion thus far. The framework gives the architect a sound foundation for selecting an ADL and orients discourse away from arguments about notation and more towards solving important engineering problems.
The remainder of the paper is organized as follows. Section 2 provides a short discussion of ADLs. Section 3 presents and motivates each architectural domain, while Section 4 discusses the support for architectural domains in existing ADLs. Section 5 expounds on the relationship between application domains and architectural domains. Discussion and conclusions round out the paper.
To properly enable further discussion, several definitions are needed. In this section, we define software architectures, architectural styles, and ADLs.[Footnote 1] We categorize ADLs, differentiate them from other, similar notations, and discuss examples of use of ADLs in actual projects. Finally, we provide a short discussion on our use of the terms "architecture" and "design."
2.1. Definitions of Architecture and Style
There is no standard definition of architecture, but we will use as our working definition the one provided by Garlan and Shaw [GS93]:
Loosely defined, "an ADL for software applications focuses on the high-level structure of the overall application rather than the implementation details of any specific source module" [Ves93]. ADLs provide both a concrete syntax and a conceptual framework for modeling a software system's conceptual architecture.
The building blocks of an architectural description are
An ADL's conceptual framework typically subsumes a formal semantic theory. That theory is part of the ADL's underlying framework for characterizing architectures; it influences the ADL's suitability for modeling particular kinds of systems (e.g., highly concurrent systems) or particular aspects of a given system (e.g., its static properties). Examples of formal specification theories are Petri nets [Pet62], Statecharts [Har87], partially-ordered event sets [LVB+93], communicating sequential processes (CSP) [Hoa85], model-based formalisms (e.g., CHemical Abstract Machine [IW95], Z [Spi89]), algebraic formalisms (e.g., Obj [GW88]), and axiomatic formalisms (e.g., Anna [Luc87]).
Finally, even though the suitability of a given language for modeling architectures is independent of whether and what kinds of tool support it provides, an accompanying toolset will render an ADL both more usable and useful. Furthermore, capabilities provided by such a toolset are often a direct reflection of the ADL's intended use.
The focus on conceptual architecture and explicit treatment of connectors as first-class entities differentiate ADLs from module interconnection languages (MILs) [DK76, PN86], programming languages, and object-oriented notations and languages (e.g., Unified Method [BR95]). MILs typically describe the uses relationships among modules in an implemented system and support only one type of connection [AG94a, SG94]. Programming languages describe a system's implementation, whose architecture is typically implicit in subprogram definitions and calls. Explicit treatment of connectors also distinguishes ADLs from OO languages, as demonstrated in [LVM95].
It is important to note, however, that there is less than a firm boundary between ADLs and MILs. Certain ADLs, e.g., Wright and Rapide, model components and connectors at a high level of abstraction and do not assume or prescribe a particular relationship between an architectural description and an implementation. We refer to these languages as being implementation independent. On the other hand, several ADLs, e.g., UniCon and MetaH, enforce a high degree of fidelity of an implementation to its architecture. Components modeled in these languages are directly related to their implementations, so that a module interconnection specification may be indistinguishable from an architectural description in such a language. These are implementation constraining languages.
ADLs are special purpose notations whose very specific foci render them suitable for powerful analyses, simulation, and automated code generation. However, they have yet to find their place in mainstream software development. Although current research is under way to bridge the gap that separates ADLs from more widely used design notations [RMRR97], only a small number of existing ADLs have been applied to large-scale, "real-world" examples to date. What these examples do demonstrate is the potential for effective use of ADLs in software projects.
Wright was used to model and analyze the Runtime Infrastructure (RTI) of the Department of Defense (DoD) High-Level Architecture for Simulations (HLA) [All96]. The original specification for RTI was over 100 pages long. Wright was able to substantially condense the specification and reveal several inconsistencies and weaknesses in it.
SADL was applied to an operational power-control system, used by the Tokyo Electric Power Company. The system was implemented in 200,000 lines of Fortran 77 code. SADL was used to formalize the system's reference architecture and ensure its consistency with the implementation architecture.
Finally, Rapide has been used in several large-scale projects thus far. A representative example is the X/Open Distributed Transaction Processing (DTP) Industry Standard. The documentation for the standard is over 400 pages long. Its reference architecture and subsequent extensions have been successfully specified and simulated in Rapide [LKA+95].
ADLs typically share syntactic constructs that enable them to model components and component interfaces, connectors, and configurations.[Footnote 2] A much greater source of divergence are the different ADLs' conceptual frameworks, and, consequently, their support for modeling architectural semantics. ADL developers typically have decided to focus on a specific aspect of architectures, or an architectural domain, which guides their selection of an underlying semantic model and a set of related formal specification notations. These formal notations, in turn, restrict the types of problems for which the ADL is suitable.
This relationship between an architectural domain and candidate formal notations is rarely straightforward or fully understood. In the absence of objective criteria, ADL researchers are forced to base their decisions on intuition, experience, and biases arising from past research accomplishments. Unfortunately, intuition can often be misleading and experience insufficient in a young discipline such as software architectures.
In this paper, we attempt to fill this void. The remainder of this section motivates and formulates a framework for classifying the problems on which architectural models focus (architectural domains), shown in Figure 1. Architectural domains represent broad classes of problems and are likely to be reflected in many ADLs and their associated formal specification language constructs. Their proper understanding is thus necessary. Furthermore, heuristics may be developed over time that will enable easier interchange of architectures modeled in ADLs that focus on particular architectural domains. Finally, such a framework can be used as a guide in developing future ADLs.
Figure 1: Architectural domains.
3.4.1. Specification-Time Evolution
If we consider components and connectors to be types which are instantiated every time they are used in an architecture, their evolution can be viewed simply in terms of subtyping. Since components and connectors are modeled at a high level of abstraction, flexible subtyping methods may be employed. For example, it may be useful to evolve a single component in multiple ways, by using different subtyping mechanisms (e.g., interface, behavior, or a combination of the two) [MORT96].
At the level of architectures, evolution is focused on incremental development and support for system families. Incrementality of an architecture can further be viewed from two different perspectives. One is its ability to accommodate addition of new components and the resulting issues of scale; the other is specification of incomplete architectures.
3.4.2. Execution-Time Evolution
As discussed above, a software architecture often consists of multiple views and may be modeled at multiple levels of abstraction (Figure 2). We call a particular view of the architecture at a given level of abstraction (i.e., a single point in the two-dimensional space of Figure 2) an "architectural cross-section." It is critical for changes in one cross-section to be correctly reflected in others. A particular architectural cross-section can be considered "dominant," so that all changes to the architecture are made to it and then reflected in others. However, changes will more frequently be made to the most appropriate or convenient cross-section. Traceability support will hence need to exist across all pertinent cross-sections.
One final issue is the consistency of an architecture with system requirements. Changes to the requirements must be appropriately reflected in the architecture; changes to the architecture must be validated against the requirements. Therefore, even though system requirements are in the problem domain, while architecture is in the solution domain, traceability between the two is crucial. For purposes of traceability, requirements can be considered to be at a very high level of architectural abstraction, as shown in Figure 2.
4. ADL Support for Architectural Domains
Support for other views is sparse. C2 provides a view of the development process that corresponds to the architecture [RR96]. Darwin's Software Architect's Assistant [NKM96] provides a hierarchical view of the architecture which shows all the component types and the "include" relationships among them in a tree structure. Rapide allows visualization of an architecture's execution behavior by building its simulation and animating its execution. Rapide also provides a tool for viewing and filtering events generated by the simulation.
The types of analyses for which an ADL is well suited depend on its underlying semantic model, and to a lesser extent, its specification features. The semantic model will largely influence whether the ADL can be analyzed statically or dynamically, or both. For example, Wright, which is based on communicating sequential processes (CSP) [Hoa85], allows static deadlock analysis of individual connectors and components attached to them. On the other hand, Rapide architectures, which are modeled with partially ordered event sets (posets) [LVB+93], can be analyzed dynamically.
The most common type of static analysis tools are language parsers and compilers. Parsers analyze architectures for syntactic correctness, while compilers establish semantic correctness. All existing ADLs have parsers. Darwin, MetaH, Rapide, and UniCon also have compilers, which enable these languages to generate executable systems from architectural descriptions. Wright does not have a compiler, but it uses FDR [For92], a model checker, to establish type conformance.
There are numerous other possible types of static analysis of architectures. Several examples are provided by current ADLs. Aesop provides facilities for checking for type consistency, cycles, resource conflicts, and scheduling feasibility in its architectures. C2 uses critics to establish adherence to style rules and design guidelines. MetaH and UniCon both currently support schedulability analysis by specifying non-functional properties, such as criticality and priority. Finally, given two architectures, SADL can establish their relative correctness with respect to a refinement map.
An architecture can evolve in two different dimensions:
4.4.1. Specification-Time Evolution
Aesop supports behavior-preserving subtyping of components and connectors to create substyles of a given architectural style. Rapide allows its interface types to inherit from other types by using OO methods, resulting in structural subtyping. ACME also supports structural subtyping via its extends feature. C2 provides a more sophisticated subtyping and type checking mechanism. Multiple subtyping relationships among components are allowed: name, interface, behavior, and implementation subtyping, as well as their combinations [MORT96].
Specification-time evolution of complete architectures has two facets: support for incremental development and support for system families. Incrementality of an architecture can be viewed from two different perspectives. One is its ability to accommodate addition of new components to the architecture. In general, explicit configuration ADLs can support incremental development more easily and effectively than in-line configuration ADLs; ADLs that allow variable numbers of components to communicate through a connector are well suited for incremental development, particularly when faced with unplanned architectural changes [Med97].
Another view of incrementality is an ADL's support for incomplete architectural descriptions. Incomplete architectures are common during design, as some decisions are deferred and others have not yet become relevant. However, most existing ADLs and their supporting toolsets have been built to prevent precisely these kinds of situations. For example, Darwin, MetaH, Rapide, and UniCon compilers, constraint checkers, and runtime systems have been constructed to raise exceptions if such situations arise. In this case, an ADL, such as Wright, which focuses its analyses on information local to a single connector is better suited to accommodate expansion of the architecture than, e.g., SADL, which is very rigorous in its refinement of entire architectures.
Still another aspect of static evolution is support for application families. In [MT96], we showed that the number of possible architectures in a component-based style grows exponentially as a result of a linear expansion of a collection of components. All such architectures may not belong to the same logical family. Therefore, relying on component and connector inheritance, subtyping, or other evolution mechanisms is insufficient. An obvious solution, currently adopted only by ACME, is to provide a language construct that allows the architect to specify the family to which the given architecture belongs.
4.4.2. Execution-Time Evolution
There are presently two approaches to supporting evolution of architectures at execution time. The first is what Oreizy calls "constrained dynamism": all runtime changes to the architecture must be known a priori and are specified as part of the architectural model [Ore96].
Two existing ADLs support constrained dynamism. Rapide supports conditional configuration; its where clause enables a form of architectural rewiring at runtime, using the link and unlink operators. Darwin allows runtime replication of components using the dyn operator.
The second approach to execution time evolution places no restrictions at architecture specification time on the kinds of allowed changes. Instead, the ADL has an architecture modification feature, which allows the architect to specify changes while the architecture is running.
Darwin and C2 are the only ADLs that support such "pure dynamism" [Ore96]. Darwin allows deletion and rebinding of components by interpreting Darwin scripts. C2 specifies a set of operations for insertion, removal, and rewiring of elements in an architecture at runtime [Med96]. C2's ArchShell tool enables arbitrary interactive construction, execution, and runtime-modification of C2-style architectures by dynamically loading and linking new architectural elements [Ore96, MOT97]. An issue that needs further exploration is constraining pure dynamic evolution to ensure that the desired properties of architectures are maintained.
Garlan has recently argued that refinement should not be consistent with respect to a single (immutable) law, but rather with respect to particular properties of interest, be they conservative extension (SADL), computational behavior (Rapide), or something entirely different, such as performance [Gar96]. This may be a good starting point towards a successful marriage of the two approaches.
Several ADLs take a different approach to refinement: they enable generation of executable systems directly from architectural specifications. These are typically the implementation constraining languages, such as MetaH and UniCon. These ADLs assume the existence of a source file that corresponds to a given architectural element. This approach makes the assumption that the relationship between elements of an architectural description and those of the resulting system will be 1-to-1. Given that architectures are intended to describe systems at a higher level of abstraction than source code modules, this can be considered only a limited form of refinement.
While the problem of refinement essentially focuses only on one axis of Figure 2 (the horizontal axis) and one direction (left to right), traceability may need to cover a large portion of the two-dimensional space and is applicable in both directions. This presents a much more difficult task, indicating why this is the architectural domain in which existing ADLs are most lacking.
The relationships among architectural views (vertical axis) are not always well understood. For example, ADLs commonly provide support for tracing changes between textual and graphical views, such that changes in one view are automatically reflected in the other; however, it may be less clear how the data flow view should affect the process view. In other cases, changes in one view (e.g., process) should never affect another (e.g., control flow). An even bigger hurdle is providing traceability support across both architectural views and levels of abstraction simultaneously. Finally, although much research has been directed at methodologies for making the transition from requirements to design (e.g., OO), this process is still an art form. Further research is especially needed to understand the effects of changing requirements on architectures and vice versa.
Traceability is particularly a problem in the way implementation constraining languages approach code generation, discussed in the previous subsection. These ADLs provide no means of guaranteeing that the source modules which are supposed to implement architectural components will do so correctly. Furthermore, even if the specified modules currently implement the needed behavior correctly, there is no guarantee that any future changes to those modules will be traced back to the architecture and vice versa.
As with dynamic analysis (Section 4.3.2), simulating an architecture will directly depend upon the ADL's ability to model its dynamic behavior. Currently, Rapide is the only ADL that can simulate the architecture itself, by generating event posets. Other ADLs enable generation of running systems corresponding to the architecture.
MetaH and UniCon require preexisting component implementations in Ada and C, respectively, in order to generate applications. Darwin can also construct executable systems in the same manner in C++, and Rapide in C, C++, Ada, VHDL, or its executable sublanguage.
C2 and Aesop provide class hierarchies for their concepts and operations, such as components, connectors, and interconnection and message passing protocols. These hierarchies form a basis from which an implementation of an architecture may be produced. Aesop's hierarchy has been implemented in C++, and C2's in C++, Java, and Ada.
Existing ADLs span a broad spectrum in terms of the architectural domains they support. On the one hand, languages like SADL and Wright have very specific, narrow foci. On the other, C2, Rapide, and Darwin support a number of architectural domains. Certain domains, e.g., evolution, refinement, and traceability are only sparsely supported, indicating areas around which future work should be centered. A more complete summary of this section is given in Table 1 below.
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
explicit config.; "weblets" | none | parser | none | application families | none | rep-maps across levels |
|
none |
|
explicit config.; graphical notation; types distinguished iconically | syntax directed editor; specialized editors for visualization classes | parser; style-specific compiler; type, cycle, resource conflict, and scheduling feasibility checker | none | behavior-preserving subtyping of components and connectors | none | none |
|
build tool constructs system glue code in C for pipe-and-filter style |
|
explicit config.; graphical notation; process view; simulation; event filtering | non-intrusive, reactive design critics and to-do lists in Argo | parser; critics to establish adherence to style rules and design heuristics | event filtering | multiple subtyping mechanisms; allows partial architectures | pure dynamism: element insertion, removal, and rewiring | none |
|
class framework enables generation of C/C++, Ada, and Java code |
|
implicit config.; graphical notation; hierarchical system view | automated addition of ports; propagation of changes across bound ports; property dialogs | parser; compiler | "what if" scenarios by instantiating parameters and dynamic components | none | constrained dynamism: runtime replication of components and conditional configuration | none |
|
compiler generates C++ code |
|
implicit config.; graphical notation; types distinguished iconically | intrusive, reactive graphical editor | parser; compiler; schedulability, reliability, and security analysis | none | none | none | none |
|
compiler generates Ada code (C code generation planned) |
|
implicit config.; graphical notation; animated simulation; event filtering | none | parser; compiler; constraint checker to ensure valid mappings | event filtering and animation | inheritance (structural subtyping) | constrained dynamism: conditional configuration and dynamic event generation | refinement maps enable comparative simulations of architectures at different levels |
constraint checking across refinement
|
simulation by generating event posets; system construction in C/C++, Ada, VHDL, and Rapide |
|
explicit config. | none | parser; relative correctness of architectures w.r.t. a refinement map | none | component and connector refinement via pattern maps | none | maps enable correct refinements across levels | refinement
across levels |
none |
|
explicit config.; graphical notation | proactive GUI editor invokes language checker | parser; compiler; schedulability analysis | none | none | none | none |
|
compiler generates C code |
|
explicit config. | none | parser; model checker for type conformance; deadlock analysis of connectors | none | type conformance for behaviorally related protocols | none | none | none | none |
5. Architectural vs. Application Domains
Over the past decade there has been interest in relating architectures, which are in the solution domain, to the problem (or application) domain, leading to the notion of domain-specific software architectures (DSSAs) [Tra95]. A DSSA provides a single (generic) reference architecture, which reflects the characteristics of a particular problem domain, and which is instantiated for each specific application in that domain. Architectural styles, discussed in Section 2, provide another way of relating the problem and solution spaces. Styles are largely orthogonal to DSSAs: a single style may be applicable to multiple application domains; on the other hand, a single DSSA may use multiple styles.
Any attempt to further explore and perhaps generalize the relationship between architectural and application domains would be greatly aided by a classification of application domains. We are unaware of any such classification, although Jackson identified a number of domain characteristics that could serve as a starting point for one [Jac95]:
Software architecture research has been moving forward rapidly. A number of ADLs and their supporting toolsets have been developed; many existing styles have been adopted and new ones invented. Theoretical underpinnings for the study of software architectures have also begun to emerge in the form of definitions [PW92, GS93] and formal classifications of styles [SC96] and ADLs [Med97, MT97].
This body of work reflects a wide spectrum of views on what architecture is, what aspects of it should be modeled and how, and what its relationship is to other software development concepts and artifacts. This divergence of views has also resulted in a divergence of ADLs' conceptual frameworks (as defined in Section 2). Such fragmentation has made it difficult to establish whether there exists in ADLs a notion similar to computational equivalence in programming languages. Furthermore, sharing support tools has been difficult.
ACME has attempted to provide a basis for interchanging architectural descriptions across ADLs. However, ACME has thus far been much more successful at achieving architectural interchange at the syntactic (i.e., structural) level, than at the semantic level. Although some of the ACME team's recent work looks encouraging, this still remains an open problem. One of the reasons ACME has encountered difficulties is precisely the fact that there is only limited agreement in the architecture community on some fundamental issues, the most critical of which is what problems architectures should attempt to solve.
This paper presents an important first step towards a solution to this problem. We have recognized that the field of software architecture is concerned with several domains and that every ADL reflects the properties of one or more domains from this set. Architectural domains thus provide a unifying view to what had seemed like a disparate collection of approaches, notations, techniques, and tools. The task of architectural interchange can be greatly aided by studying the interrelationships among architectural domains. Existing ADLs can be better understood in this new light and new ADLs more easily developed to solve a specific set of problems.
Much further work is still needed, however. Our current understanding of the relationship between architectural domains and formal semantic theories (Section 2) is limited. Also, we need to examine whether there exist techniques that can more effectively support the needs of particular architectural domains than those provided by existing ADLs. Finally, a more thorough understanding of the relationship between architectural and application domains is crucial if architecture-based development is to fulfill its potential.
Approved for Public Release - Distribution Unlimited.