The System Architect's Assistant for Design and ... - CiteSeerX

Proceedings of 4th IEEE Workshop on Future Trends of Distributed Computing Systems, Lisbon, Sept. 1993.

The System Architect’s Assistant for Design and Construction of Distributed Systems Jeff Kramer, Jeff Magee, Keng Ng and Morris Sloman Department of Computing, Imperial College, London SW7 2BZ. Abstract Distributed systems are conveniently described, constructed and managed in terms of their software structure or architecture. However few current platforms exploit the architectural view. This paper outlines current work on the provision of an architectural methodology and graphical support tool, the System Architect’s Assistant, for the design and engineering of distributed systems. The tool supports both initial informal design decomposition and subsequent rigorously checked composition when a set of specified, designed and/or implemented components1 are integrated to analyse and/or construct the desired distributed system. The effectiveness of the methodology and prototype tool will be assessed by applying it to case studies supplied by an industrial associate and by conducting controlled productivity experiments.

1. Motivation The distributed systems research community has recently reached a (not undisputed) consensus on the set of techniques and mechanisms which should be used to construct distributed systems. Among the mechanisms agreed as useful are, communication by remote procedure call, atomic group cast communication between server replicas to support availability and atomic actions to preserve data consistency in the presence of failures. This consensus is reflected in the inclusion of most of the above in commercially available distributed applications platforms such as ANSA[1] and OSF/DCE. However, none of the above mechanisms help in the design process of decomposing an overall application into a set of components nor in its subsequent construction. They are 1 In the paper, we use the neutral term component to mean a software entity which encapsulates some resources and provides a well defined interface in terms of the operations it provides to access the resources and the operations it requires to implement its functionality. We have refrained from using the term object, which captures much of this, since it has acquired a more specialised use in the OOP world.

rather the “glue” used to compose components such that they may communicate and interact. What is missing is any notion of structure. Support is missing for the design and construction of applications exhibiting a structure which is any more complex than a simple client-server arrangement. Practical experience in software engineering has taught us that complex systems can be built and managed provided we adhere to some sound principles. Software modularity is essential, and permits the use of composition to form a system. In particular, distributed systems are conveniently described, constructed and managed in terms of their software structure. Descriptions of the constituent software components and their interconnection patterns provide a clear and concise level at which to specify and design systems, and can be used directly by construction tools to generate the system itself. In many cases - particularly embedded applications - it is the structure of the application itself which is used to dictate the structure of the resultant system. Since it seems that many 'new' systems are created by modifying or evolving previous versions rather than by design and construction ab initio, there is a need to recognise system evolution as a major portion of the development process. Evolution of the system can be achieved by making extensions or changes to the system configuration by the addition or replacement of components. The premise of our approach is thus that a separate, explicit structural (configuration) description is essential for all phases in the software development process for distributed systems, from system specification as a configuration of component specifications to evolution as changes to a system configuration. In contrast to the "specification driven" approach, our approach to distributed systems design is "constructive". The "specification driven" approach attempts to formalise the decomposition process based only on the system specification [2]. We believe that this process of component identification remains informal as it requires design information not usually included in the system specification. Decomposition is best dealt with through

design heuristics. Emphasis should rather be placed on the validation process using analysis through composition of component behaviours analogous to "construction" of the system from components [18,19]. This constructive approach is the means by which we gain confidence that our design is satisfactory. For a number of years, the Conic environment [23] has supported the use of an explicit configuration language (“configuration programming”) for distributed system construction. A number of other research projects make use of a separate configuration language for distributed systems construction (Durra [3], Lady [27], Polylith [29]) but few are as widely distributed and used, and as simple yet versatile as the Conic configuration language which includes facilities for hierarchic definition of composite components, for parametrisation of components, for replication of both component instances and interface ports, for conditional configurations with evaluation of guards at component instantiation, and even for recursive definition of components [8]. This work has been extended to include dynamic and generic structures in Darwin [21,24,25]. Standard design methods such as JSD [14] and Structured Analysis (Data Flow Diagrams) [7] produce designs as system configurations but fail to carry these notions through to distributable implementations with explicit configurations. HOOD [13] and JSD+ [15] address some of these issues but are tailored to the Ada language. Environments such as STATEMATE [12] recognise the power of the structural view for system specification and modelling, but tend to be weak in their

Design Analysis

Construction

Configuration Monitoring Architect's Assistant

2. Methodology and Tool Support

In order to focus and evaluate the work on the methodology and integration mechanisms, we have developed a prototype version of the System Architect’s Assistant (SAA). Its functionality can be split into four complementary and interacting areas. These are support for design, analysis, construction and evolution. Both the off-line activities (such as design and Component analysis) and the on-line activities Requirements Library (such as monitoring and change) are unified in the SAA by the use of a Interface common structural description of the Design system architecture developed during Specification Architect's Assistant design which the tool can view and Implementation manipulate graphically. Although Primitive Composite Components Components Dependencies shown separately in Figure 1, it reflects different uses of the same tool.

Component Language compilers C/C++

Execution

support for component-based distributed system construction. STILE (STructured Interconnection Language and Environment) [32] advocates and provides good support for graphical component-based design and construction, but does not provide particular support for distribution. In addition, as is done in environments such as the Designer’s Notepad [11], it is essential to provide flexible means for design expression, documentation and exploration. This paper outlines current work on the provision of such an architectural methodology supported by a graphical environment, the System Architect’s Assistant, for the design and engineering of distributed systems. The constructive design approach [19], the Darwin configuration language [21,24,25] and some initial work on graphical configuration programming [17,28] form the basis of this research work. The environment owes its name to the assistant approach adopted in the Programmer’s Apprentice [30] except that we focus on generic structures as architectural clichés and use the graphical and textual configuration language as our underlying formalism.

Configuration Translator

Build Control Version Control

Darwin

Distributed Application Distributed Execution Environment Distributed Systems Platforms

Figure 1 - Integration using the System Architects’s Assistant

Design Our approach is not restricted to a specific design method or technique such as SASD or OOD in the sense of enforcing those specific rules and method steps. Rather it supports a general approach to design which we have termed constructive. It consists of the following design activities (figure 2):

•Structure and Component Identification: Initial design aims to identify the main processing components and produce a structural description indicating the main data flows. This step provides an initial identification of component types. Furthermore, hierarchical decomposition of any of the component types into a configuration of subcomponents may be performed or left for later refinement. •Interface Specification: This aims at introducing control (synchronisation) between components and refining the configuration, component interface specifications (intercommunication) and component descriptions accordingly. The formulation of precise interface specifications is intended to permit the detailed design, implementation and testing of a component type to proceed independently from the rest of the system design. The tool automatically infers the interface types of composed components (see below) and checks the compatibility of component interconnections. Further, it allows the definition of generic components which define a structure which is parameterised with specific component types. •Component Elaboration consists of elaboration of the component types, e i t h e r by hierarchical decomposition of composite component types into a configuration of subcomponents, or by functional description of behaviour (formal or informal specifications). Primitive components must also be provided with implementation (code) descriptions. As before, the identification of common component types is emphasised. Software Structure Real World Application

System

Component Types

Interface specification

+

Elaboration component composite structure program begin ....... end

Figure 2 -

CDA, the Constructive Design Approach

Although this description emphasises the top-down approach, bottom-up (constructive) composition and component reuse can be used at any stage. We plan to further refine the overall design approach, including investigation of aspects such as the use of heuristics to avoid fruitless decomposition paths. Systematic approaches such as Critter [10], which aid decomposition by goal satisfaction and the assignment of responsibility to agents, appear appropriate and promising. We also intend to investigate of the use of inheritance in the definition of component types and its relationship to our use of hierarchical composition of component instances. A third area of investigation concerns the effects of architectural and functional design changes. The former is currently easy to accommodate, the latter less so. Construction The design activity culminates in a structural description of the desired system and a set of primitive component types described in a programming language. From these, the executing distributed system can be constructed by invoking the appropriate compilation, linking and loading tools. Central to the construction activity is the structural description. It can be annotated with non-functional information such as location, availability and resource requirements during the design process to direct the construction phase. The SAA has the capability to manipulate this description in both graphical and textual forms and is intended to transform one to the other (currently only graphical to textual). Past experience has shown that the description of large regular structures are tedious to define graphically and is thus best done in the more concise textual form. The SAA will use an enhanced version of the configuration language Darwin for textual structure description. Darwin descriptions compile to C++ procedures which elaborate the required structures at system generation/instantiation time. Darwin permits the definition of both static and dynamically changing structures. The enhanced version of Darwin is neutral with respect to the form of inter-component communication or interface specification used although it will allow these interfaces to be checked for compatibility. We plan to investigate use of the Assistant to design and construct distributed systems using ANSA, Arjuna [31] and our in-house platform as dictated by heterogeneity, reliability, and performance requirements, respectively. Application to these three distributed systems platforms for different case studies will assist in validating the generality of the approach and its embodiment in the SAA. Analysis In order to exploit the central architectural view, we

adopt compositional techniques analogous to system construction except that the entities being manipulated are not software components but associated attributes giving specifications or models of their functional or timing behaviour. The objective is to ensure that the structure of the system and of its specification is the same. System architects should be free to select those specification techniques that are appropriate to the application. Wanda [33] is a recent specification language for the description of distributed time-critical systems. It utilises the constructive design method of decompositional design and hierarchical system construction. The formal framework of Wanda is adopted from the Timed CSP model embedded into a typed logic language. It provides two well-formedness rules, one for composition to ensure that the environment of a sub-component behaves as specified, and one for decomposition to ensure that the subcomponents of a component co-operate in a way that guarantees the assertions of the composite component. Another example of this approach is the work of Castro [4] which uses a form of Petri Nets for the description of individual component behaviour and Causal Temporal Logic for reasoning about composed systems. Zave and Jackson [34] also support the general approach and have recently proposed the use of a simple logic (one-sorted Predicate Logic) to enable the use of "conjunction as composition". This is very promising and seems ideally suited to our framework. Milner’s work on the π-calculus [26] is also promising, especially as it has been found to be useful in defining the semantics of Darwin [9]. More recently, the work of Cheung [5,6] has provided a tractable technique for flow analysis of distributed programs and a technique for compositional analysis of components specified as labelled transition systems. The SAA is intended to act as a front end for specifying the structure and those component specification attributes selected by the designer. It should then be possible to invoke the relevant compositional analysis or verification tools associated with any or all of the provided attributes.

in the REX project [21]. The tool provided a basis for the graphical user interface since it implemented a set of effective and sophisticated layout and tidyup algorithms. However, since it was targeted at Conic and subsequently REX, it lacked the generality required. The current protoype implementation of the Assistant runs on the Apple Macintosh and is to be ported to X Windows/Motif. It focuses on the design phase of program development. It has been specially tuned to support the Constructive Design Approach (CDA), with support for both top-down and bottom-up development. Knowledge of the CDA method workplan and representations are built into the tool, thus enabling various syntactic and consistency checks and transformations to be performed automatically. The main objective of the tool is to provide a flexible and unintrusive environment in which software design and associated information can be captured, viewed and modified easily and quickly. This is achieved through the provision of intelligent, automated assistance throughout the design process, including facilities for the refinement and modification of the program design as well as various layout facilities to simplify the task of diagram editing. Indeed, automation is one of the aspects we have tried to exploit in the implementation of the tool. To improve productivity and ease of use, any required information that can be inferred from existing data is generated automatically. This also has the effect of reducing human errors and ensuring the consistency of information. The Assistant currently provides support for sketching and recording distributed designs (both graphical and textual), for navigating and traversing through complex hierarchies, and initial support for composing component descriptions (including code, formal and informal specifications), maintaining libraries of components, and generating reports. Code, specifications, informal comments and user-defined attributes can be attached to any object. These facilities are described in more detail below.

Evolution Evolution is the incremental construction of a system. In previous work, we have addressed the problems of dynamically changing a distributed system on-line [16, 20]. It is intended that the Assistant will have the ability to monitor and modify the systems it constructs. Detailed discussion of this is beyond the scope of this paper.

Multiple Integrated Vi e w s The prototype Assistant has a highly visual and interactive user interface, and provides multiple graphical as well as textual views onto the program design. The use of the tool revolves mainly around the Configuration Window (figure 3, top left) which acts as a sketchpad in which the basic software architecure is mapped out and refined. The configuration structure is displayed one level at a time, in terms of components and their interconnections. Controls are provided for traversing the hierarchy within this view. Changes made in this view are automatically reflected in all other views. The Tree Window (figure 3, bottom) displays the entire

3. Current Status of the System Architect’s Assistant A previous protoype, RexDesigner, was based on a tool which was originally developed for Conic [23] and revised

be achieved with the minimum of effort on the part of the user. Facilities provided include the automatic clean-up of diagrams by minimising line crossovers, automatic node placement, grid lines for node alignments and node templates for grouping and aligning nodes [17]. Many of these are performed automatically as a diagram is being edited, hence ensuring that the diagram is always in a tidy state. Together, they help remove much of the drudgery (such as re-routing lines between nodes) from diagram manipulation, thereby allowing the user to concentrate more on the creative aspects of program design and less on mundane and tedious clerical and mechanical tasks. Figure 3 -

System Architect’s Assistant

system decomposition within a single hierarchical tree structure, and also serves as a navigational aid - selecting the appropriate component in this view will bring up the structure of that component in the Configuration Window. This is particularly useful in the case of large systems as it enables the user to move from one part of the hierarchy to another with just a single mouse-click. By highlighting the components currently displayed in the Configuration Window, the Tree view also doubles up as a ‘Where am I’ indicator. Both the Configuration and Tree Windows can be split into resizable panes to display, amongst other information, the corresponding configuration code of the component being displayed. The textual code (figure 3, top right) is automatically updated as changes are made to the graphical design. The Assistant supports the display of multiple Configuration Windows, thus allowing different components within the hierarchy to be viewed and modified in any order. Editing and Layout Support Due to the non-linear nature of graphical representations, diagram editing is inherently more complex and tedious than editing text. In the Assistant, comprehensive support for diagram layout and editing is thus provided to enable the desired layout of a diagram to

User-definable Attributes The Assistant allows pieces of information, called attributes, to be attached to individual objects of the program design. Typical attribute types may be a formal specification (see Analysis section above), design history, general comments, resource requirements, functional descriptions and so on. Depending on the user’s requirements, new attribute types can be defined for storing new kinds of information, and may be applied to all types of objects or made specific to just particular types of objects (figure 4). This extra flexibility enables attribute types such as ‘comments’ to be applied to all types of objects but limits others such as ‘data dictionary’ to just data flows. It is vitally important that location and retrieval of an object’s attribute be intuitive and straight forward, regardless of the size of the system being built or the number of defined attribute types. For this purpose, the graphical views of the Configuration or Tree window provide the ideal interface. By selecting the individual objects from either of these views, a pop-up menu listing all the attribute types relevant to that object is displayed. Choosing an attribute from this menu will bring up the object’s corresponding attribute in a resizable pane in the same window. The underlying attribute storage mechanism is thus hidden from the user.

library. Selecting an item in this list brings up the picture of the component and its corresponding textual description. This enables the user to browse through a library rapidly when searching for a component for reuse. Once a component has been located, it can be incorporated into a design diagram using the standard ‘cut & paste’ metaphor. In a similar fashion, components in a diagram can be copied and added to a library for later reuse. There is no restriction on the number of libraries that can be created or used. This facilitates the organisation of the reusable components in a manner that best suits the user’s needs. For example, separate libraries can be created for components based on their function, creator or project. Figure 4 - Creating, removing or renaming attributes Component Reuse The context-independent nature of components makes them ideally suited for reuse. In practice, however, reuse has been hampered by the lack of proper tool support for the archiving and retrieval of potentially reusable components. In the Assistant, we support the notion of a component library - a repository in which components can be stored for reuse at a later date. For each component, the library stores its interface, its internal structure, its picture (to aid later identification and retrieval) as well as an associated textual description. This editable description allows the functionality of a component, for instance, to be recorded.

Figure 5 - Browser for a Component Library The location and retrieval of reusable components is supported by a library browser (figure 5) which provides a simple interface for accessing stored components. Within the browser window, an alphabetically-ordered list of names indicate all component types that are within a

4. Conclusions and Evaluation The specification of system requirements can be construed as a set of tests which the design and subsequent implementation are expected to satisfy. A design is a model of the system on which these tests can be conducted, where test satisfaction strengthens confidence in the adequacy of the design, while test failure indicates particular inadequacies. It is thus essential that designs are testable. Analysis is utilised as part of the testing process to provide additional evidence as to the adequacy of the design. The level of the design model(s) is selected so as to support such testing and analysis yet also provide the basis for (efficient) implementation. Our approach is to adopt an architectural design methodology in which distributed systems are described, modelled and constructed in terms of their software structure. Descriptions of the constituent software components and their interconnection patterns provide a clear and concise level at which to specify, design and analyse systems, and can be used directly by construction tools to generate the system itself. The Architect’s Assistant is intended to provide an environment for supporting this methodology. Design initially concentrates on the description of an instance of the architecture. This can be generalised to provide generic architectural types with the inclusion of component parameters, conditional instantiation and binding, iteration and recursion, and generic structures with component type parameters. The designer is obliged to ensure that the particular required instance can be generated from the general architectural description. This process of moving between the specific (usually described graphically) and the general (usually described textually) requires further work in both the methodology and in the support offered by the Assistant. We plan to assess the effectiveness of the methodology, its integration approach and the Assistant in two ways. Firstly, the approach will be applied to case

studies provided by an industrial associate. These case studies will validate its effectiveness for realistic distributed system applications. Secondly, we would like to assess the productivity gains in using the approach. Our final (fourth) year M.Eng Software Engineering students represent the level of engineer the Assistant is aimed at. They spend six months in industry in their third year and are exposed to a wide range of software tools and environments during their course. We plan to split them into three groups: one will act as the control and address distributed system implementation using conventional approaches; another will use the methodology but without using the Assistant; while the third will have use of the Assistant. Although, we can only attempt to construct relatively simple distributed systems in these experiments, we hope to get useful data on the effectiveness of the approach and the Assistant. Acknowledgements: We gratefully acknowledge the advice of our colleagues in the Distributed Software Engineering Research Section, and the financial support provided by the DTI under grant ref: IED4/410/36/002.

References [1] “ANSAware 3.0 Implementation Manual”, Doc. RM.097.00, APM Ltd, Cambridge, Jan. 1991. [2] R.Balzer, "A 15 Year Perspective on Automatic Programming", IEEE Transactions o n Software Engineering, SE-11 (11), Nov. 1985 [3] M.R.Barbacci, et al, "Durra: a Structure Language for Developing Distributed Applications", IEE Software Engineering Journal, Special Issue on Configurable Distributed Systems, 8 (2), March 1993, pp. 83-94. [4] J . C a s t r o , J.Kramer, “Temporal-Causal System Specification”, IEEE Int. Conf. on Computer Systems and Software Engineering (CompEuro ‘90), Israel, May 1990. [5] S.C.Cheung, J.Kramer, “Tractable Flow Analysis for Anomaly Detection in Distributed Programs”, 4th European Software Engineering Conf., ESEC , Sept. 1993. [6] S.C.Cheung, J.Kramer, “Enhancing Compositional Analysis with Interfaces”, Technical Report DoC 93/13, Dept. of Computing, Imperial College, April 1993. [7] T. De Marco, "Structured Analysis and Structured Specifications", Prentice Hall 1979. [8] N.Dulay, “A Configuration Language for Distributed Programming”, Ph.D. Thesis, Imperial College, 1990. [9] S.Eisenbach, R.Paterson, “π-Calculus Semantics for the Concurrent Configuration Language Darwin”, HICSS-26, Hawaii, January 1993. [10] S.Fickas and R.Helm "Knowledge Representation and Reasoning in the Design of Composite Systems", IEEE Transactions on Software Engineering, SE-18 (6), June 1992, pp. 470-482. [11] N.Haddley and I.Sommerville, “Integrated support for system design”, IEE Software Engineering Journal, 5 (6), Nov. 1990. [12] D.Harel, et al, "STATEMATE: A Working Environment for the Development of Complex Reactive Systems", Proc. 10th. Int. Conf. on Software Eng., Singapore April

1988, pp. 396-406. [13] HOOD Reference Manual, Issue 3.0, European Space Agency, Sept. 1989.. [14] M.A.Jackson, "System Development", Prentice Hall 1983. [15] JSD+ Reference Manual, Sema Scientific, Sema Group, June 1991. [16] J.Kramer, J.Magee, "Dynamic Configuration for Distributed Systems", IEEE Transactions on Software Engineering, SE-11 (4), April 1985, pp. 424-436. [17] J.Kramer, J.Magee, K.Ng, "Graphical Configuration Programming", Computer, 22 (10), October 1989, 53-65. [18] J.Kramer. “Configuration Programming - A Framework for the Development of Distributable Systems”, Proc. of IEEE CompEuro ’90, Israel, May 90, pp 374-384. [19] J.Kramer, J.Magee, A.Finkelstein, “A Constructive Approach to the Design of Distributed Systems”, Proc of 10th Int. Conf. on Distributed Computing Systems, Paris, 1990, 580 - 587. [20] J.Kramer, J.Magee, "The Evolving Philosophers Problem: Dynamic Change Management", IEEE Transactions on Software Engineering, SE-16 (11), Nov. 1990, pp. 1293-1306. [21] J.Kramer, et. al. “An Introduction to Distributed Programming in Rex”, Esprit Conference 91, Brussels, Nov. 1991. [22] J.Kramer, J.Magee, M.Sloman, N.Dulay, "Configuring Object-Based Distributed Programs in REX", IEE Software Engineering Journal, 7 (2), March 1992, pp139-149. [23] J.Magee, J.Kramer, and M.Sloman, "Constructing Distributed Systems in Conic" IEEE Transactions o n Software Engineering, SE-15 (6), June 1989. [24] J.Magee, N.Dulay and J.Kramer. “Structuring Parallel and Distributed Programs”, IEE Software Engineering Journal, Special Issue on Configurable Distributed Systems, 8 (2), March 1993, pp. 73-82. [25] J.Magee, J.Kramer and N.Dulay “Darwin/MP: An Environment for Parallel and Distributed Programing”, Proc. of 26th HICSS, Vol. II (Software Technology), Jan. 1993, pp. 337-346. [26] R.Milner, J.Parrow, D.Walker “A Calculus of Mobile Processesl”, LFCS -89-85 and 86, Edinburgh U., 1989. [27] J.Nehmer, et al, “Key Concepts of the INCAS Multicomputer Project”, IEEE Transactions on Software Engineering, SE-13 (8), August 1987. [28] K.Ng, “Visual Support for distributed Programming”, PhD Thesis, Department of Computing, Imperial College, August 1992. [29] J.Purtilo, “The Polylith Software Toolbus”, to appear, ACM TOPLAS. [30] C.Rich, R.C.Waters, “The Programmer’s Apprentice: A Research Overview”, Computer, 21 (11), Nov. 1988, pp. 11-25. [31] S.Shrivastava, G.Dixon, G.Parrington, “An Overview of the Arjuna Distributed Programming System”, IEEE Software 8 (1), January 1991. [32] M. Stovsky, B.Weide, “STILE: a graphical design and development environment”, COMPCON Spring ‘87, IEEE, San Francisco Feb. 1987. [33] J. Trescher, "Compositional Specification of Parallel Time-Critical Systems", Proc. of IEEE Int. Conf. o n Computer Languages, San Francisco, 1992. [34] P.Zave, M. Jackson, "Conjunction as Composition", t o appear, ACM TOSEM, 1993.