Moving architectural description from under the technology lamppost

https://doi.org/10.1016/j.infsof.2006.08.006Get rights and content

Abstract

In 2000, we published an extensive study of existing software architecture description languages (ADLs), which has served as a useful reference to software architecture researchers and practitioners. Since then, circumstances have changed. The Unified Modeling Language (UML) has gained popularity and wide adoption, and many of the ADLs we studied have been pushed into obscurity. We argue that this progression can be attributed to early ADLs’ nearly exclusive focus on technological aspects of architecture, ignoring application domain and business contexts within which software systems and development organizations exist. These three concerns – technology, domain, and business – constitute three “lampposts” needed to appropriately “illuminate” software architecture and architectural description.

Introduction

Software architecture emerged as a field of software engineering research in the early 1990s, after the publication of Perry and Wolf’s seminal paper [33]. Quickly thereafter a number of architecture-based software development notations, methods, techniques, and tools were formulated. Of particular interest to the early software architecture researchers and (to a somewhat lesser extent) practitioners were the notations for modeling software architectures. These came to be known as architecture description languages, or ADLs.

Several ADLs appeared in the software engineering literature in relatively short succession: Acme [15], C2 [39], Darwin [25], MetaH [4], Rapide [24], UniCon [37], Weaves [16], Wright [1], and so on. Several other, already existing notations were also claimed to be ADLs, either by their developers or users: module interconnection languages (MILs) [34], StateCharts [17], CHAM [19], LILEAnna [41], UML 1.x [7], and so on. The early understanding of this subject was so immature that it was very difficult to argue for or against considering a given software modeling notation to be an ADL; languages often “became” ADLs simply because someone referred to them as such. However, one thing common across all these notations was the implication that they would significantly alter and improve the way software is produced.

Our study, which was conducted in the late 1990s and published in early 2000 [27], provided some much needed answers. It provided a technical basis for determining what an ADL is and is not. In particular, this allowed us to formulate a clear argument against the inclusion of several commonly used notations into the ADLs category. Our conclusions regarding some of these “non-ADLs”, such as StateCharts or CHAM, largely agreed with the conventional wisdom of the time, while in the case of others, such as UML 1.x, they were surprising (even though subsequent developments – the architecture modeling constructs added to UML 2.x – proved our conclusions sound).

These early “first-generation” ADLs came from different sources: commercial industry, government-funded aerospace companies, standards bodies, and academia. They emerged from very different areas of software development. For example, MetaH was targeted primarily at real-time systems (with a view toward the control systems domain), while Weaves modeled asynchronous data-flow architectures (geared to the needs of weather satellite-based systems). The early ADLs also emerged from different areas of computer science, outside software engineering. For example, Rapide’s predecessors were used for hardware architecture modeling, while Darwin grew out of a distributed computing research project.

Yet, despite these differences, the first-generation ADLs all shared certain traits. They all modeled the structural and, with the exception of Acme, functional characteristics of software systems. They invariably took a single, limited perspective on software architecture. Some, such as Rapide, focused almost exclusively on event-based modeling at the expense of other system aspects; others, such as Wright, were specifically geared toward deadlock detection in concurrent architectures; still others, such as MetaH and UniCon, were mainly concerned with process scheduling. To support such objectives the early ADLs heavily focused on formalization of software architectural models, with an eye on their analysis.

The result of this narrow focus was a set of ADLs that were deficient in various areas that were critical to many stakeholders. Most of these ADLs focused exclusively on software. For example, only MetaH had explicit support for modeling software architecture as well as the hardware on which it runs. Few first-generation ADLs were accompanied by a strategy for implementing the described architecture. Moreover, characteristics of the architecture description could often be verified using analysis tools and methods, but there was no way to ensure that the implemented system conformed to the architecture. Finally, these ADLs were not extensible in any meaningful way – it was prohibitively expensive to add features to them to support any unmet needs – severely limiting their range of applicability.

Since our 2000 study, the landscape of software architecture has continued to evolve. Two major changes are of interest here. First, the notion of software architecture has been expanded, allowing us to view ADLs in a new light. Second, notations and approaches for modeling software architecture have themselves continued to evolve, thereby providing us with information about directions in which the architecture modeling community is heading.

There is not today, nor has there ever been, a clear consensus on a definition of software architecture. Yet defining software architecture is critical to understanding what constitutes an architecture description language. Literally hundreds of definitions have been proffered; many have been cataloged by the Software Engineering Institute (SEI) and are available on the Web [10]. Our initial study struggled with this problem as well, identifying several alternative notions of what constituted architecture and what made up an ADL. Based on a broad survey of architecture description notations and approaches, we identified that ADLs capture aspects of software design centered around a system’s components, connectors, and configuration. This framework is concordant with what is supported in most first-generation ADLs, which, as we noted above, primarily tend to capture architectural structure along with properties of that structure. It was this framework that provided us with a “litmus test” as to whether a modeling notation was or was not an ADL.

Since that time, however, other concerns have become increasingly prominent in the software engineering community, specifically those derived from domain-specific and business needs. Additional insight has come from notions of architecture beyond the software engineering community – systems engineers, for example, have a broad notion of what constitutes architecture. Conferences such as the Working IEEE/IFIP Conference on Software Architecture (WICSA) have brought together researchers and practitioners from the software architecture, systems engineering, and enterprise architecture communities. All this has revealed that, while structural concerns retain a place of primacy in software architecture modeling, they do not and should not define its scope. Instead, we propose a broader definition of software architecture:

Definition 

A software system’s architecture is the set of principal design decisions about the system.

Design decisions encompass every aspect of the system under development, including:

  • * design decisions related to system structure – for example, “there should be exactly three components in the system, the ‘data store,’ the ‘business logic,’ and the ‘user interface’ component;”

  • * design decisions related to behavior (also referred to as functional) – for example, “data processing, storage, and visualization will be handled separately;”

  • * design decisions related to interaction – for example, “communication among all system elements will occur only using event notifications;”

  • * design decisions related to the system’s non-functional properties – for example, “the system’s dependability will be ensured by replicated processing modules;”

  • * design decisions related to the system’s development itself – for example, the process that will be used to develop and evolve the system; and

  • * design decisions related to the system’s business position – for example, its relationship to other products, time-to-market, and so on.

An important term that appears in the above definition is “principal.” It implies a degree of importance that grants a design decision “architectural status.” It also implies that not all design decisions are architectural, that is, they do not necessarily impact a system’s architecture. How one delimits “principal” will depend on what the system goals are. Ultimately, the system’s stakeholders (including, but not restricted only to the architect) will decide which design decisions are important enough to include in the architecture, and which are not. For example, consider a design decision such as “the log viewer component will check for new log entries once every second.” For systems where real-time log viewing is needed, the log refresh interval might be specified as part of the architecture. For other systems, this may simply be an implementation detail and be elided from the description of the system’s architecture.

From this definition of architecture, we can also derive definitions for architecture models, description languages, and the act of modeling:

Definition 

An architecture model is an artifact or document that captures some or all of the design decisions that make up a system’s architecture. Architecture models are sometimes referred to as architecture descriptions.

Definition 

An architecture description language is a notation in which architecture models can be expressed.

Definition 

Architecture modeling is the effort to capture and document the design decisions that make up a system’s architecture.

This broader perspective changes the test for whether a notation can be considered an architecture description language. Instead of defining ADLs based on features (e.g., the ability to model high-level system structure), they are defined by stakeholder concerns – whether a notation can adequately capture design decisions deemed principal by the system’s stakeholders. As we will explain below, these concerns are substantially broader than those captured by first-generation ADLs.

In some sense, the broader definition may seem like a step backward in that it is a relaxation of our original litmus test. In this new light, even some determinations we made in our original study about what is and is not an ADL may change. However, this raises the importance of discussing the adequacy of different notations for modeling software architecture. For example, under our new definition a notation that is not suitable for high-level structural modeling may now be classified as an ADL, but one that is clearly deficient in a critical respect.

This induces a new way to evaluate architecture modeling notations: not based on how they model basic structural elements like components, connectors, and interfaces, but rather how adequately they model concerns important to their target stakeholders.

Our criticisms of the early ADLs, and, to a somewhat lesser extent UML, stem from this issue. Those notations focused primarily on general concerns related to the technical aspects of designing and constructing software systems. However, we argue that additional concerns must be illuminated: those from application domains, as well as business needs. We posit that these three “lampposts” (technology, domain, and business) can help explain the reasons behind the limited impact of the first-generation ADLs and the shortcomings of UML. In fact, they provide a means for a more complete treatment of ADLs than was given in our original study [27]. We also posit that several more recent, “second-generation” ADLs, including UML 2.0, can be better understood and put in their proper context with the help of the three lampposts.

This paper, therefore, provides a different perspective of ADLs, both first- and second-generation, with an improved understanding of a system’s development context and an ADL’s role in it. In order to properly understand, and assess, an architecture modeling language, we believe that one needs to understand a number of issues that go beyond the usual system structure and behavioral concerns: the many overlapping and sometimes conflicting non-functional properties; the characteristics and needs of the application domain(s) at which the ADL is targeted; the system stakeholders; the organization’s business goals (e.g., managing architectural assets to support product families); and so on. Capturing all such concerns with a single, narrowly focused notation (e.g., a first-generation ADL) is impossible. At the same time, as we will discuss, it is also impractical to try to do so with a “universal” notation, such as UML.

In light of this, we will argue in this paper that a truly effective ADL must strike a proper balance between a strict focus on recurring technical concerns and the extensibility needed to include the concerns mandated by different application domains and business contexts. Our principal objectives are to highlight and improve the current understanding of

  • 1.

    the limitations of purely technical approaches to software architecture, as in the first-generation ADLs;

  • 2.

    the justified attraction, but also limitations of “one-size-fits-all” approaches, as embodied in UML; and

  • 3.

    the need for specialization of a modeling language based on the demands of a specific application, application family, or application domain.

Most importantly, returning to our metaphor, we will argue that, in order to realize their impact, ADLs have to step away from the technology lamppost and let in some light from the remaining two lampposts. This is not to say that there exists today an “ideal” or “perfect” ADL; in fact, we believe no such ADL can emerge because of the diversity of concerns that can impact systems development. Rather, we argue that ADLs can be made more effective by taking into account concerns from all three lampposts, and that several recent ADLs are indeed moving in this direction.

The remainder of the paper is organized as follows: Section 2 fleshes out our vision of the three lampposts and how they can (and should) influence software architecture modeling. Section 3 briefly recaps the lessons taught by first-generation ADLs. Section 4 describes, in some detail, a set of “second-generation” architecture description languages that have evolved from first-generation ADLs and are more appropriately positioned under the three lampposts. Section 5 summarizes lessons we have learned since our 2000 study, and extrapolates some future directions for architecture modeling. Section 6 concludes the paper.

Section snippets

The three lampposts

The old story about the man who lost his keys provides some context for our perspective on the design of architecture description languages. One variant of the story states that one night a man dropped his keys in a parking lot just before getting to his car. A friend saw him searching for the keys on the ground under a lamppost, but quite some distance away from the car. When asked why he was looking for the keys so far away from where he dropped them, the man replied, “Because the light is

First-generation ADLs

As discussed in the Section 1, in our initial study of ADLs [27] we considered several classes of notations: “first-generation” ADLs, UML [7], formal modeling notations – some of which were targeted specifically at architectural concerns, such as CHAM [19] and LILEAnna [41], module interconnection languages [34], and even programming languages. We defined an ADL as a modeling notation that provides facilities for capturing a software system’s components (i.e., computational elements), connectors

Second-generation ADLs

The first-generation ADLs predominantly remained under the “technology lamppost” – addressing interesting technical problems, but largely ignoring domain or business concerns. The contributions and lessons of this first generation of ADLs were not lost, however: even though they did not achieve significant adoption, they inspired a second generation of ADLs. These “second generation” ADLs tend to inherit lessons from earlier ADLs, as well as to include more domain and business concerns. In this

Discussion

Several insights have emerged from our retrospective examination of the evolution of ADLs.

Growing numbers of concerns are being considered part of a system’s architecture. First-generation ADLs reflect a relatively narrow view of what constitutes a system’s architecture. Many of them focus on modeling structural views of a system, perhaps annotating the structural view with additional properties to capture one or two more concerns, such as behavior or implementation mappings. Second-generation

Conclusions and future trends

Our initial classification and comparison of ADLs [27] has been a useful reference point to researchers and practitioners, and has stood the test of time in many ways. All the same, it was a very technologically oriented study that largely ignored the other two lampposts. There are two clear reasons for this. The first is that ADLs themselves (and, it could be argued, even software architecture) were not sufficiently well understood at the time. The second reason behind the limited scope of our

Acknowledgements

This material is based upon work sponsored in part by the National Science Foundation under Grant Nos. CCR-9985441, ITR-0312780, CCF-0430066, and CNS-0438996. The content of the information does not necessarily reflect the position or the policy of the Government or any sponsor and no official endorsement should be inferred. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National

References (42)

  • D. Harel

    Statecharts: a visual formalism for complex systems

    Science of Computer Programming

    (1987)
  • R. Prieto-Diaz et al.

    Module interconnection languages

    Journal of Systems and Software

    (1986)
  • R. Allen. A Formal Approach to Software Architecture. PhD thesis. Carnegie Mellon University, 1997, p. 248. Available...
  • R. Allen, S. Vestal, B. Lewis, D. Cornhill, Using an architecture description language for quantitative analysis of...
  • D. Batory, L. Coglianese, S. Shafer, W. Tracz, The ADAGE Avionics Reference Architecture, in: Proceedings of the AIAA...
  • P. Binns et al.

    Domain-specific software architectures for guidance, navigation and control

    International Journal of Software Engineering and Knowledge Engineering

    (1996)
  • B. Boehm et al.

    Software Cost Estimation with COCOMO II

    (2000)
  • G. Booch

    Object-Oriented Analysis and Design with Applications

    (1993)
  • G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide. Object Technology Series. Addison Wesley...
  • G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, second ed., Addison-Wesley Object...
  • T. Bray, J. Paoli, C.M. Sperberg-McQueen, Extensible Markup Language (XML): Part I. Syntax. World Wide Web Consortium,...
  • Carnegie Mellon University. How Do You Define Software Architecture?...
  • E. Dashofy et al.

    A comprehensive approach for the development of XML-based software architecture description languages

    Transactions on Software Engineering Methodology (TOSEM)

    (2005)
  • E.M. Dashofy. Issues in Generating Data Bindings for an XML Schema-Based Language, in: Proceedings of the Workshop on...
  • D.C. Fallside. XML Schema Part 0: Primer. World Wide Web Consortium, W3C Recommendation Report, May 2, 2001. Available...
  • P.H. Feiler, B. Lewis, S. Vestal, The SAE Avionics Architecture Description Language (AADL) Standard: A Basis for...
  • D. Garlan, R.T. Monroe, D. Wile, ACME: An Architecture Description Interchange Language, in: Proceedings of the CASCON...
  • M.M. Gorlick, R.R. Razouk, Using Weaves for Software Construction and Analysis, in: Proceedings of the 13th...
  • Institute for Software Research. ArchStudio, An Architecture-based Development Environment. Available from:...
  • P. Inverardi et al.

    Formal specification and analysis of software architectures using the chemical abstract machine model

    IEEE Transactions on Software Engineering

    (1995)
  • I. Jacobson. Object-Oriented Software Engineering: A Use Case Driven Approach, first ed., Addison-Wesley Professional,...
  • Cited by (88)

    • Achieving stepwise construction of cyber physical systems in EX-MAN component model

      2022, Journal of King Saud University - Computer and Information Sciences
      Citation Excerpt :

      Lastly, Section 7 presents the conclusion and gives directions for future work. For system construction, the use of components and connectors (Medvidovic et al., 2007; Mehta et al., 2000; Meng et al., 2012; Nejati et al., 2018) as two separate entities is a common approach in CBD. However, only few component models use coordination based connectors (Lau et al., 2006; Lau et al., 2005; Arbab et al., 2004).

    • Deriving architectural models from requirements specifications: A systematic mapping study

      2019, Information and Software Technology
      Citation Excerpt :

      Hence, one third (13 studies corresponding to 33.3%) use standard Architecture Description Languages - ADLs (e.g., UML, SysML, and AADL) [79,87,91,92,95,96,106,110–113,115,116], another third does not explicitly use a standard ADL to model the architecture [80–82,88,93,94,97,99–102,109,114], and the third, does not indicate the architectural description language used [78,83–86,89,90,98,103–105,107,108] (None of the selected studies used a process algebra ADL). A possible reason for 26 studies not adopting nor defining an ADL could be because an ADL needs to capture design decisions judged fundamental to satisfy different stakeholder concerns [33] and also because it is difficult to capture all the different concerns with a unique language [34]. Of the 39 selected studies, 18 (46.1%) are partially automated [79,81–83,87,89–93,95,96,99,109,112,113,115,116], 8 (20.5%) are not automated [78,97,98,100–102,110,114], and 13 (33.3%) do not mention supporting tools [80,84–86,88,94,103–108,111].

    • Do the informal & formal software modeling notations satisfy practitioners for software architecture modeling?

      2018, Information and Software Technology
      Citation Excerpt :

      Clements and Medvidovic surveyed a small group of 8–9 ADLs that they have determined for assessing their framework. Medvidovic et al. later on conducted another survey in 2006, where they again categorised 8 different ADLs based on their definition of the ”three lamppost” (i.e., technology, domain, and business) [38]. In [39], Hilliard and Rice focussed on the possible issues that affect the expressiveness of the ADLs proposed in the nineties, including multiple viewpoints, first-class elements, architectural patterns, and the specifications of client requirements and architects’ design decisions separately.

    • Architecting Cloud Services for the Digital Me in a Privacy-Aware Environment

      2017, Software Architecture for Big Data and the Cloud
    View all citing articles on Scopus
    1

    Tel.: +1 949 824 4101; fax: +1 949 824 1715.

    2

    Tel.: +1 949 824 6429; fax: +1 949 824 1715.

    View full text