| [1] | Nenad Medvidovic and Richard N. Taylor. A classification and
comparison framework for software architecture description language.
IEEE
Transactions on Software Engineering, 26(1):70-93, January 2000. [ bib ] A good starting point for studying Architectural Description Languages. A survey kind of paper published in the year 2000. Surveys almost all the ADLs. The paper identifies abstractions necessary for describing software architectures. Paper claims that components, connectors and architectural configurations are the basic building blocks for ADL. Paper conceptually defines what it means to be components, connectors and configurations in the context of ADLs. Provides answer the question why these abstractions are necessary to be supported by ADLs? Then paper elaborates on how these abstractions are supported in different ADLs. Paper also discusses tool support for each language. |
| [2] | David Garlan Robert Allen. A case study in architectural
modeling: The aegis system. 8th Workshop on Software
Specification
and Design (IWSD-96), pages 6-15, March 1996. [ bib ] This paper applies Wright ADL to model a military application called AEGIS. Familiarity with CSP notation is expected from the reader. This Paper is easier to comprehend if reader has read the paper, Formal basis of Architectural Connection. Application is modeled in Client/Server architectural style. Identifies component in the AEGIS system. (Domain Modeling). Defines behavior in term of three processes i.e., ClientPullT, ServerPushT, and ClientServer. Builds a system by instantiating appropriate number of components. Claims that certain kind of reasoning, for example, absence of deadlock, and substitutability of components, is possible to be performed. Satates that lack of dynamic modeling is the weakness of Wright |
| [3] | Medvidovic Richard N. Taylor, Nenad. A component and message based
architectural style for gui software. IEEE Transactions on
Software Engineering, 22(6):390-406, June 1996. [ bib ] This is one of the earliest
papers discussing the C2
Architectural style. An
architectural
style puts constraints on how components are interconnected through
connectors.
One of the definitions of software architecture describes
architecture as 3Cs
i.e. Components, Connectors and Constraints. C2 architectural style
provides
better insight on what role is played by constraints in defining
software
architecture configuration.
The paper gives the structure of C2 Component, describes rules for composition of connectors and provides three examples i.e. Petri Net Simulator, Meeting Scheduler and KLAX (video game), which are modeled in C2 style. Argo a tool that checks c2 specification provides critical feedback and that generates c++ code is also discussed in the paper. |
| [4] | Mary Shaw and David Garlan. Characteristics of
higher-level languages
for software architecture. Technical Report CMU-CS-94-210,
School of
Computer Science and Software Engineering Institute, Carnegie Mellon
University, USA, December 1994. [ bib ] The report identifies the characteristics of an ADL along-with what constructs should be present in an ADL. An ideal ADL should have support for hierarchical definition of a system, components and connectors are the necessary abstractions that must be present in an ADL, should provide reusability of components and connectors, support for static and dynamic configuration, interchange of architectural descriptions, and analysis of architectural descriptions. Report also highlights the weaknesses of using module interconnection languages for describing architectures. |
| [5] | Mary Shaw.
Procedure calls are the assembly language of
software
interconnection: Connectors deserve first class status.
Technical
Report CMU-CS-94-107, School of Computer Science and Software
Engineering Institute Carnegie Mellon University, January 1994. [ bib ] The report
argues the case of treating connectors
as first class entities like components in an ADL.
Connectors in ADL are responsible for mediating
interactions
among components. In most of the application connection logic is hidden
into
components. The main benefit of treating connector like component is
that reuse
of connection logic is possible.
|
| [6] | David Garlan. Acme:
An architecture description
interchange language. Proceedings
of CASCON'97, November 1997. [ bib ] The paper is
specific to ACME ADL. ACME is an
interchange language that makes
possible to inter-operate architectural description. The paper presents
a brief
survey on different ADLs and tradeoffs present in designing an
interchange
language. The significance and necessity of ADL abstractions like
Components,
Ports, Connectors, Roles, System, Representations and Representation
maps is discussed
along with syntax and semantics for these abstractions. Example
description in
ACME is also provided in the paper.
|
| [7] | David Garlan. Higher
order connectors. Workshop on
Compositional
Software Architectures, January 1998. [ bib ] This is an extension of the case of treating connectors are first class entities. Higher order connectors allow us to define new connector from existing one. Asks for the mechanisms should be present in an ADL to define higher order connectors. Situations like secured communication, filtering of messages, compression of communicated data are few examples where higher order connectors are useful. |
| [8] | Judy Bishop. Connectors
in configuration programming
languages are they
necessary? 3rd International Conference on Configurable
Distributed System (ICCDS-96), May 1996. [ bib ] The paper demands support for explicit mechanisms for defining connectors in programming languages. Also discusses three different approaches to specify connections i.e. implicit connection, pre-defined fixed set of connectors, and user-defined connectors. Discusses pros and cons of implementing connectors in programming languages using these approaches. |
| [9] | Nikunj R. Mehta. Towards a taxonomy of software
connectors. In 22nd
International Conference on Software Engineering, June 2000. [ bib ] <> This paper classifies and creates a catalogue of software connectors based on types of services offered by them. Communication, Coordination, conversion and facilitation are the main services offered by the connectors. Paper identifies connector types as Procedure calls, Streams, Adaptors, Arbitrators, Distributor, Events, linkage and data accesses. The paper explains the functionalities of these connectors using examples for each of them. The paper identifies connectors in the Linux Architecture. The examples of connectors found in the Linux architecure are Process Schedular, File Façade, and Shared Memory. Thes connectors are composed from basic types of connectors. The paper does not specify rules for conenctor composition. The paper highlights the benefits of such classification and categorization. There are other disciplines where such classification and categorization failed. |
| [10] | Mary Shaw. Abstractions
and implementations for
architectural
connections. 3rd International Conference on Configurable
Distributed System (ICCDS-96), May 1996. [ bib ] The paper takes the compiler directed approach for implementing connector. After identifying the types of connectors required for implementing a software system as a set of interconnecting components, the paper proceeds with by enumerating tools/resources/mechanisms (products) required to implement connector. A compiler is used to generate the code for connector abstractions. The paper exemplifies the approach by implementing a real time scheduler as a connector. (RTSchedular) |
| [11] | Nenad Medvidovic. Modeling
software architectures in
unified modeling
language. ACM Transactions on Software Engineering and
Methodology,
11(1):2-57, January 2002. [ bib ] This paper discusses use of UML for describing architectures. Architectural abstractions are not directly supported by UML. Paper first tries to use UML as it is for modeling C-2 style application. Architecture of meeting scheduler, a candidate problem for architectural modeling, is implemented using UML. This exercise highlights certain limitations.In the second approach, UML stereotypes are defined to implement architectural abstractions in C2-ADL, Wright, and Rapide. Stereotypes defined for this purpose constrains modeling capability of UML metaclasses. The paper concludes with that architectural abstractions are not effectively supported by UML. To support architectural abstractions effectively, UML is required to be extended rather than constrained. Approach of extending UML limits use of UML tools for architectural modeling. It will be an interesting to redo the same exercise with UML 2.0. |
| [12] | Peyman Oreizy. On
the role of connectors in modeling and
implementing
software architecture. Technical Report 98-04, Department of
Information and Computer Science, University of California, Irvine,
Feb. 1998. [ bib ] |
| [13] | Mary Shaw. Abstractions
for software architectures and
tools to support
them. IEEE Transactions on Software Engineering,
21(4):314-335, April 1995. [ bib ] The paper describes a connector oriented architectural description language. Syntax and semantics of the UniCon constructs are defined in the paper. The semantics for connector is well defined. UniCon supports a library of predefined connector. Connector composition and user defined connectors are not allowed. |
| [14] | Eric M. Dashofy.
An infrastructure for the rapid
development of
xml based architecture description language. In Proceedings
of the
24th International Conference on Software Engineering (ICSE-2002),
2002. [ bib ] The paper describes XML based ADL at XML schema level along-with the tool support for such language. |
This file has been generated by bibtex2html 1.74