• Source: Architecture description language

      • Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.
      The system engineering community uses an architecture description language as a language and/or a conceptual model to describe and represent system architectures.
      The software engineering community uses an architecture description language as a computer language to create a description of a software architecture. In the case of a so-called technical architecture, the architecture must be communicated to software developers; a functional architecture is communicated to various stakeholders and users. Some ADLs that have been developed are: Acme (developed by CMU), AADL (standardized by the SAE), C2 (developed by UCI), SBC-ADL (developed by National Sun Yat-Sen University), Darwin (developed by Imperial College London), and Wright (developed by CMU).


      Overview


      The ISO/IEC/IEEE 42010 document, Systems and software engineering—Architecture description, defines an architecture description language as "any form of expression for use in architecture descriptions" and specifies minimum requirements on ADLs.
      The enterprise modelling and engineering community have also developed architecture description languages catered for at the enterprise level. Examples include ArchiMate (now a standard of The Open Group), DEMO, ABACUS (developed by the University of Technology, Sydney). These languages do not necessarily refer to software components, etc. Most of them, however, refer to an application architecture as the architecture that is communicated to the software engineers.
      Most of the writing below refers primarily to the perspective from the software engineering community.
      A standard notation (ADL) for representing architectures helps promote mutual communication, the embodiment of early design decisions, and the creation of a transferable abstraction of a system. Architectures in the past were largely represented by box-and-line drawing annotated with such things as the nature of the component, properties, semantics of connections, and overall system behavior. ADLs result from a linguistic approach to the formal representation of architectures, and as such they address its shortcomings. Also important, sophisticated ADLs allow for early analysis and feasibility testing of architectural design decisions.


      History


      ADLs have been classified into three broad categories: box-and-line informal drawings, formal architecture description language, and UML (unified modeling language)-based notations.
      Box-and-line have been for a long time the most predominant means for describing software architectures. While providing useful documentation, the level of informality limited the usefulness of the architecture description. A more rigorous way for describing software architectures was required. Quoting Allen and Garlan (1997), "while these [box-and-line] descriptions may provide useful documentation, the current level of informality limits their usefulness. Since it is generally imprecise what is meant by such architectural descriptions, it may be impossible to analyze an architecture for consistency or determine non-trivial properties of it. Moreover, there is no way to check that a system implementation is faithful to its architectural design." A similar conclusion is drawn in Perry and Wolf (1992), which reports that: "Aside from providing clear and precise documentation, the primary purpose of specifications is to provide automated analysis of the documents and to expose various kinds of problems that would otherwise go undetected."
      Since then, a thread of research on formal languages for software architecture description has been carried out. Tens of formal ADLs have been proposed, each characterized by different conceptual architectural elements, different syntax or semantics, focusing on a specific operational domain, or only suitable for different analysis techniques. For example, domain-specific ADLs have been presented to deal with embedded and real-time systems (such as AADL, EAST-ADL, and EADL), control-loop applications (DiaSpec), product line architectures (Koala), and dynamic systems (Π-ADL)). Analysis-specific ADLs have been proposed to deal with availability, reliability, security, resource consumption, data quality and real-time performance analysis (AADL, behavioral analysis (Fractal)), and trustworthiness analysis (TADL).
      However, these efforts have not seen the desired adoption by industrial practice. Some reasons for this lack of industry adoption have been analyzed by Woods and Hilliard, Pandey, Clements, and others: formal ADLs have been rarely integrated in the software life-cycle, they are seldom supported by mature tools, scarcely documented, focusing on very specific needs, and leaving no space for extensions enabling the addition of new features.
      As a way to overcome some of those limitations, UML has been indicated as a possible successor of existing ADLs. Many proposals have been presented to use or extend the UML to more properly model software architectures.
      A 2013 study found that practitioners were generally satisfied with the design capabilities of the ADLS they used, but had several major concerns with them: they lacked analysis features and the ability to define extra-functional properties; those used in practice mostly originated from industrial development rather than academic research; they needed more formality and better usability.


      Characteristics


      There is a large variety in ADLs developed by either academic or industrial groups. Many languages were not intended to be an ADL, but they turn out to be suitable for representing and analyzing an architecture.
      In principle ADLs differ from requirements languages, because ADLs are rooted in the solution space, whereas requirements describe problem spaces. They differ from programming languages, because ADLs do not bind architectural abstractions to specific point solutions. Modeling languages represent behaviors, where ADLs focus on representation of components. However, there are domain specific modeling languages (DSMLs) that focus on representation of components.
      Minimal requirements
      The language must:

      Be suitable for communicating an architecture to all interested parties
      Support the tasks of architecture creation, refinement and validation
      Provide a basis for further implementation, so it must be able to add information to the ADL specification to enable the final system specification to be derived from the ADL
      Provide the ability to represent most of the common architectural styles
      Support analytical capabilities or provide quick generating prototype implementations
      ADLs have in common:

      Graphical syntax with often a textual form and a formally defined syntax and semantics
      Features for modeling distributed systems
      Little support for capturing design information, except through general purpose annotation mechanisms
      Ability to represent hierarchical levels of detail including the creation of substructures by instantiating templates
      ADLs differ in their ability to:

      Handle real-time constructs, such as deadlines and task priorities, at the architectural level
      Support the specification of different architectural styles. Few handle object oriented class inheritance or dynamic architectures
      Support the analysis of the architecture
      Handle different instantiations of the same architecture, in relation to product line architectures


      = Positive elements of ADL

      =
      ADLs are a formal way of representing architecture
      ADLs are intended to be both human and machine readable
      ADLs support describing a system at a higher level than previously possible
      ADLs permit analysis and assessment of architectures, for completeness, consistency, ambiguity, and performance
      ADLs can support automatic generation of software systems


      = Negative elements of ADL

      =
      There is no universal agreement on what ADLs should represent, particularly as regards the behavior of the architecture
      Representations currently in use are relatively difficult to parse and are not supported by commercial tools
      Most ADLs tend to be very vertically optimized toward a particular kind of analysis


      Common concepts of architecture


      The ADL community generally agrees that Software Architecture is a set of components and the connections among them. But there are different kind of architectures like:


      = Object connection architecture

      =
      Configuration consists of the interfaces and connections of an object-oriented system
      Interfaces specify the features that must be provided by modules conforming to an interface
      Connections represented by interfaces together with call graph
      Conformance usually enforced by the programming language
      Decomposition — associating interfaces with unique modules
      Interface conformance — static checking of syntactic rules
      Communication integrity — visibility between modules


      = Interface connection architecture

      =
      Expands the role of interfaces and connections
      Interfaces specify both "required" and "provided" features
      Connections are defined between "required" features and "provided" features
      Consists of interfaces, connections and constraints
      Constraints restrict behavior of interfaces and connections in an architecture
      Constraints in an architecture map to requirements for a system
      Most ADLs implement an interface connection architecture.


      Architecture vs. design


      Architecture, in the context of software systems, is roughly divided into categories, primarily software architecture, network architecture, and systems architecture. Within each of these categories, there is a tangible but fuzzy distinction between architecture and design. To draw this distinction as universally and clearly as possible, it is best to consider design as a noun rather than as a verb, so that the comparison is between two nouns.
      Design is the abstraction and specification of patterns and organs of functionality that have been or will be implemented. Architecture is both a degree higher in abstraction and courser in granularity. Consequentially, architecture is also more topological (i.e. overall structure and relationship between components) in nature than design (i.e. specific details and implementation), in that it specifies where major components meet and how they relate to one another. Architecture focuses on the partitioning of major regions of functionality into high level components, where they will physically or virtually reside, what off-the-shelf components may be employed effectively, in general what interfaces each component will expose, what protocols will be employed between them, and what practices and high level patterns may best meet extensibility, maintainability, reliability, durability, scalability, and other non-functional objectives. Design is a detailing of these choices and a more concrete clarification of how functional requirements will be met through the delegation of pieces of that functionality to more granular components and how these smaller components will be organized within the larger ones.
      Oftentimes, a portion of architecture is done during the conceptualization of an application, system, or network and may appear in the non-functional sections of requirement documentation. Canonically, design is not specified in requirements, but is rather driven by them.
      The process of defining an architecture may involve heuristics, acquired by the architect or architectural team through experience within the domain. As with design, architecture often evolves through a series of iterations, and just as the wisdom of a high level design is often tested when low level design and implementation occurs, the wisdom of an architecture is tested during the specification of a high level design. In both cases, if the wisdom of the specification is called into question during detailing, another iteration of either architecture or design, as the case may be, may become necessary.
      In summary, the primary differences between architecture and design are ones of granularity and abstraction, and (consequentially) chronology. (Architecture generally precedes design, although overlap and circular iteration is a common reality.)


      Examples


      ArchiMate
      Architecture Analysis & Design Language
      C4 model (software)
      Darwin (ADL)
      EAST-ADL
      Wright (ADL)


      Approaches to system architecture



      Academic approach
      focus on analytic evaluation of architectural models
      individual models
      rigorous modeling notations
      powerful analysis techniques
      depth over breadth
      special-purpose solutions
      Industrial approach
      focus on wide range of development issues
      families of models
      practicality over rigor
      architecture as the big picture in development
      breadth over depth
      general-purpose solutions


      See also


      AADL
      Darwin
      Scripting language
      Hardware description language


      References




      External links



      Medvidovic, N.; Taylor, R.N. (January 2000). "A Classification and Comparison Framework for Software Architecture Description Languages". IEEE Transactions on Software Engineering. 26 (1): 70–93. doi:10.1109/32.825767.
      Malavolta, Ivano; Lago, Patricia; Muccini, Henry; Pelliccione, Patrizio; Tang, Antony (2013). "What Industry Needs from Architectural Languages: A Survey". IEEE Transactions on Software Engineering. 39 (6): 869–891. doi:10.1109/TSE.2012.74. S2CID 6383726.
      Architecture Description Languages // Mälardalen University
      Clements, P.C. (1996). "A survey of architecture description languages" (PDF). Proceedings of the 8th International Workshop on Software Specification and Design. pp. 16–25. doi:10.1109/IWSSD.1996.501143. ISBN 0-8186-7361-3. S2CID 7307554. Archived from the original (PDF) on 2013-12-24.
      ABACUS
      ACME
      ADML
      Aesop
      AO-ADL
      ArchiMate An example of an ADL for enterprise architecture
      ByADL (Build Your ADL) - University of L'Aquila
      C2 SADL
      DAOP-ADL
      DEMO Another example of an enterprise architecture ADL
      DiaSpec an approach and tool to generate a distributed framework from a software architecture
      Malavolta, I.; Muccini, H.; Pelliccione, P.; Tamburri, D. (January–February 2010). "Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies". IEEE Transactions on Software Engineering. 36 (1): 119–140. doi:10.1109/TSE.2009.51. S2CID 6825192. DUALLy
      Rapide
      SSEP
      Unicon
      Wright

    Kata Kunci Pencarian: