Architectural Patterns for Problem Frames Christine Choppy , Denis - PDF document

Architectural Patterns for Problem Frames Christine Choppy ‡ , Denis Hatebur § and Maritta Heisel ¶ Abstract Problem frames provide a characterisation and classification of software development prob- lems. Fitting a problem to an appropriate problem frame should not only help to understand it, but also to solve the problem (the idea being that, once the adequate problem frame is identified, then the associated development method should be available). We propose soft- ware architectural patterns corresponding to the different problem frames that may serve as a starting point for the construction of the software solving the given problem. We show that these architectural patterns exactly reflect the properties of the problems fitting to a given frame, and that they can be combined in a modular way to solve multi-frame problems. We also provide alternative architectures to cope with specific system characteristics (e.g. distribution). 1 Introduction Pattern-orientation is a promising approach to software development. Patterns are a means to reuse software development knowledge on different levels of abstraction. They classify sets of software development problems or solutions that share the same structure. Patterns have been introduced on the level of detailed object oriented design [9]. Today, pat- terns are defined for different activities. Problem Frames [13] are patterns that classify software development problems . Architectural styles are patterns that characterise software architectures [17, 1]. They are sometimes called “architectural patterns”. Design Patterns are used for finer- grained software design, while frameworks [7] are considered as less abstract, more specialised. ‡ LIPN, UMR CNRS 7030, Institut Galil´ ee - Universit´ e Paris XIII, France, email: Christine.Choppy@lipn.univ- paris13.fr § Universit¨ at Duisburg-Essen, Fachbereich Ingenieurwissenschaften, Institut f¨ ur Medientechnik und Software- Engineering, Germany, email: denis.hatebur@uni-duisburg-essen.de and Institut f¨ ur technische Systeme GmbH, Germany, email: d.hatebur@itesys.de ¶ Universit¨ at Duisburg-Essen, Fachbereich Ingenieurwissenschaften, Institut f¨ ur Medientechnik und Software- Engineering, Germany, email: maritta.heisel@uni-duisburg-essen.de 1

Finally, idioms are low-level patterns related to specific programming languages [3], and are some- times called “code patterns”. Using patterns, we can hope to construct software in a systematic way, making use of a body of accumulated knowledge, instead of starting from scratch each time. It is acknowledged that the first steps of software development are essential to reach the best possible match between the expressed requirements and the proposed software product, and to eliminate any source of error as early as possible. Therefore, we propose to use patterns already in the requirements elicitation phase of the software development life-cycle, as advocated by Fowler [8] or Sutcliffe et al. [19, 20]. M. Jackson [12, 13] proposes the concept of problem frames for presenting, classifying and understanding software development problems. A problem frame is a characterisation of a class of problems in terms of their main components and the connections between these components. Once a problem is successfully fitted to a problem frame, its most important characteristics are known. Gaining a thorough understanding of the problem to be solved is a necessary prerequisite for solving it. However, when using problem frames, one can even hope for more than just a full comprehension of the problem at hand. Since problem frames are patterns, they represent problem structures that occur repeatedly in practice. Hence, it is worthwhile to look for solution structures that match the problem structures represented by problem frames. The construction of the solution of a software development problem should begin with the decision on the main structure of the solution, i.e., a decision on the software architecture. Our aim is to exploit the knowledge gained in representing a problem as an instance of a problem frame in taking that decision. For each problem frame, we propose a corresponding architectural pattern that takes into account the characteristics of the problems fitting to the given problem frame. Our architectural patterns structure the software into layers. Of course, this is not the only possible way of structuring, but a very convenient one. We have chosen it because a layered archi- tecture makes it possible to divide platform-dependent from platform-independent parts, because different layered systems can be combined in a systematic way, and because other architectural styles can be incorporated in such an architecture. That choice has been validated in several industrial projects, dealing for example with smart cards, protocol converters, web/mail-servers, and real-time operating systems. Like problem frames, our architectural patterns must be instantiated to develop a solution for 2

a concrete problem. The structure provided by an architectural pattern constitutes a concrete starting point for the process of constructing a solution to a problem that is represented as an instance of a problem frame. The rest of the paper is organised as follows: after introducing the basic concepts of our work in Section 2, we discuss related work in Section 3. In Section 4, we present the architectural patterns associated with each problem frame. In Section 5, we present an example and show how the different solutions of multi-frame problems can be combined. In Section 6, we conclude with a discussion of our approach and directions for future research. 2 Basic Concepts In this paper, we relate architectural patterns to problem frames. As a notation for our architec- tural patterns, we use composite structure diagrams of UML 2.0. In the following, we give brief descriptions of these three ingredients of our work. 2.1 Problem Frames Jackson [13] describes problem frames as follows: A problem frame is a kind of pattern. It defines an intuitively identifiable problem class in terms of its context and the characteristics of its domains, interfaces and requirement. Solving a problem is accomplished by constructing a “machine” and integrating it into the environment whose behaviour is to be enhanced. For each problem frame a diagram is set up (cf. left-hand sides of Figures 2, 3, 5, 6, 7, and 9). Plain rectangles denote application domains (that already exist), rectangles with a double vertical stripe denote the machine domains to be developed, and requirements are denoted with a dashed oval. They are linked together by lines that represent interfaces, also called shared phenomena. Jackson distinguishes causal domains that comply with some laws, lexical domains that are data representations, and biddable domains that are people. Jackson defines five basic problem frames ( Required Behaviour, Commanded Behaviour, Information Display, Workpieces and Transformation ), and we consider them together with one variant ( Commanded Information ). In order to use a problem frame, one must instantiate it, i.e., provide instances for its domains, 3

interfaces and requirements. A description of these problem frames is given in Section 4 where an associated architecture is proposed. 2.2 Architectural Styles According to Bass, Clements, and Kazman [1], the software architecture of a program or computing system is the structure or struc- tures of the system, which comprise software components, the externally visible prop- erties of those components, and the relationships among them. Architectural styles are patterns for software architectures. A style is characterised by [1]: • a set of component types (e.g., data repository, process, procedure) that perform some function at runtime, • a topological layout of these components indicating their runtime interrelationships, • a set of semantic constraints (for example, a data repository is not allowed to change the values stored in it), • a set of connectors (e.g., subroutine call, remote procedure call, data streams, sockets) that mediate communication, coordination, or cooperation among components. When choosing an architecture for a system, usually several architectural styles are possible, which means that all of them could be used to implement the functional requirements. In the following, we propose concrete architectural patterns for each basic problem frame in order to provide a concrete starting point for the further development of the machine. These architectural patterns are based on a Layered architecture. The components in this layered architecture are either Communicating Processes (active components) or used with a Call-and-Return mechanism (passive components). That design decision is taken in a later step of the development. We also show how the Repository and the Pipe-and-Filter architectural styles can be mapped to the layered architecture (see Figures 8 and 10). We use UML 2.0 composite structure diagrams (see Section 2.3) to represent architectural patterns as well as concrete architectures. 2.3 Composite Structure Diagrams Composite structure diagrams [21] are a means to describe architectures. They contain named rectangles, called parts . Theses parts are components of the software. In an object-oriented implementation components are instantiated classes. Each component may contain other (sub-) 4