Abowd, G. D., Allen, R. J. and Garlan, D. Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodology, 4(4): 319-364, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of their concerns and their generalization, and the understanding how one models and deals with those concerns. 2.1. 2 Advantages of Software Architecture Models The advantages of creating explicit software architecture models and architectural descriptions have been identified by many [AAG95, SG96, BCK98] Communication among stakeholders Architectural description, as a common highlevel abstraction and common vocabulary, can be used by the system s stakeholders to decrease the complexity in their interaction by providing a language that is abstract enough to facilitate e#ective ....

G. Abowd, R. Allen, and D. Garlan. Formalizing style to understand descriptions of software architecture. ACM Transactions on Software Engineering and Methodology, October 1995.

.... (component interaction facilities) configurations (specific compositions of components and connectors) and constraints placed on them [19] The system composition patterns and their constraints comprise architectural styles, which are targeted at families of systems with shared characteristics [1,25]. Styles are therefore reusable software architectural idioms. There are many architectural styles currently in use: client server, pipe and filter, push based, layered, blackboard, and so forth [30] A large number of these styles have not been formally described, and the exact characteristics ....

....comparison of different styles to understand their strengths and weaknesses in order to enable the selection of styles most appropriate for a given application. Attempts have been made to develop systematic techniques for dealing with architectural styles resulting in formalisms to describe styles [1,15], preliminary taxonomies [29] and informal discussions of the differences between a newly codified style and existing styles that have influenced it [11,31] However, for the most part these studies fail to clarify the key dimensions along which one architectural style may differ from another. ....

[Article contains additional citation context not shown here]

G. D. Abowd, R. Allen and D. Garlan, "Formalizing Style to Understand Descriptions of Software Architecture", ACM Trans. on Software Engineering and Methodology, 4(4), Oct. 1995, pp. 319-364.

....Networks] Distributed Systems. 1. Introduction Architectural specifications have an increasingly important role in the design and development of computer based systems. This role is evidenced by the emergence of software architecture with its formal underpinnings as a distinct field [28,50,55,3,18,13], and by the proliferation of specialized methods and notations for architectural descriptions of software [6,14,27,43,53,26] Besides their use as documentation and as an abstraction mechanism to manage structural complexity, architectural specifications can also aid in rigorous system ....

G. Abowd, , R. Allen, and D. Garlan. Formalizing style to understand descriptions of software architecture. Technical Report CMU-CS-95-111, Carnegie Melon University, School of Computer Science, Pittsburgh, PA, March 1995.

....itself. An Architectural Description Language (ADL) should be used to create specifications that reflect both such aspects. Early work in Software Architecture focused on categorizing different architectural styles, sets of design rules for composing an application from inter connected components [1]. Many ADLs have been proposed that can describe, model, and analyze the specific architecture forasoftware systems [2, 20,21] Implicitly, however, the target audience for an ADL specification has been the designers and developers of the original system. We believe that an ADL specification for a ....

G. D. Abowd, R. Allen, and D. Garlan. Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodology, 4(4):319--364, October 1995.

.... final product by permitting analyses to be performed early in the life cycle [5, 13, 23] Consequently, much e#ort has been devoted to researching, experimenting with, and categorizing the kinds of analyses that can be performed and the product quality attributes that can be improved through them [1, 3, 4, 7, 8, 9, 14, 15, 17, 18, 19, 21, 22]. Despite the significant amount of research in architectural specification, there has been little attempt to formally relate it to higher levels of specification, such as the system requirements [24] Only recently has interest begun to emerge in this regard [16, 20] In this paper we present our ....

G.D. Abowd, R. Allen, and D. Garlan. Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodology, 4(4):319-- 364, October 1995.

.... among and analysis of existing interaction schemes, plus the 10 specification of new connectors [MMP00] Formal descriptions of connectors have been expressed in several architectural description languages (ADLs) A97, AG97, GMW97, LV95, MRT99, MDEK95] as well as in the Z and Object Z notations [AAG95, PGKD00, STI97]. As their potential for contribution to analysis has been recognized, research is ongoing to capture and describe architecture integration functionality in terms of connectors [K99, KG98, SG01] 2.4 Integration Elements Integration elements can be defined as architectural connectors for ....

Abowd, G., Allen, and R.,Garlan, D. Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodologies (1995), 4(4): 319-364.

....style, which provides information regarding pattern based configuration and coordination constraints. Often driven by connectors (interaction mechanisms) architectural styles have been both formally and informally defined for systems such as pipe and filter, event based, and main subroutine [2,14,21,24,31]. As a result, there are many types of connectors that range from simple to complex, with variants at every level and taxonomies to express and relate them [19,22] Architectural characteristics have been researched to further differentiate individual styles, their extensions, and ....

Abowd, G., Allen, A., Garlan, D. Formalizing Style to Understand Descriptions of Software Architecture. ACM TOSEM, 4(4): 319-364, 1995.

.... SIT97, KCBA97, YBB99] Characteristics are defined and utilized to aid in the detection of mismatch (see Appendix A) The phrase architecture mismatch is used to describe the underlying reasons for interoperability problems among seemingly open software components with available source code [AAG95]. Characterizing software architecture styles (i.e. 10 event based or pipe and filter) provides additional details that further differentiate these styles. Gacek [GAC97] and Abd Allah [ABD96] define characteristics that typify components, connectors and the constraints therein, as well as, ....

....are more often than not black box, these properties reside at a level of abstraction that makes their qualification a possibility. Knowing the style in which the product was developed, or the language used to implement it, allows some assumptions about its properties, data, control, and system [AAG95]. Indeed, the consumer driven description of software 51 provides useful information about its interface. Operating systems, which need to fulfill consumer profiles of personal user, network user, server, etc, define the operations which it must contain to fulfill its promise to that particular ....

Abowd, G., Allen, A., Garlan, D. Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodologies,4(4): 319-64, 1995.

....without benefit of source code. Particularly with COTS, this information tends to be illuminating in an abstract way. For example, if you know the style in which the product was developed, or the language used to implement it, some assumptions about its topology, both data and control, can be made [2]. Indeed, the nature of the software sometimes provides useful information about its interface, such as operating systems which need to fulfill consumer profiles of personal user, network user, server, etc. Guidelines for determining values for characteristics such as control structure, supported ....

G. Abowd, R. Allen and D. Garlan, Formalizing Style to Understand Description of Software Architecture, ACM TOSEM, 4(4):319-364, 1995.

....component can be difficult to formally specify. 2.2. Formal methods in software architecture In this section we will briefly review the literature in terms of the utilization of formal approaches to the specification of architectural styles. In developing a software architecture, Abowd, et al. [5] formally specify three syntactic classes: components, connectors, and configurations. A component consists of a set of ports (incoming and outgoing) and a description, a connector consists of a set of roles (incoming and outgoing connections to ports) and a description, and a configuration ....

....outgoing) and a description, a connector consists of a set of roles (incoming and outgoing connections to ports) and a description, and a configuration describes a generic attachment function that binds connector roles to component ports. Using these generic primitives as a basis, Abowd, et al. [5] developed formal models in the Z notation [9] of the pipe and filter style, and event system architectural style. We extend their approach to specify the architectural abstractions of the rule based architectural styles, presented in Section 3. 2.2.1. The basic Z notation Z [9] has a special ....

[Article contains additional citation context not shown here]

G. Abowd, R. Allen, D. Garlan, Formalizing Style to Understand Description of Software Architecture, ACM TOSEM, submitted for publication.

.... By using a taxonomy, fundamental features of middleware functionality, proprietary extensions, and application assumptions can be modeled uniformly using combinations of semi formal languages (e.g. the UML [RC99] and formal languages (e.g. Object Z [DRS94] for architectural descriptions [AAG95, RMRR98, GSP99, GPK99, MR99], inheritance, refinement, temporal reasoning, and proofs. Based on these models, a theory will emerge to define the middleware conflicts and the essential parts needed to connect component based systems, providing a formal underpinning for our third and final thrust. 4. Facilitating Software ....

G. Abowd, R. Allen, and D. Garlan. Formalizing Style to Understand Descriptions of Software Architecture. ACM TOSEM, 1995.

....model that functionality architecturally. Subsequently, we have defined three integration elements called translator, controller and extender and described their connector models. These have evolved from Butler s modeling research [Butler99] definitions stemming from architecture style modeling [AbdAllah96, AAG95, GSP99, SGa97], case study analysis [Cole97, GAO95, Sitarman97] and the study of integration strategies [BMRSS95, BS95, GHJV95, Lea94, Mularz94] These integration elements express the primary functional needs for an integration strategy to resolve interoperability problems. Composing the connector models, we ....

G. Abowd, R. Allen and D. Garlan. Formalizing Style to Understand Description of Software Architecture. ACM TOSEM, 4(4):319-364, 1995.

....to provide primitive dimensions of fix up then back up to the characteristics that cause the need for the fix up [21] In this regard, we define integration elements that are at the same abstraction level as component architecture descriptions. These definitions stem from architecture modeling [1, 2, 8, 23] and case study analysis [6, 10, 22] Each element is a minimal model of integration functionality that is based on some model of incompatibility. Composing multiple elements forms an integration architecture. In addition, we present a taxonomy of common integration strategies, demonstrating how ....

G. Abowd, R. Allen and D. Garlan. Formalizing Style to Understand Description of Software Architecture. ACM TOSEM, 4(4):319-364, 1995.

.... can allow for design choices among and analysis of existing interaction schemes, plus the specification of new connectors [11] Formal descriptions of connectors have been expressed in several architectural description languages (ADLs) 3,13,19,20,22] as well as in the Z and Object Z notations [2,25,31]. Unfortunately, connectors suffer from similar problems in characterization as components and architectural styles. There are many types of connectors that range from generic to complex, with variants at every level. The impetus behind connector taxonomy research is to allow designers ....

Abowd, G., Allen, A., Garlan, D. Formalizing Style to Understand Descriptions of Software Architecture. ACM TOSEM (1995), 4(4): 319-64.

.... system is a highlevel description of its computational elements, the means by which they interact, and the structural constraints on interaction [29,32] On the basis of architecture mismatch, characteristics have been specifically viewed with respect to their potential impact on interoperability [1,2,3,4,10,13,31,33]. We have expanded on this effort to classify and relate published characteristics resulting in a highly relevant set for interoperability analysis [8] Connectors have become increasingly important in software architecture analysis, having been relegated to first class status in many ....

Abowd, G., Allen, A., Garlan, D. Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodologies, 4(4): 319-64, 1995.

....without over formalizing, because of its coarse grained descriptions of computational entities and their allowable connectivity within an application. Architectural styles and patterns have been modeled formally and informally with respect to the underlying components or modules, and connectors [1, 9, 11]. Furthermore, current research is defining architecture characteristics whose comparisons point to potential interoperability problems [10] As patterns of conflicts emerge, defining mappings from conflicts to integration solutions is the next step. Thus, for seamless analysis and design of the ....

.... in) out = y Same as ComposerController except out must be empty before the next output is determined Figure 6: Formal Model of Composer Controller and Specialized Sequencer The templates for these models are loosely based on earlier models of the pipe and filter and event based styles [1]. In these models, connectors were explicitly specified to transfer the data between components. We have since normalized the templates to take advantage of inheritance and refinement. The models presented in Figures 5 and 6 do not require explicit 13 connectors. Rather, transfer operation ....

G. Abowd, R. Allen, D. Garlan. Formalizing style to understand descriptions of software architecture. ACM TOSEM, 1995.

....of system quality attributes by construction. 3.1 Premises of PACC The study of software architectural styles supports the first premise. An architectural style is a recurring design pattern, usually expressed as a set of component types and constraints on their allowable interactions [1,7]. Architectural styles provided the first link between structural design constraints and system properties. For example, the pipe and filter style yields systems that can be easily restructured. However, the link between system level quality attribute and architectural style is informal and ....

G. D. Abowd, R. Allen and D. Garlan, Formalizing Style to Understand Descriptions of Software Architecture, ACM Transactions on Software Engineering and Methodology, Vol. 4, No. 4, October,

.... They include four books ( 6] 10] 59] 63] 1995 to 1998) eight papers dealing with architectures for particular domains ( 11] 12] 13] 24] 32] 34] 38] 40] 1990 to 1995) seven papers presenting surveys or models for the field ( 17] 21] 20] 46] 51] 57] 58] 1992 to 1995) three formalizations ( 1][2][45] 1993 to 1996) and one paper each on an architecture description language [56] and reverse engineering [67] Unsurprisingly, they generally represent the first three phases of development. Imperfect though this estimate may be, it still indicates very substantial growth since 1995 and a ....

....and styles, compilation to code) and Wright [3] component interaction) Formalizations developed in parallel with the language development. Sometimes this was integral to the language (Darwin, Rapide, Wright) and in other cases it was more independent, as the formalization of style [1][2] or formal analysis of inconsistency in a specific architectural model [60] Recognition that multiple views must be reconciled in architectural analysis [31] helped to frame the requirements for formalism. The early narrative catalogs of styles were expanded in taxonomies of styles [55] and of ....

Gregory Abowd, Robert Allen, and David Garlan. Formalizing style to understand descriptions of software architecture. ACM Tr on Software Engineering and Methodology, 1995.

.... In the last five years, software architecture has attracted the attention of the software engineering community with the seminal works of Garlan and Shaw [17] and Perry and Wolf [37] Much work has been published on module interconnection languages [36,38] architectural description languages [2,5], design patterns [12,16] and formal models for component integration [32,35,42] The high diffusion of distributed, client server systems and remote objects, has pushed towards the development of interface description languages [28] which allow to control the exchange of structured data between ....

G. Abowd, R. Allen, and D. Garlan. Formalizing style to understand descriptions of software architecture. Technical Report CMU-CS-95-111, Carnegie Mellon University, Jan. 1995.

....NF requirement) any constraint referred to a subset of the NFattributes that are in use in a particular software unit. 2. A Model for Software Architecture Our model for software architecture distinguishes two usual kinds of units, components and connectors. 2. 1 Components According to [1], components are the active, computational entities of a system. The relationship between a component and its environment is defined explicitly as a collection of interaction points, or ports . In our current framework, we restrict ourselves to software components, although we feel that most of ....

....our work we have not bound yet non functional information to any of these component types, but directly to component instances. Non functional issues will be introduced in architectures using the language presented in section 3. 2.2. Connectors Once again, we adopt the definition appearing in [1] that states that connectors define the interaction between components. Each connector provides a way for a collection of ports to come into contact and logically defines the protocol through which a set of components will interact . Connectors can be then as diverse as: method invocation, ....

[Article contains additional citation context not shown here]

G.D. Abowd, R. Allen, D. Garlan. "Formalizing Style to Understand Descriptions of Software Architecture". ACM Transactions on Software Engineering and Methodology, 4(4), pp. 319-364, October 1995.

.... behaviour of a specific architecture (i.e. the one of a compiler) in [Inverardi Wolf 1995] The Z language has been used to characterise architectural styles and has later led to define a framework for such characterisations so as to enable comparing styles sharing a common semantic model [Abowd et al. 1995]. Logic has been used in [Moriconi et al. 1995] for supporting correct stepwise refinement of configurations. Graph grammars are exploited in [Le Metayer 1996] for enabling constrained architecture evolution. The advantages of introducing ADLs over the above works are obvious with respect to ....

G. Abowd, R. Allen and D. Garlan "Formalizing Style to Understand Descriptions of Software Architecture", ACM Transactions on Software Engineering and Methodology (TOSEM), 4(4), pp. 319-364, 1995.

No context found.

Gregory Abowd, Robert Allen, and David Garlan. Formalizing style to understand descriptions of software architecture. ACM Transactions on Software Engineering and Methodology, October 1995.

No context found.

Abowd, G. D., Allen, R. J. and Garlan, D. Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodology, 4(4): 319-364, 1995.

No context found.

. Gregory Abowd, Robert Allen, and David Garlan, Formalizing Style to Understand Descriptions of Software Architecture, ACM Transactions on Software Engineering and Methodology, Vol. 4, No. 4, October 1995.

No context found.

G.D. Abowd, R. Allen, and D. Garlan. Formalizing style to understand descriptions of software architecture. ACM Transactions on Software Engineering and Methodology, 4(4):319--364, Oct 1995. .

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC