Abstract not found

The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia system. The Web has been iteratively developed over the past ten years through a series of modifications to the standards that define its architecture. In order to identify those aspects of the Web that needed improvement and avoid undesirable modifications, a model for the modern Web architecture was needed to guide its design, definition, and deployment. Software architecture research investigates methods for determining how best to partition a system, how components identify and communicate with each other, how information is communicated, how elements of a system can evolve independently, and how all of the above can be described using formal and informal notations. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. An architectural style is a named, coordinated set of architectural constraints. This dissertation defines a framework for understanding software architecture via architectural styles and demonstrates how styles can be used to guide the architectural design of network-based application software. A survey of architectural styles for network-based applications is used to classify styles according to the architectural properties they induce on an architecture for distributed hypermedia. I then introduce the Representational State Transfer (REST) architectural style and describe how REST has been used to guide the design and development of the architecture for the modern Web. REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. I describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles. Finally, I describe the lessons learned from applying REST to the design of the Hypertext Transfer Protocol and Uniform Resource Identifier standards, and from their subsequent deployment in Web client and server software.

Numerous architectural description languages (ADLs) have been developed, each providing complementary capabilities for architectural development and analysis. Unfortunately, each ADL and supporting toolset operates in isolation, making it di cult to integrate those tools and share architectural descriptions. Acme is being developed as a joint e ort of the software architecture research community as a common interchange format for architecture design tools. Acme provides a structural framework for characterizing architectures, together with annotation facilities for additional ADLspeci c information. This scheme permits subsets of ADL tools to share architectural information that is jointly understood, while tolerating the presence of information that falls outside their common vocabulary. In this paper we describe Acme's key features, rationale, and technical innovations. 1

Much of the recent work on Architecture Description Languages (ADL) has concentrated on specifying organisations of components and connectors which are static. When the ADL specification is used to drive system construction, then the structure of the resulting system in terms of its component instances and their interconnection is fixed. This paper examines ADL features which permit the description of dynamic software architectures in which the organisation of components and connectors may change during system execution. The paper outlines examples of language features which support dynamic structure. These examples are taken from Darwin, a language used to describe distributed system structure. An operational semantics for these features is presented in the n-calculus, together with a discussion of their advantages and limitations. The paper discusses some general approaches to dynamic architecture description suggested by these examples. 1

Abstract: The overall structure of a system described by a set of components and their interconnections is termed its software architecture. In this paper, we associate behavioural specifications with components and use these specifications to analyze the overall system architecture. The approach is based on the use of Labelled Transition Systems to specify behaviour and Compositional Reachability Analysis to check composite system models. The architecture description of a system is used directly in the construction of the model used for analysis. Analysis allows a designer to check whether an architecture satisfies the properties required of it. The paper uses examples to illustrate the approach and discusses some open questions arising from the work. 1

attention as an important sub#eld of software engineering. During that time there has been considerable progress in developing the technological and methodological base for treating architectural design as an engineering discipline. However, much remains to be done to achieve that goal. Moreover, the changing face of technology raises anumber of new challenges for software architecture. This paper examines some of the important trends of software architecture in research and practice, and speculates on the important emerging trends, challenges, and aspirations.

Over the past decade, software architecture research has emerged as the principled study of the overall structure of software systems, especially the relations among subsystems and components. From its roots in qualitative descriptions of useful system organizations, software architecture has matured to encompass broad explorations of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. We can understand the evolution and prospects of software architecture research by examining the research paradigms used to establish its results. These are, for the most part, the paradigms of software engineering. We advance our fundamental understanding by posing research questions of several kinds and applying appropriate research techniques, which differ from one type of problem to another, yield correspondingly different kinds of results, and require different methods of validation. Unfortunately, these paradigms are not recognized explicitly and are often not carried out correctly; indeed not all are consistently accepted as valid. This retrospective on a decade-plus of software architecture research examines the maturation of the software architecture research area by tracing the types of research questions and techniques used at various stages. We will see how early qualitative results set the stage for later precision, formality, and automation and how results build up over time. This generates advice to the field and projections about future impact. Keywords: Software architecture, research paradigms 1.

The software architecture of a system is the overall structure of the system in terms of its constituent components and their interconnections. Dynamic changes to the instantiated system architecture -- to the components and/or interconnections - may take place while it is running. In order that these changes do not violate the integrity of the system, we adopt a general model of dynamic configuration which only permits change to occur when the affected portions of the system are quiescent. In this paper we investigate the ability to perform behaviour analysis on systems which conform to the change model. Our analysis approach associates behavioural specifications with the components of a software architecture and analyses the behaviour of systems composed from these components. We use Labelled Transition Systems to specify behaviour and Compositional Reachability Analysis to check composite system models. We model the changes that can occur and use analysis to check that the architect...

A Software Architecture is the overall structure of a system in terms of its constituent components and their interconnections. In this paper, we describe work to associate behavioural specifications with the components of a distributed software architecture and an approach to analysing the behaviour of systems composed from these components. The approach is based on the use of Labelled Transition Systems to specify behaviour and Compositional Reachability Analysis to check composite system models. The architecture description of a system is used directly to generate the model used for analysis. Analysis allows a designer to check whether an architecture satisfies the properties required of it. The approach is illustrated using a case study of an Active Badge system.

Abstract. Software architectures and designs "notations " are typically based on bubble-and-arc diagrams. Embellishing these diagrams may increase their information content but does not make a language. A formal language has syntax, semantics, and inference rules, so that reasoning and automatic manipulation are made possible. We describe LePUS, a formal language for describing and reasoning about object oriented software architectures, designs, and patterns. A LePUS formula imposes constraints on the software at an appropriate level of abstraction but does not unnecessarily restrict the implementation. LePUS is not an ad hoc collection of loosely related concepts but instead originates from an insight on a small number of necessary and sufficient basic "building blocks " that are ubiquitous in object oriented design. A LePUS specification can be expressed as either a formula or a semantically equivalent diagram. We provide examples of LePUS descriptions ranging from simple design patterns, such as FACTORY METHOD, to popular current architectures, such as Enterprise JavaBeans™.