. In this paper we introduce a formal approach to architectural design patterns based on an object-oriented model integrated with a process-oriented method for describing the patterns. The object-oriented model is based on the Abstract Data View (ADV) concept, which is a formal model for subjectivity in that it explicitly distinguishes between two kinds of objects, namely application objects and object views. The formalism allows the definition and application of design patterns by considering both the process program for the pattern tasks and the interconnected objects and views resulting from a particular pattern instantiation. The approach can be used to describe design patterns at many different architectural levels, and this is illustrated by presenting patterns for the master-slave, pipes-and-filters, layered systems, adapter, observer, and composite. 1 Introduction Design patterns can be viewed as a means to achieve large-scale reuse by capturing successful softwar...

Language by

In this paper we motivate and describe a logic-based specification framework for objects and interfaces based on Abstract Data Views, a formal model for specifying interfaces. Abstract Data Views (ADVs) are Abstract Data Objects (ADOs) or objects that have been specifically augmented to support the specification of interfaces: interfaces between application components (ADOs) or between application components and an "external" environment such as a user or a network. The central mathematical tools used for this purpose are temporal logic (or deontic action logic) and some tools from category theory (institutions). Essentially, temporal logic is used to represent the individual ADVs or ADOs and the tools from category theory are used to represent the amalgamation of these components into a structure. Both ADVs and ADOs will basically be represented by tuples ! DT ; AT ; AC; AX ?, where DT is a data signature, AT is a set of attributes (state memory), AC is a set of actions that can quer...

In this paper we present a formal approach to define and apply design patterns that is both process- and reuse-oriented. Initially we use a process program based on design pattern primitive tasks or constructors to describe how to instantiate a pattern. As we develop the patterns we introduce a formal model for the interconnected objects that constitute the instantiation. The formal model which is based on Abstract Data Views divides designs into both objects and views in order to maintain a separation of concerns. We have chosen a formal model for pattern definition and application since it allows us to specify the steps in pattern instantiation unambiguously and to reason about the completed design. Furthermore, a formal statement of the application of a design pattern can provide the foundation on which to build tools to assist the programmer in code generation. 1 Introduction Design patterns[GHJV95, CS95, Coa95] can be viewed as an approach to encapsulating "good practice" in obje...

In this article we present a tool for the formal definition and application of design patterns that is both process- and reuse-oriented. A formal model for design patterns allows us to unambiguously specify the steps in pattern instantiation. The model is based on Abstract Data Views and divides designs into both objects and views in order to maintain a separation of concerns. This formalism also provides a foundation for both tool support and code generation.

This paper presents a formal transformational process-based approach to object-oriented design. This approach uses a process language that allows us to represent the changes of the object models through the design process and, in particular, the changes induced by the application of design patterns. The approach is illustrated through a small example dealing with expression trees that is designed based on three design patterns: the bridge, the abstract factory, and the adapter. In this case, we provide an implementation in Prolog that allows us to obtain the object model design of the example by the application of some transformations in a structured semi-automated manner. The processes of this language can be formally defined as schema transformations of theory presentations associated with the object models represented in a particular object calculus. We believe the method scales up to larger systems as it allows architectural object-oriented transformations to be also defined.

Recent implementation languages such as AspectJ and HyperJ allow systems to be decomposed into declaratively complete units. These units are projections of the system, which are partial implementations of the entire system where each program element such as a data structure or procedure may be partially defined in more than one projection. In contrast, traditional languages rely on units that are partitions, which are complete implementations of part of the system: every program element is defined in only one part. Projection-based approaches offer low coupling between units leading to programs that may be easier to maintain and extend. These implementation languages for projection-based systems offer facilities for composing projections to form a complete software package. This composition usually yields a number of complex interactions between the projections. Some of these interactions may manifest themselves as inconsistencies such as undesired interference among projections. Formal verification is an effective mechanism for detecting inconsistencies. However, existing formal specification languages do not provide the means to express the interactions between projections in a clear and concise fashion.

In this paper we have shown how the description of application objects and interface objects can be formalized and applied to the specification of a highly interactive system. We have presented the Abstract Data View (ADV) model which is a design concept for the specification of interfaces. An ADV can be used to represent an interface between a user, a network or a device such as a timer and an Abstract Data Object (ADO), or as an interface between two or more ADOs, where an ADO is a specification for an object's public interface. Thus, ADVs can be viewed as media transformers or transformers between ADOs, and can add a "reuse dimension" to design, since they can determine the way in which one object "views" another, and could support syntactic non-interference and semantic context independence among different object specifications. Our experience has shown that the practical use of ADV/ADOs in object-oriented design is related to both the formulation of reusable design patterns and to...

Data View (ADV) component model [CILS93a, CILS93b, CL95] which can be viewed as a formalism [ACL95d] supporting subject-oriented programming [HO93, HOSD94]. The ADV model which decomposes designs into objects (Abstract Data Objects or ADOs) and views of objects (ADVs) allows us to address related issues such as abstraction, encapsulation, separation of concerns, coupling and cohesion. This model is supported by a logical theory that allows us to reason about the properties of designs, and by schemas that define components and support code generation. 2 The Abstract Data View (ADV) Model An ADO is an object that manages the state of an application and has no direct contact with the "outside" world. As an object an ADO has a state and a public interface that can be used to query or change this state. An ADV is an ADO augmented to support the development of general "views" of ADOs, where a view could include a user interface or an adaptation of the public interface of The work describ...

Both object-orientation and the Internet make the widespread reuse of software a possibility. Unfortunately, the potential benefits from these facilities have not been forthcoming. One reason for this is the lack of a coherent model for software development and reuse. This paper proposes such a model which is based upon modelling software components using state transition machines. Reuse is made possible by defining matching relations between component descriptions in terms of machine simulations. Both the development process and matching relations are given a formal semantics. 2 Introduction The reuse of software components has long been a major aim of Software Engineering [12]. We propose that there are two major reasons why this aim has not yet been realised. Firstly, no single organisation can afford to develop all the software which it will subsequently need to reuse (and until recently there has been no effective mechanism which allows different organisations to pool software r...