Exploiting ADLs to specify architectural styles induced by middleware infrastructures
E. di Nitto, und D. Rosenblum. Proceedings of the 1999 International Conference on Software Engineering, 1999, Seite 13--22. IEEE, (Mai 1999)
Zusammenfassung
Architecture definition languages (ADLs) enable the formalization of the architecture of software systems and the execution of preliminary analyses on them. These analyses aim at supporting the identification and solution of design problems in the early stages of software development. We have used ADLs to describe middleware-induced architectural styles. These styles describe the assumptions and constraints that middleware infrastructures impose on the architecture of systems. Our work originates from the belief that the explicit representation of these styles at the architectural level can guide designers in the definition of an architecture compliant with a pre-selected middleware infrastructure, or, conversely can support designers in the identification of the most suitable middleware infrastructure for a specific architecture. In this paper we provide an evaluation of ADLs as to their suitability for defining middleware-induced architectural styles. We identify new requirements for ADLs, and we highlight the importance of existing capabilities. Although our experimentation starts from an attempt to solve a specific problem, the results we have obtained provide general lessons about ADLs, learned from defining the architecture of existing, complex, distributed, running systems.
Proceedings of the 1999 International Conference on Software Engineering, 1999
Jahr
1999
Monat
may
Seiten
13--22
Verlag
IEEE
isbn
1-58113-074-0
review
SUMMARY (Fritz) Use ADLs to specify architectural styles/patterns of event based architectures - main focus: ARMANI & Rapide Also identify requirements for ADLs REQUIREMENTS FOR ADLs - assembling composite components & connectors (different levels of abstraction of architecture) - CLAIMS: - Many available ADLs themselves introduce architectural assumptions which can conlict with the ones of the target architecture EXAMPLE ARCHITECTURES USED: JEDI - normal event-driven/space based architecture C2 - Components across levels of granularity decoupled by communication buses (one communication bus between each level of granularity) ADLs USED: ARMANI: Components (with ports) & connectors (with roles and data types), both constrained with OCL-like constraints. Systems assembled by instantiating components and connectors and connecting them through ports. Rapide: Essentially process design, not architecture (functions, events, behavous, constraints on behaviour) Darwin: components (simple & composite), services, bindings. Components require & provide services ala UML. Some support for dynamic component construction (see nice example on top of 2nd column on p19). Darwin \textless-\textgreater CORBA IDL mappings exist. Wright: Similar structure specification to that of ARMANI (components, connectors, ports, roles, attachments, ..). Augments structure by supporting a subset of CSP to specify processes on both, components and connectors. GENERAL STATEMENTS: A style defines a set of general rules that describe or constrain the structure of architectures und the way their components interact. They are used for categorizing architectures.
%0 Conference Paper
%1 di_nitto_exploiting_1999
%A di Nitto, E.
%A Rosenblum, D.
%B Proceedings of the 1999 International Conference on Software Engineering, 1999
%D 1999
%I IEEE
%K Architecture; Computer Information Middleware; Performance Permission; Programming; Robustness; Software analysis; architectural architecture architecture; client-server complex definition design development; distributed formal formalization; high infrastructures; languages; level middleware problems; science; software specification; style systems systems; {ADLs};
%P 13--22
%T Exploiting ADLs to specify architectural styles induced by middleware infrastructures
%X Architecture definition languages (ADLs) enable the formalization of the architecture of software systems and the execution of preliminary analyses on them. These analyses aim at supporting the identification and solution of design problems in the early stages of software development. We have used ADLs to describe middleware-induced architectural styles. These styles describe the assumptions and constraints that middleware infrastructures impose on the architecture of systems. Our work originates from the belief that the explicit representation of these styles at the architectural level can guide designers in the definition of an architecture compliant with a pre-selected middleware infrastructure, or, conversely can support designers in the identification of the most suitable middleware infrastructure for a specific architecture. In this paper we provide an evaluation of ADLs as to their suitability for defining middleware-induced architectural styles. We identify new requirements for ADLs, and we highlight the importance of existing capabilities. Although our experimentation starts from an attempt to solve a specific problem, the results we have obtained provide general lessons about ADLs, learned from defining the architecture of existing, complex, distributed, running systems.
%@ 1-58113-074-0
@inproceedings{di_nitto_exploiting_1999,
abstract = {Architecture definition languages {(ADLs)} enable the formalization of the architecture of software systems and the execution of preliminary analyses on them. These analyses aim at supporting the identification and solution of design problems in the early stages of software development. We have used {ADLs} to describe middleware-induced architectural styles. These styles describe the assumptions and constraints that middleware infrastructures impose on the architecture of systems. Our work originates from the belief that the explicit representation of these styles at the architectural level can guide designers in the definition of an architecture compliant with a pre-selected middleware infrastructure, or, conversely can support designers in the identification of the most suitable middleware infrastructure for a specific architecture. In this paper we provide an evaluation of {ADLs} as to their suitability for defining middleware-induced architectural styles. We identify new requirements for {ADLs}, and we highlight the importance of existing capabilities. Although our experimentation starts from an attempt to solve a specific problem, the results we have obtained provide general lessons about {ADLs}, learned from defining the architecture of existing, complex, distributed, running systems.},
added-at = {2013-02-28T11:13:35.000+0100},
author = {di Nitto, E. and Rosenblum, D.},
biburl = {https://www.bibsonomy.org/bibtex/2bf3796f5b42733fc2da99a73e84bf51e/fritzsolms},
booktitle = {{Proceedings of the 1999 International Conference on Software Engineering, 1999}},
interhash = {2b568cee13bf9ec5524efc228789a43c},
intrahash = {bf3796f5b42733fc2da99a73e84bf51e},
isbn = {1-58113-074-0},
keywords = {Architecture; Computer Information Middleware; Performance Permission; Programming; Robustness; Software analysis; architectural architecture architecture; client-server complex definition design development; distributed formal formalization; high infrastructures; languages; level middleware problems; science; software specification; style systems systems; {ADLs};},
lccn = {0126},
month = may,
pages = {13--22},
publisher = {{IEEE}},
review = {{SUMMARY} {(Fritz)} Use {ADLs} to specify architectural styles/patterns of event based architectures - main focus: {ARMANI} \& Rapide Also identify requirements for {ADLs} {REQUIREMENTS} {FOR} {ADLs} - assembling composite components \& connectors (different levels of abstraction of architecture) - {CLAIMS:} - Many available {ADLs} themselves introduce architectural assumptions which can conlict with the ones of the target architecture {EXAMPLE} {ARCHITECTURES} {USED:} {JEDI} - normal event-driven/space based architecture C2 - Components across levels of granularity decoupled by communication buses (one communication bus between each level of granularity) {ADLs} {USED:} {ARMANI:} Components (with ports) \& connectors (with roles and data types), both constrained with {OCL-like} constraints. Systems assembled by instantiating components and connectors and connecting them through ports. Rapide: Essentially process design, not architecture (functions, events, behavous, constraints on behaviour) Darwin: components (simple \& composite), services, bindings. Components require \& provide services ala {UML.} Some support for dynamic component construction (see nice example on top of 2nd column on p19). Darwin {\textless}-{\textgreater} {CORBA} {IDL} mappings exist. Wright: Similar structure specification to that of {ARMANI} (components, connectors, ports, roles, attachments, ..). Augments structure by supporting a subset of {CSP} to specify processes on both, components and connectors. {GENERAL} {STATEMENTS:} A style defines a set of general rules that describe or constrain the structure of architectures und the way their components interact. They are used for categorizing architectures.},
timestamp = {2013-02-28T11:14:02.000+0100},
title = {{Exploiting {ADLs} to specify architectural styles induced by middleware infrastructures}},
year = 1999
}