Architecture Description Language (ADL) - Revision history

User at 15:50, 19 December 2022

2022-12-19T15:50:13Z

User at 19:54, 16 November 2022

2022-11-16T19:54:47Z

User at 19:52, 16 November 2022

2022-11-16T19:52:48Z

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T13:50:28Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 19:55, 11 December 2019

2019-12-11T19:55:08Z

User: An Architecture description language (ADL) is domain-specific modeling language for enterprise architecture management. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express system architectures.

2018-12-03T22:48:39Z

An Architecture description language (ADL) is domain-specific modeling language for enterprise architecture management. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express system architectures.

Show changes

User: Created page with "'''Content Coming Soon'''"

2018-12-03T19:57:03Z

Created page with "'''Content Coming Soon'''"

New page

'''Content Coming Soon'''

@@ Line 1: / Line 1: @@
-An '''[[Architecture]] description language (ADL)''' is domain-specific modeling language for [[Enterprise_Architecture_Management_(EAM)|EAM]]. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express [[system]] architectures. That means, ADLs provide a set of rules and common practices for the creation of visualizations like e.g. flow diagrams or [[organization]] charts. The resulting visualizations address concerns of EAM stakeholders and can be grouped into views. ADLs are often supported by EAM tools to aid the creation, use and analysis of its models and visualizations.<ref>Defining Architecture Description Language (ADL) [http://eam-initiative.org/pages/ir4pt24usy4d/Architecture-Description-Language-ADL eam-initiative.org]</ref>
+An '''Architecture description language (ADL)''' is domain-specific modeling language for [[Enterprise_Architecture_Management_(EAM)|EAM]]. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express system architectures. That means, ADLs provide a set of rules and common practices for the creation of visualizations like e.g. flow diagrams or organization charts. The resulting visualizations address concerns of EAM stakeholders and can be grouped into views. ADLs are often supported by EAM tools to aid the creation, use and analysis of its models and visualizations.<ref>Defining Architecture Description Language (ADL) [http://eam-initiative.org/pages/ir4pt24usy4d/Architecture-Description-Language-ADL eam-initiative.org]</ref>
-A [[software architecture]] describes the structure and behavior of a [[software]] system and the non-software entities the system interfaces with. In a software architecture, a system is represented as a set of software components, their connections, and their important behavioral interactions. Creating a software architecture promotes better understanding of the system, thus aiding the [[design process]]. It also provides a basis for rigorous analysis of the system [[design]], making possible the early detection of design errors and flaws that lead to improvements in software [[quality]] and help ensure correctness. An architectural description language (ADL) is used to describe a software architecture. An ADL may be a formal or semi-formal descriptive language, a graphics language, or include both. The advantage of using an ADL lies in the ability to rigorously specify an architecture so that it can be analyzed. An ADL may have associated with it a set of tools for doing useful analysis of architectures specified in the language. In recent years, there has been a considerable amount of research into developing ADLs.<ref>What are Architecture Description Languages (ADLs)? [https://www.itl.nist.gov/div897/ctg/adl/adl_info.html NIST]</ref>
+A [[Software Architecture|software architecture]] describes the structure and behavior of a software system and the non-software entities the system interfaces with. In a software architecture, a system is represented as a set of software components, their connections, and their important behavioral interactions. Creating a software architecture promotes better understanding of the system, thus aiding the [[Design Process|design process]]. It also provides a basis for rigorous analysis of the system design, making possible the early detection of design errors and flaws that lead to improvements in software quality and help ensure correctness. An architectural description language (ADL) is used to describe a software architecture. An ADL may be a formal or semi-formal descriptive language, a graphics language, or include both. The advantage of using an ADL lies in the ability to rigorously specify an architecture so that it can be analyzed. An ADL may have associated with it a set of tools for doing useful analysis of architectures specified in the language. In recent years, there has been a considerable amount of research into developing ADLs.<ref>What are Architecture Description Languages (ADLs)? [https://www.itl.nist.gov/div897/ctg/adl/adl_info.html NIST]</ref>
@@ Line 15: / Line 15: @@
 '''Common ADL Constructs'''<ref>Common ADL Constructs [https://pdfs.semanticscholar.org/presentation/402a/9a51bfa0695549a7d1122127de0528afdeff.pdf Prof. Duane Truex]</ref><br />
-*Components (Either [[data]] store or unit of computation)
+*Components (Either data store or unit of computation)
 **represent the primary computational elements and data stores of a system.
 **Typical examples of component include such things as clients, servers, filters, objects, blackboards and databases.
@@ Line 24: / Line 24: @@
 **From the run time perspective, connectors mediate the communication and coordination activities among components.
 **Examples include simple forms of interaction, such as pipes, procedure call, and event broadcast.
-**Connectors may also represent complex interactions, such as client-[[server]] protocol, or a SQL Link between a database and an [[application]].
+**Connectors may also represent complex interactions, such as client-server protocol, or a SQL Link between a database and an application.
 **Connectors have interfaces that define the roles played by the participants in the interaction.
 *Systems (configurations of components and connectors)
@@ Line 39: / Line 39: @@
 '''Choosing an Architecture Description Language'''<ref>Factors Affecting Choice of  Architecture Description Language [http://trak-community.org/index.php/wiki/Choosing_an_Architecture_Description_Language trak-community.org]</ref><br />
 There are considerations when choosing an architecture description language that will affect the choice:
-*How much of the architecture [[framework]] metamodel is it possible to represent using the ADL? Most ADLs themselves have some form of metamodel and they may or may not have the means to represent parts of your architecture framework metamodel. If they cannot then this may not matter depending on what concerns are to be addressed using the architecture description - if the framework metamodel elements for the views/viewpoints needed for the task are covered then the architecture task can be completed. If there is inadequate coverage either another ADL has to be used or a combination of ADLs has to be used (although this adds practical complications).
+*How much of the architecture framework metamodel is it possible to represent using the ADL? Most ADLs themselves have some form of metamodel and they may or may not have the means to represent parts of your architecture framework metamodel. If they cannot then this may not matter depending on what concerns are to be addressed using the architecture description - if the framework metamodel elements for the views/viewpoints needed for the task are covered then the architecture task can be completed. If there is inadequate coverage either another ADL has to be used or a combination of ADLs has to be used (although this adds practical complications).
 *Familiarity and experience. If an ADL is commonly used then the training requirements will be smaller. modelling tool support. Some modelling tools support a limited set of ADLs and therefore choosing a new ADL might require either new tools or extension of existing ones.
@@ Line 50: / Line 50: @@
 '''Characteristics of Architecture Description Language (ADL)'''<ref>What are the Characteristics of an Architecture Description Language (ADL)? [https://en.wikipedia.org/wiki/Architecture_description_language Wikipedia]</ref><br />
-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.
+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:
@@ Line 67: / Line 67: @@
 **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
+**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
@@ Line 83: / Line 83: @@
 How do ADLs differ from programming languages, requirements languages, modeling languages, and the like? Given a language for expressing properties or behaviors of a system, what are the criteria for deciding if it is an ADL or not? Unfortunately, it isn't clear.
 *In principle, ADLs differ from requirements languages because the latter category describes problem spaces, whereas the former category is rooted in the solution space.
-*In practice, requirements are often divided into behavioral chunks for ease of presentation, and the languages used for representing those behaviors are sometimes well-suited to representing architectural components, even though that was not the original goal of the language. For example, Modechart, a requirements language similar to Statechart, exhibited stronger analytical capabilities than most ADLs because of the presence of a [[model]]-checking verifier. Modechart was considered to be an ADL because its componentry (state machines) could be interpreted as architectural components. However, Modechart was not designed to be an ADL, and so it is easy to produce artifacts in Modechart that do not, under any reasonable semantic interpretation, correspond to an architectural view of a system.
+*In practice, requirements are often divided into behavioral chunks for ease of presentation, and the languages used for representing those behaviors are sometimes well-suited to representing architectural components, even though that was not the original goal of the language. For example, Modechart, a requirements language similar to Statechart, exhibited stronger analytical capabilities than most ADLs because of the presence of a model-checking verifier. Modechart was considered to be an ADL because its componentry (state machines) could be interpreted as architectural components. However, Modechart was not designed to be an ADL, and so it is easy to produce artifacts in Modechart that do not, under any reasonable semantic interpretation, correspond to an architectural view of a system.
 *In principle, ADLs differ from programming languages because the latter category binds all architectural abstractions to specific point solutions whereas ADLs intentionally suppress or vary such binding.
 *In practice, architecture is embodied in and recoverable from code, and many languages provide architecture-level views of the system. For example, Ada offers the ability to view a system just in terms of its package specifications, which are the interfaces to components. However, Ada offers little or no architecture-level analytical capabilities, nor does it provide architecture level insight into how the components are "wired" together.
@@ Line 114: / Line 114: @@
 *[[The Open Group Architecture Framework (TOGAF)]]
 *[[Architecture Driven Modernization]]
 *[[Enterprise Architecture]]
 *[[Unified Modeling Language (UML)]]

@@ Line 2: / Line 2: @@
-A [[Software_Architecture|software architecture]] describes the structure and behavior of a [[software]] system and the non-software entities the system interfaces with. In a software architecture, a system is represented as a set of software components, their connections, and their important behavioral interactions. Creating a software architecture promotes better understanding of the system, thus aiding the [[Design_Process|design process]]. It also provides a basis for rigorous analysis of the system [[design]], making possible the early detection of design errors and flaws that lead to improvements in software [[quality]] and help ensure correctness. An architectural description language (ADL) is used to describe a software architecture. An ADL may be a formal or semi-formal descriptive language, a graphics language, or include both. The advantage of using an ADL lies in the ability to rigorously specify an architecture so that it can be analyzed. An ADL may have associated with it a set of tools for doing useful analysis of architectures specified in the language. In recent years, there has been a considerable amount of research into developing ADLs.<ref>What are Architecture Description Languages (ADLs)? [https://www.itl.nist.gov/div897/ctg/adl/adl_info.html NIST]</ref>
+A [[software architecture]] describes the structure and behavior of a [[software]] system and the non-software entities the system interfaces with. In a software architecture, a system is represented as a set of software components, their connections, and their important behavioral interactions. Creating a software architecture promotes better understanding of the system, thus aiding the [[design process]]. It also provides a basis for rigorous analysis of the system [[design]], making possible the early detection of design errors and flaws that lead to improvements in software [[quality]] and help ensure correctness. An architectural description language (ADL) is used to describe a software architecture. An ADL may be a formal or semi-formal descriptive language, a graphics language, or include both. The advantage of using an ADL lies in the ability to rigorously specify an architecture so that it can be analyzed. An ADL may have associated with it a set of tools for doing useful analysis of architectures specified in the language. In recent years, there has been a considerable amount of research into developing ADLs.<ref>What are Architecture Description Languages (ADLs)? [https://www.itl.nist.gov/div897/ctg/adl/adl_info.html NIST]</ref>
 '''What constitutes an ADL?'''<ref>What constitutes an ADL? [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.625.6415&rep=rep1&type=pdf Paul C. Clemens]</ref><br />
-After surveying a broad [[selection]] of languages, all of which have some claim to being ADLs, what can we conclude about what makes a language an ADL? The following seems to be a minimal set of requirements for a language to be an ADL:
+After surveying a broad selection of languages, all of which have some claim to being ADLs, what can we conclude about what makes a language an ADL? The following seems to be a minimal set of requirements for a language to be an ADL:
 • An ADL must support the tasks of architecture creation, refinement, and validation. It must embody rules about what constitutes a complete or consistent architecture.
 • An ADL must provide the ability to represent (even if indirectly) most of the common architectural styles enumerated in.
@@ Line 110: / Line 110: @@
 *[[Architectural Pattern]]
 *[[Architectural Principles]]
 *[[Architecture Development Method (ADM)]]
 *[[Service Oriented Architecture (SOA)]]
 *[[The Open Group Architecture Framework (TOGAF)]]
 *[[Architecture Driven Modernization]]

@@ Line 91: / Line 91: @@
 '''Architecture Description Languages: Mainstream and Experimental'''<ref>Architecture Description Languages: Mainstream and Experimental [https://iasaglobal.org/itabok/capability-descriptions/architecture-description/ IASA]</ref><br />
-*Architecture Description languages are still largely a research activity with only 2 languages really considered “mainstream”, with UML an established and generally accepted “lingua franca” of software design, and [[ArchiMate]] being a recently emerging but widely supported ADL.
+*Architecture Description languages are still largely a research activity with only 2 languages really considered “mainstream”, with UML an established and generally accepted “lingua franca” of software design, and ArchiMate being a recently emerging but widely supported ADL.
 **[http://www.uml.org UML]
 **[http://www.opengroup.org/subjectareas/enterprise/archimate ArchiMate]
@@ Line 106: / Line 106: @@
 ===See Also===
-[[Architectural_Style|Architectural Style]]<br />
+*[[Architectural Style]]
-[[Architectural_Risk|Architectural Risk]]<br />
+*[[Architectural Risk]]
-[[Architectural_Pattern|Architectural Pattern]]<br />
+*[[Architectural Pattern]]
-[[Architectural_Principles|Architectural Principles]]<br />
+*[[Architectural Principles]]
-[[Architecture|Architecture]]<br />
+*[[Architecture]]
-[[Architecture_Development_Method_(ADM)|Architecture Development Method (ADM)]]<br />
+*[[Architecture Development Method (ADM)]]
-[[Service_Oriented_Architecture_(SOA)|Service Oriented Architecture (SOA)]]<br />
+*[[Service Oriented Architecture (SOA)]]
-[[Software_Architecture|Software Architecture]]<br />
+*[[Software Architecture]]
-[[The_Open_Group_Architecture_Framework_(TOGAF)|The Open Group Architecture Framework (TOGAF)]]<br />
+*[[The Open Group Architecture Framework (TOGAF)]]
-[[Architecture_Driven_Modernization|Architecture-Driven Modernization]]<br />
+*[[Architecture Driven Modernization]]
-[[Design_Pattern|Design Pattern]]<br />
+*[[Design Pattern]]
-[[Enterprise_Architecture|Enterprise Architecture]]
+*[[Enterprise Architecture]]
-[[Unified_Modeling_Language_(UML)|Unified Modeling Language (UML)]]
+*[[Unified Modeling Language (UML)]]

@@ Line 1: / Line 1: @@
-An '''Architecture description language (ADL)''' is domain-specific modeling language for [[Enterprise_Architecture_Management_(EAM)|EAM]]. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express system architectures. That means, ADLs provide a set of rules and common practices for the creation of visualizations like e.g. flow diagrams or organization charts. The resulting visualizations address concerns of EAM stakeholders and can be grouped into views. ADLs are often supported by EAM tools to aid the creation, use and analysis of its models and visualizations.<ref>Defining Architecture Description Language (ADL) [http://eam-initiative.org/pages/ir4pt24usy4d/Architecture-Description-Language-ADL eam-initiative.org]</ref>
+An '''[[Architecture]] description language (ADL)''' is domain-specific modeling language for [[Enterprise_Architecture_Management_(EAM)|EAM]]. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express [[system]] architectures. That means, ADLs provide a set of rules and common practices for the creation of visualizations like e.g. flow diagrams or [[organization]] charts. The resulting visualizations address concerns of EAM stakeholders and can be grouped into views. ADLs are often supported by EAM tools to aid the creation, use and analysis of its models and visualizations.<ref>Defining Architecture Description Language (ADL) [http://eam-initiative.org/pages/ir4pt24usy4d/Architecture-Description-Language-ADL eam-initiative.org]</ref>
-A [[Software_Architecture|software architecture]] describes the structure and behavior of a software system and the non-software entities the system interfaces with. In a software architecture, a system is represented as a set of software components, their connections, and their important behavioral interactions. Creating a software architecture promotes better understanding of the system, thus aiding the [[Design_Process|design process]]. It also provides a basis for rigorous analysis of the system design, making possible the early detection of design errors and flaws that lead to improvements in software quality and help ensure correctness. An architectural description language (ADL) is used to describe a software architecture. An ADL may be a formal or semi-formal descriptive language, a graphics language, or include both. The advantage of using an ADL lies in the ability to rigorously specify an architecture so that it can be analyzed. An ADL may have associated with it a set of tools for doing useful analysis of architectures specified in the language. In recent years, there has been a considerable amount of research into developing ADLs.<ref>What are Architecture Description Languages (ADLs)? [https://www.itl.nist.gov/div897/ctg/adl/adl_info.html NIST]</ref>
+A [[Software_Architecture|software architecture]] describes the structure and behavior of a [[software]] system and the non-software entities the system interfaces with. In a software architecture, a system is represented as a set of software components, their connections, and their important behavioral interactions. Creating a software architecture promotes better understanding of the system, thus aiding the [[Design_Process|design process]]. It also provides a basis for rigorous analysis of the system [[design]], making possible the early detection of design errors and flaws that lead to improvements in software [[quality]] and help ensure correctness. An architectural description language (ADL) is used to describe a software architecture. An ADL may be a formal or semi-formal descriptive language, a graphics language, or include both. The advantage of using an ADL lies in the ability to rigorously specify an architecture so that it can be analyzed. An ADL may have associated with it a set of tools for doing useful analysis of architectures specified in the language. In recent years, there has been a considerable amount of research into developing ADLs.<ref>What are Architecture Description Languages (ADLs)? [https://www.itl.nist.gov/div897/ctg/adl/adl_info.html NIST]</ref>
 '''What constitutes an ADL?'''<ref>What constitutes an ADL? [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.625.6415&rep=rep1&type=pdf Paul C. Clemens]</ref><br />
-After surveying a broad selection of languages, all of which have some claim to being ADLs, what can we conclude about what makes a language an ADL? The following seems to be a minimal set of requirements for a language to be an ADL:
+After surveying a broad [[selection]] of languages, all of which have some claim to being ADLs, what can we conclude about what makes a language an ADL? The following seems to be a minimal set of requirements for a language to be an ADL:
 • An ADL must support the tasks of architecture creation, refinement, and validation. It must embody rules about what constitutes a complete or consistent architecture.
 • An ADL must provide the ability to represent (even if indirectly) most of the common architectural styles enumerated in.
@@ Line 15: / Line 15: @@
 '''Common ADL Constructs'''<ref>Common ADL Constructs [https://pdfs.semanticscholar.org/presentation/402a/9a51bfa0695549a7d1122127de0528afdeff.pdf Prof. Duane Truex]</ref><br />
-*Components (Either data store or unit of computation)
+*Components (Either [[data]] store or unit of computation)
 **represent the primary computational elements and data stores of a system.
 **Typical examples of component include such things as clients, servers, filters, objects, blackboards and databases.
@@ Line 24: / Line 24: @@
 **From the run time perspective, connectors mediate the communication and coordination activities among components.
 **Examples include simple forms of interaction, such as pipes, procedure call, and event broadcast.
-**Connectors may also represent complex interactions, such as client-server protocol, or a SQL Link between a database and an application.
+**Connectors may also represent complex interactions, such as client-[[server]] protocol, or a SQL Link between a database and an [[application]].
 **Connectors have interfaces that define the roles played by the participants in the interaction.
 *Systems (configurations of components and connectors)
@@ Line 39: / Line 39: @@
 '''Choosing an Architecture Description Language'''<ref>Factors Affecting Choice of  Architecture Description Language [http://trak-community.org/index.php/wiki/Choosing_an_Architecture_Description_Language trak-community.org]</ref><br />
 There are considerations when choosing an architecture description language that will affect the choice:
-*How much of the architecture framework metamodel is it possible to represent using the ADL? Most ADLs themselves have some form of metamodel and they may or may not have the means to represent parts of your architecture framework metamodel. If they cannot then this may not matter depending on what concerns are to be addressed using the architecture description - if the framework metamodel elements for the views/viewpoints needed for the task are covered then the architecture task can be completed. If there is inadequate coverage either another ADL has to be used or a combination of ADLs has to be used (although this adds practical complications).
+*How much of the architecture [[framework]] metamodel is it possible to represent using the ADL? Most ADLs themselves have some form of metamodel and they may or may not have the means to represent parts of your architecture framework metamodel. If they cannot then this may not matter depending on what concerns are to be addressed using the architecture description - if the framework metamodel elements for the views/viewpoints needed for the task are covered then the architecture task can be completed. If there is inadequate coverage either another ADL has to be used or a combination of ADLs has to be used (although this adds practical complications).
 *Familiarity and experience. If an ADL is commonly used then the training requirements will be smaller. modelling tool support. Some modelling tools support a limited set of ADLs and therefore choosing a new ADL might require either new tools or extension of existing ones.
@@ Line 50: / Line 50: @@
 '''Characteristics of Architecture Description Language (ADL)'''<ref>What are the Characteristics of an Architecture Description Language (ADL)? [https://en.wikipedia.org/wiki/Architecture_description_language Wikipedia]</ref><br />
-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.
+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:
@@ Line 67: / Line 67: @@
 **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
+**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
@@ Line 83: / Line 83: @@
 How do ADLs differ from programming languages, requirements languages, modeling languages, and the like? Given a language for expressing properties or behaviors of a system, what are the criteria for deciding if it is an ADL or not? Unfortunately, it isn't clear.
 *In principle, ADLs differ from requirements languages because the latter category describes problem spaces, whereas the former category is rooted in the solution space.
-*In practice, requirements are often divided into behavioral chunks for ease of presentation, and the languages used for representing those behaviors are sometimes well-suited to representing architectural components, even though that was not the original goal of the language. For example, Modechart, a requirements language similar to Statechart, exhibited stronger analytical capabilities than most ADLs because of the presence of a model-checking verifier. Modechart was considered to be an ADL because its componentry (state machines) could be interpreted as architectural components. However, Modechart was not designed to be an ADL, and so it is easy to produce artifacts in Modechart that do not, under any reasonable semantic interpretation, correspond to an architectural view of a system.
+*In practice, requirements are often divided into behavioral chunks for ease of presentation, and the languages used for representing those behaviors are sometimes well-suited to representing architectural components, even though that was not the original goal of the language. For example, Modechart, a requirements language similar to Statechart, exhibited stronger analytical capabilities than most ADLs because of the presence of a [[model]]-checking verifier. Modechart was considered to be an ADL because its componentry (state machines) could be interpreted as architectural components. However, Modechart was not designed to be an ADL, and so it is easy to produce artifacts in Modechart that do not, under any reasonable semantic interpretation, correspond to an architectural view of a system.
 *In principle, ADLs differ from programming languages because the latter category binds all architectural abstractions to specific point solutions whereas ADLs intentionally suppress or vary such binding.
 *In practice, architecture is embodied in and recoverable from code, and many languages provide architecture-level views of the system. For example, Ada offers the ability to view a system just in terms of its package specifications, which are the interfaces to components. However, Ada offers little or no architecture-level analytical capabilities, nor does it provide architecture level insight into how the components are "wired" together.
@@ Line 91: / Line 91: @@
 '''Architecture Description Languages: Mainstream and Experimental'''<ref>Architecture Description Languages: Mainstream and Experimental [https://iasaglobal.org/itabok/capability-descriptions/architecture-description/ IASA]</ref><br />
-*Architecture Description languages are still largely a research activity with only 2 languages really considered “mainstream”, with UML an established and generally accepted “lingua franca” of software design, and ArchiMate being a recently emerging but widely supported ADL.
+*Architecture Description languages are still largely a research activity with only 2 languages really considered “mainstream”, with UML an established and generally accepted “lingua franca” of software design, and [[ArchiMate]] being a recently emerging but widely supported ADL.
 **[http://www.uml.org UML]
 **[http://www.opengroup.org/subjectareas/enterprise/archimate ArchiMate]
@@ Line 127: / Line 127: @@
 ===Further Reading===
-*An Overview of Software Architecture Description Language and Evaluation Method [https://link.springer.com/chapter/10.1007/978-3-642-31698-2_126 Yang LinglingZhao Wei]
+*An Overview of [[Software Architecture]] Description Language and [[Evaluation]] Method [https://link.springer.com/chapter/10.1007/978-3-642-31698-2_126 Yang LinglingZhao Wei]
 *A Survey of Architecture Description Languages [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.625.6415&rep=rep1&type=pdf Paul C. Clements]
 *Architectural description languages (ADLs) vs UML: a review [https://dl.acm.org/citation.cfm?id=1764828 R. K. Pandey]
 *Defining an Architecture Description Language for Dassault Systèmes [https://pdfs.semanticscholar.org/05a2/23911775d415b6fdc82875f9e0b168997b43.pdf Yves Ledru, Rémy Sanlaville, Jacky Estublier]

← Older revision		Revision as of 19:55, 11 December 2019
Line 1:		Line 1:
−	An Architecture description language (ADL) is domain-specific modeling language for [[Enterprise_Architecture_Management_(EAM)\|EAM]]. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express system architectures. That means, ADLs provide a set of rules and common practices for the creation of visualizations like e.g. flow diagrams or organization charts. The resulting visualizations address concerns of EAM stakeholders and can be grouped into views. ADLs are often supported by EAM tools to aid the creation, use and analysis of its models and visualizations.<ref>Defining Architecture Description Language (ADL) [http://eam-initiative.org/pages/ir4pt24usy4d/Architecture-Description-Language-ADL eam-initiative.org]</ref>	+	An '''Architecture description language (ADL)''' is domain-specific modeling language for [[Enterprise_Architecture_Management_(EAM)\|EAM]]. Architecture description languages (ADLs) are any kind of modeling language, that can be used to express system architectures. That means, ADLs provide a set of rules and common practices for the creation of visualizations like e.g. flow diagrams or organization charts. The resulting visualizations address concerns of EAM stakeholders and can be grouped into views. ADLs are often supported by EAM tools to aid the creation, use and analysis of its models and visualizations.<ref>Defining Architecture Description Language (ADL) [http://eam-initiative.org/pages/ir4pt24usy4d/Architecture-Description-Language-ADL eam-initiative.org]</ref>