: A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS

Transcription

1 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN ABSTRACT. Architecting, designing, configuring and deploying a sophisticated distributed system is a challenging process that involves many complicated design and specification tasks. A unifying architectural specification framework can be a valuable tool for organizing the designs of distributed systems and their constituent components, and for documenting configuration and deployment constraints and requirements. We present an integrated multi-level specification framework, called, that supports the definition of architectural properties of distributed object and component systems. Each of the five levels of the framework addresses distributed component system definition at a distinct level of abstraction that incorporates both the software and hardware components of distributed systems. The specification at each level is done in terms of a definition language that admits both textual and graphical representation. We define formally using the Z specification language. The five levels deal with the specifications of component interfaces, implementation, integration, instantiation and installation. To illustrate the semantics at each level of specification we use the UML implementation diagrams. Keywords: Distributed software engineering, formal specification language, software architecture, configuration management. 1. INTRODUCTION Extant network technology allows for creation of large distributed computing environments that incorporate numerous types of user interface devices, general purpose computers, specialized servers, network equipment and other electronic devices. Such inherently heterogeneous distributed computing environments, even when their size is modest, present numerous challenges to THE WORK IN THIS PAPER HAS BEEN PARTIALLY SUPPORTED BY RE- SEARCH GRANT F FROM AFOSR. 1

2 2 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN those who need to architect, design, develop and deploy distributed applications. One of the challenges faced by architects and designers is that, despite the emergence of object-oriented design tools and interface specification languages, there are no comprehensive methodologies and tools that deal specifically, and in depth, with distributed object-oriented application designs. In designing a sophisticated distributed application, the best practice today involves a patchwork of specifications including graphical object-oriented modeling tools, manual documentation of object interaction, automated class dependency analysis, ad hoc specification of type vs. class subtleties, formal specification of interfaces, descriptions of distributed algorithms and protocols at varying degrees of formality, and specifications of distributed system configuration and deployment. Without a comprehensive design framework, it is very difficult to ensure that all necessary types of specifications are produced within the design effort. It is usually the case that when a distributed system is first deployed, numerous forgotten or underspecified aspects of the system begin to surface. Even when one is able to amass all necessary specifications, it is extremely difficult to deal with the dissimilar kinds of specifications and specification formats and media. During the development of a system, it becomes difficult to maintain traceability between the specifications and the resulting implementation. This problem is further aggravated when an existing distributed system needs to be refined, extended or redeployed. Our broad goal is to provide a comprehensive specification framework for capturing and organizing complete architectural designs of object-oriented and component-oriented distributed applications. Assuming an object-oriented approach to distributed system architecture is natural because it allows the designers to represent physical and logical resources and components in a distributed environment as objects. Distributed middleware is also taking an increasingly object-oriented approach and is providing better support for distributed application developers. Significant steps in the direction of complete system specification are being made, for example, by UML [6]. UML is a standard object-oriented design specification language that enjoys wide support from many software companies. UML includes graphical formalisms that help developers visualize the structure of the system under construction, and this is a valuable feature for distributed system designers. Our goals for defining a complete specification framework include the goal of taking advantage of existing specification frameworks, such as UML.

3 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 3 Contributions. We present an integrated multi-level specification framework, called, that supports the definition of architectural properties of distributed object and component systems. includes five specification levels for defining, at different levels of abstraction, the distributed system and its hardware and software components in an integrated and uniform way. The framework can be used to organize the design and documentation processes for new systems, as well as to document fully developed, and existing or deployed distributed systems. This documentation enhances the system implementation traceability and provides a sound basis for system configuration management. Since the framework deals with the architectural specification of a distributed system, we allow for the detailed designs, e.g., specific algorithms and protocols, to be incorporated as necessary within the context of a particular project using the notation and the level of formality chosen by the designers. The five levels of deal with the Interface, Implementation, Integration, Instantiation, and Installation aspects of the distributed system specification: The Interface level deals with different types of components in the system and nodes in the target network, and with type inheritance. The Implementation level deals with the classes that realize the component types and node types. The existence of implementation inheritance is also specified in this level. The Integration level establishes the requirements for software/hardware class integration. The Instantiation level deals with instances of the component and node classes when the instances are statically defined. The Installation level defines or constraints the deployment of instance components over the instance nodes of the network. We explicitly address the distinction between types and classes, and enable class inheritance to modify the type inheritance structures. This is necessary to allow multiple coexisting implementation of the same functionality, and also to deal methodically with heterogeneity in the distributed setting. The specification at each of the five levels of is done in terms of a definition language. We present a formal specification of the five definition lnguages of using the Z specification language [17]. Disitributed system specifications in admit both the traditional textual representations and the graphical representations, for example, in terms of the UML implementation diagrams [6]. The benefits of the dual representation is that the system definition

4 4 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN can be done in precise detail given the flexibility and power of the textual languages, while providing a user-friendly way of visualizing the designs using the graphical languages. The formal specification of allows us to build an automated design tool for specifying distributed systems using its integrated textual/visual representation. The design of ensures that during any step of the specification process we may switch between the textual and graphical modes of representation. We plan to pursue this work in the future. The features of UML that can be used for modeling distributed systems component and deployment diagrams have not been fully used in practice yet [9]. Thus, our integrated framework contributes motivation for further development of these capabilities in UML. Furthermore, any tool that supports existing UML diagrams does not need to reinvent notation for the required features, additionally taking advantage of UML makes such tool appealing to a broad user community. Related Work. Early inspiration for our work can be found in the ideas behind OSF s I4DL family of languages [2, 8]. There have been similar efforts defining dual textual/graphical specifications for distributed systems such as [7, 13] that deal with support tools and their use in documentation and configuration management. Our approach distinguishes between types and classes, and allows for class inheritance to modify the type inheritance structures. We also designed our graphical representation based on UML implementation diagrams thus avoiding inventing another notation. Many other formalisms have been used to describe distributed systems. In [16] and [15], Z is also used to specify software architectures; in [1], Wright is presented to model dynamic aspects of software architecture. In [10], inputoutput automata are used to specify distributed systems as a set of interacting components. In general all these formalisms deal with detailed specification having the goal of the analysis of system properties. The focus of our approach is on the system structure and integration of its diverse aspects, such as the software, the hardware and their relationships and dependencies, into a comprehensive specification. We see substantial potential in future integration of our architectural specification approach with detailed algortihm and protocol specification approaches, and their associated methodologies. The Paper. In Section 2 we define the background concepts and describe the five levels of. In Section 3 we formally define in an incremental manner using the Z specification language; we also ilustrate the features that

5 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 5 may be included in the specification using UML s implementation diagrams component and deployment diagrams. Conclusions and future work are in Section DEFINITIONS, CONCEPTS AND OVERVIEW is a specification framework for defining distributed systems in terms of five hierarchical levels. The five levels of are: interface, implementation, integration, instantiation and installation, describing the distributed systems software, hardware and dependencies between software and hardware, in an integrated manner, and at different levels of abstraction and detail Background Concepts. Among the key concepts in this paper are: types, classes, instances, and inheritance. In particular, we define the notion of inheritance in different contexts. We now define these terms and explain their usage. Interface. The interface of a component defines its interaction with its environment. This definition comprises the signature that specifies the interaction at the syntactical level, and of all calls made to operations at other components. Type. A type is an abstract entity defined by its interface and its semantics. Currently, we are only using the interface to formally characterize a type; adding the corresponding semantics will be considered in our future work. TYPES T1 I2 C1 I2 CLASSES Type inheritance (a) T2 I2 I4 Realization Implementation inheritance C2.1 I2 I4 (b) C2.2 I2 I4 FIGURE 1. Interfaces, types, classes and inheritance. Type inheritance. A subtype inherits the interface and semantics defined for its supertype and it may specialize the supertype. We allow multiple type inheritance whenever it generates no conflict (see Figure 1, (a)). Class. A class is the implementation of a type. Multiple implementations may be possible for a particular type. This is due to different programming languages, different algorithms and different target platforms. Any class must implement the respective type interface and type semantics. Classes are represented with filled boxes in Figure 1, (b).

6 6 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN Realization. We define realization to be the relationship between a type and a class that implements it (Figure 1, (a) and (b)). Implementation inheritance. Implementations provided for a class may be inherited by the classes implementing the subtypes. Implementation inheritance must be specified in addition to type inheritance when addressing portability and optimization issues. This is often done adhoc in real practice. We make the distinction between type and class inheritance specifications explicit in (Figure 1, (b)). Instance. An instance is an element of a class. The instantiation can be static (done at system initialization) or dynamic (occuring at runtime). We consider instances software components, instance computer nodes and instance connectors. We assume that all inheritance-induced references are resolved prior to the instantiation The Five Levels of Specification. Our multi-level specification framework takes a divide-and-conquer approach in specifying complex distributed systems. This is done by addressing the distributed system architectural specification at five different levels of abstraction. The specification at five levels induces a methodology, in which each of the five levels are specified one after the other by adding detail that is appropriate and necessary for each level of abstraction. This process can be repeated in a spiral fashion. has five levels: Interface, Implementation, Integration, Instantiation, and Installation, each dealing with a different aspects of the distributed system specification. Interface. Includes the definition of the different types of components in the application and the nodes and connectors in the network, as well as their dependencies and connections. The Interface level includes type inheritance in a similar way as Java interfaces and CORBA IDL [5, 11, 14]. Implementation. Implementation refers to the classes that realize the component types and node types defined in the Interface level. The existence of implementation inheritance for component classes is also specified in this level. Node classes are the different computer classes that form (part of) the target network. We express the realization relationship for the software components and also for the nodes in the network, yielding a specification with pleasing symmetry. Integration. This level establishes the requirements and constraints for mapping instances of component classes to instances of node class. We define the

7 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 7 relationship supports to represent the constraint that instances of a component class may only run on instance nodes of the indicated classes. Instantiation. The actual instances of the component and node classes are specified as part of the Instantiation level and uniquely identified. In our specification we only address the static configuration; adding dynamic configuration [12], where processes or instances are created and/or destroyed at runtime, is subject to future work (note that dynamic instances can always be modeled at fine levels of granularity when they are entirely contained within a deployable component). Only the instances of the classes identified in the Implementation level may be part of the final system. The specification has three different kinds of elements: types, classes, and instances for describing the software and the hardware. Table 1 shows the different levels of specification and the symmetry between hardware and software specification. Component Node Type Specifies interface and semantics Role played by the node Class Type implementation (multiples Platform and/or operating system possible) that implements the role Instance An executable instance of a class Instance computer TABLE 1. Levels of Specification for Components and Nodes. Installation. This level defines where each instance component is to be deployed over the instance nodes identified in the Instantiation level. Installation requirements such as fixed locations for some components, or the need of running two components in the same or different nodes, are also included. In Figure 2 we summarize the specifications in each level and their relationships. Each horizontal level represents a specification level and the meaning of the arrows is the following: 1. Implementation classes refine types specified in the Interface level. 2. Classes defined in Implementation are integrated. 3. Classes defined in Implementation are instantiated. 4. Each instance component must have at least one instance node where the component may run. 5. The relations together and separated can be specified for instance components of the application. 6. The location of some components may be fixed at certain instance nodes in a way that is consistent with Integration level specification.

8 8 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN 7. Installation satisfies all separated, together and fix constraints, and it includes all instance components and nodes. SOFTWARE HARDWARE COMPONENT NODE TYPES TYPES 1 1 COMPONENT IMPLEMENTATION CLASSES 2 2 NODE IMPLEMENTATION CLASSES INTERFACE IMPLEMENTATION 3 IMPLEMENTATION 3 INTEGRATION COMPONENT INSTANTIATION 4 4 APPLICATION INSTANTIATION 5 6 NODE INSTANTIATION 4 INTEGRATION INSTANTIATION INSTALLATION REQUIREMENTS (together, separated) 7 INSTALLATION REQUIREMENTS (fixed components) INSTALLATION 7 7 FINAL INSTALLATION FIGURE 2. Definition Languages in. 3. FORMAL DEFINITION OF We formalize using the Z specification language [17]. A distributed system may have many structural features and complex constraints. We present the five level definitions in order, with each specification level introducing details incrementally. A level may define new elements and additional integrity constraints with respect to the previous levels. In this way we get a specification that is manageable at each level, and that captures all the decisions made in the process from designing to deploying a distributed system Interface. The Interface level of specification is the highest level and the only independent one. Here we specify the types of software components and their dependencies, as well as the hardware node and connector types. Software component types specify their unique type from among the set of all assumed component types COMP TYPE. Component types are also formed by their interfaces and calls, the union of those locally defined and those inherited from the supertypes [A,B]. For a given type, the interfaces are the services available for other components to call, and the calls are those interfaces in

9 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 9 other Comp Types that it calls. More than one Comp Type may implement the same interface, so calls are identified with a pair (Comp Type, Interface) to avoid ambiguity. We state as a constraint that every call to an interface in another component type is such that the interface is a part of the interfaces of that component type [C]. COMP TYPE Comp Type type COMP TYPE supertypes Comp Type local int Interface interfaces Interface local calls Comp Type Interface calls Comp Type Interface interfaces supertypes interfaces local int [A] calls supertypes calls local calls [B] ct i calls i ct interfaces [C] CT1 I1 interface CT3 I3 <<generalization>> CT2 I2 CT4 I3 I4 interfaces FIGURE 3. Component types in a distributed system. Standard UML component diagrams provide all the elements necessary to model the software Interface level, as shown in Figure 3: interfaces are shown with the lollypop symbol, and calls are stereotyped dependencies between component types and interfaces, type inheritance is represented with the generalization arrow. The Interface level of the software specification is a set of uniquely identified component types [D] such that all calls [E] and type inheritance [F] are satisfied within the system; we call it I S.

10 10 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN I S comp types Comp Type c c comp types c type c type c c [D] ct i comp types calls ct comp types [E] ct comp types ct supertypes comp types [F] For the hardware Interface specification, we include the types of nodes and connectors that form part of the system. NODE TYPE Node Type type NODE TYPE CONN TYPE Conn Type type CONN TYPE Node types classify nodes according to their assumed features and the roles they play in the system (e.g., a database server, ATM machine) and connector types identify the type of communication service they provide at an appropriate level of abstraction (e.g., point-to-point serial line, transport-level connection). connt1 NT1 connt2 NT2 connt3 connt4 NT3 FIGURE 4. Node types in a distributed system. UML s deployment diagrams show the physical architecture of the hardware and software in the system; they have a type and an instance version [4, 6]. Deployment diagrams, including only the node types are used for specifying the hardware interface, as shown in Figure 4. Node types may be connected using different connector types. The lines representing connectors in the figure represent connector types that may connect the specified node types;

11 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 11 if there are multiple connector types, then each connector type must be represented between the same pair of node types. Connector types between a node type and itself correspond to connections between nodes of the same type. The Interface level of the hardware I H can be specified as a set of node types, a set of connector types, and a relation connects that relates connector types and node types. I H node types Node Type conn types Conn Type connects Conn Type Node Type dom connects conn types [G] ran connects node types [H] nt node types ct nt set connects nt nt set [I] Only node types and connector types identified as part of the system can participate in the connects relation [G,H], and all node types must be connected with at least one type of connector [I]. Then, the whole Interface level is the conjunction of the specifications of the software and the hardware; we call it I. Schema conjunction is a standard Z operation and is such that the resulting schema includes the union of all the state variables in each schema and the conjunction of all their constraints. I I S I H 3.2. Implementation. In the Implementation level we specify the realizations, that is, the different classes implementing both, the hardware node types and the software component types. There may be different classes implementing the same type, but classes can only realize types defined in the Interface level. C CLASS Comp Class Comp Type class C CLASS superclasses Comp Class cl call Comp Class Interface cc superclasses cc Comp Type supertypes [A] cc i cl call ct i calls cc Comp Type ct [B]

12 12 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN All interfaces identified for the component type are preserved in the implementation classes just by including the Comp Type. All implementation inheritance relations identified in superclasses are refinements of type inheritance relations in supertypes [A]. A call of the component type is refined to calls to interfaces on one, some or all the classes implementing the type realizing the target interface, but all calls in cl call realize calls in calls [B]. CT1 I1 <<realizes>> IC1 I1 <<realizes>> IC3 I3 CT3 I3 implementation inheritance type inheritance CT4 I3 I4 <<realizes>> IC4.1 I3 I4 IC4.2 I3 I4 <<realizes>> FIGURE 5. Component implementation: realization. Figure 5 shows how some of the component types in Figure 3 are realized into implementation classes. In the UML, a refinement relationship is indicated by a dependency arrow from the more specific element to the more general element. The dependency is stereotyped with the keyword realizes. We can express I S as follows: I S I S c classes Comp Class c classes type comp types [C] cc c classes cc superclasses c classes [D] cc i c classes cl call cc c classes [E] The classes included in I S can only be the realizations of the types specified as part of I S [C]. All superclasses must also be part of the system [D]. All calls must be to interfaces implemented by classes in the system [E]. We also specify the Implementation level for nodes and connectors. N CLASS

13 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 13 Node Class Node Type class N CLASS C CLASS Conn Class Conn Type class C CLASS The specification of the Implementation level for the hardware includes the refinement of the nodes, connectors and connections: I H I H node classes Node Class conn classes Conn Class connects cl Conn Class Node Class node classes Node Type node types [F] conn classes Conn Type conn types [G] cc nc set connects cl ct nt set connects cc Conn Type ct nc set Node Type nt set [H] All node classes and connector classes must be refinements of some node type and connector type included in I H [F,G]. All connections between node classes, those identified in connects cl, are refinements of the connections identified in connects [H]. We use a UML deployment diagram in its type version in Figure 6 to show the refinement of the node types into node classes. Connector and node classes refine connector and node types in a non trivial way, they document a specific design decision and this information cannot be automatically derived from the Interface level specification. We can then put things together and specify the complete Implementation level I as the conjunction of I S and I H. I I S I H 3.3. Integration. For the Integration we put together the complete Implementation and state that some component classes can only run on certain classes of nodes.

14 14 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN connt1 connt4 NT1 connt2 NT2 connt3 <<realizes>> NT3 NC3.1 <<realizes>> <<realizes>> <<realizes>> <<realizes>> <<realizes>> connc3.1 <<realizes>> connc1 connc3.2 NC3.2 NC1 connc2 NC2 <<realizes>> connc4 NC3.3 FIGURE 6. Node implementation: refinement. I I supports Comp Class Node Class dom supports c classes [A] ran supports node classes [B] The supports relation is expressed in UML with the stereotype supports be- IC1 IC3 IC4.1 <<suports>> <<suports>> <<suports>> <<suports>> <<suports>> NC3.3 NC1 NC2 FIGURE 7. Integration constraints: supports. tween the component and the node classes as shown in Figure 7. Even though supports is not a standard stereotype, it has already been used in [6] with precisely the same meaning. The supports relation between component classes and node classes shows the need of a component class to be deployed to a certain class of node to run. It is a relation and not a function because a component may be able to run on

15 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 15 more than one class of node. Only component and node classes identified as part of the Implementation level may participate in the supports relation [A,B] Instantiation. Instance components and nodes that form part of the system must belong to the classes identified in the Implementation level. However, defining component instances that need to run on node classes not instantiated in the specified system serves no purpose; in this sense, the complete Instantiation also depends on the Integration level. Inst Comp Comp Class inst id String inst call Inst Comp ic i inst call Interface cc i cl call ic Comp Class cc [A] Instances of each component class implement all interfaces defined in the Implementation level, thus every interface of the class becomes an interface of each instance. Every call may become zero, one or many calls to instances of the same class [A] in the Instantiation. Then, I S is a set of component instances of the classes defined in the Implementation level [B] such that all calls are satisfied within the system [C]. I S I S i comp Inst Comp i comp Comp Class c classes [B] ran i comp inst call i comp interfaces [C] Figure 8 shows the instance components that form the actual system. In UML notation, instances are identified with a lower case name separated by a colon from the type name, and everything underlined. In in our case we do not instantiate types but classes. Node and connector instances are also instances of the node and connector classes. We can have a connector class connecting nodes of only one class, but it only make sense to connect more than one instance [D]. Inst Node Node Class inst id String

16 16 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN IC1 I1 IC4.1 I3 I4 <<instantiates>> <<instantiates>> <<instantiates>> inst1:ic1 I1 inst1:ic4.1 I3 I4 <<instantiates>> inst2:ic1 I1 inst3:ic1 I1 FIGURE 8. Instance components of the actual application. Inst Conn Conn Class inst id String inst nodes Inst Node inst nodes [D] The actual network is formed by the instance nodes and the instance connectors; we call it I H. All node and connector instances must be of the classes identified in the Implementation level [E,F], and connector instances must connect instance nodes that belong to the same system [G]. All instance identifiers are unique [H,I]. Instance connectors implement the connection relationships identified in the Implementation level as part of the connects cl relation [J]. I H I H nodes conns Inst Node Inst Conn nodes class node classes [E] conns class conn classes [F] conns inst nodes nodes [G] in in nodes in inst id in inst id in in [H] ic ic conns ic inst id ic inst id ic ic [I] ci conns cc nc set connects cl ci Conn Class cc ci inst nodes Node Class nc set [J]

17 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS 17 NC3.1 NC3.2 node1:nc2 inst_conn1 node1:nc3.3 inst_conn2 NC1 NC2 <<instantiates>> inst_conn3 node2:nc2 inst_conn4 node2:nc3.3 NC3.3 <<instantiates>> FIGURE 9. Instance nodes and connectors of the actual network. Figure 9 shows the actual network; it only includes instances of two classes. Connections specified at the Implementation level are also preserved. Even though Instantiation of software and hardware independently does not depend on the Integration level, the complete I4 does. I I I S I H ic i comp in nodes ic class in class supports [K] All instance components must be able to run on at least one instance node of the network [K] Installation. The Installation level indicates the deployment of the instance components over the instance nodes in the actual system. This is a comprehensive description of the running distributed system; most of the times it can result in a very large diagram or a very long specification, thus the previous four levels guide the process of getting this final description, as well as giving the rationale behind many design decisions. We divide the Installation specification into installation requirements and the complete installation. Among the installation requirements we have: fixing the location of certain instance components, or the need to deploy some components either to the same instance node or to different nodes. All instance components must be installed once [A] and only over instance nodes identified in the Instantiation level [B]. The instance nodes must support

18 18 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN the class of instance components they are assigned [C]. Those instance components that have a fix location, must be deployed to the precise node [D]. Every pair of instance components that belong to a set in together or separated, must be deployed to the same [E] or different [F] instance node, respectively. I I together Inst Comp separated Inst Comp fix Inst Comp Inst Node deployment Inst Comp Inst Node dom deployment i comp [A] ran deployment nodes [B] c n deployment c class n class supports [C] fix deployment [D] i set together ic ic i set deployment ic deployment ic [E] i set separated deployment ic [F] ic ic i set deployment ic inst2:ic1 I1 inst_conn1 inst1:ic4.1 I3 I4 inst3:ic1 I1 node1:nc2 node1:nc3.3 inst_conn3 inst_conn2 inst1:ic1 I1 inst_conn4 node2:nc3.3 node2:nc2 FIGURE 10. Complete Deployment. We cannot use UML s deployment diagrams to express the separated relation, but we can express fix and together. Figure 10 shows the complete deployment of the instance components over the instance nodes.

19 : A FRAMEWORK FOR ARCHITECTURAL SPECIFICATION OF DISTRIBUTED SYSTEMS DISCUSSION A complete integrated specification of the software and hardware comprising a distributed system provides traceability and helps in the future configuration management. Our approach presents a framework whose layered structure makes it an efffective and convenient approach to system specification. We have used for specifying a real distributed system [3]. In this paper we used graphical notation to present example definitions. Even though the graphical notation is clearer for visualizing the structure of the distributed application, it gets much more more complex during the design of a large system. In the textual specification, on the other hand, is difficult to visualize design, but as it grows in size, it does not become structurally more complex. Having the possibility of switching between the two types of specification, and having changes made in one reflected in the other adds power to the specification technique since designers can choose the specification form based on what they consider appropriate. We are currently considering a number of extensions to this work. An automated tool for. The formalization of makes it possible to build a tool for specifying, documenting and guiding the design of distributed systems. The correspondence of each level of with constrained UML implementation diagrams, makes it possible to use these diagrams for building the tool that would have the strength of a fully formalized textual definition. Type Semantics. We have defined Types just with their interfaces. A more comprehensive approach would also need to be able to deal with semantics. We are considering using an existing methodology (e.g., [10]) for defining semantics and veryfying that (abstract) implementations correctly implement types. Dynamically Changing Systems. Creating and destroying processes at runtime in distributed systems is a common practice. Adding this capability to implies adding instances of the already specified classes to the nodes and i comp sets defined in the Instantiation level. REFERENCES [1] Robert Allen and David Garlan. A formal basis for architectural connection. ACM Transactions on Software Engineering and Methodoly, 6(3): , July [2] Matthias Autrata and Colin Strutt. DME Framework and Design, chapter 23, pages Network and Distributed Systems Management. Addison Wesley, 1994.

20 20 M. CECILIA BASTARRICA, STEVEN A. DEMURJIAN, ALEX A. SHVARTSMAN [3] M. Cecilia Bastarrica, Scott Craig, Steven A. Demurjian, and Alex A. Shvartsman. Using for Specifying Real World Distributed Systems. Technical Report CSE-TR-99-3, Department of Computer Science and Engineering, University of Connecticut, May [4] Grady Booch, James Rumbaugh, and Ivar Jacobson. Version 1.1 of the Unified Modeling Language (UML), September Rational Software Corporation. Available at [5] Digital Equipment Corporation. ObjectBroker. System Integrator s Guide. Technical report, Maynard, Massachusets, [6] Hans-Erik Eriksson and Magnus Penker. UML Toolkit. Johen Wiley and Sons, Inc., first edition, [7] Halldor Fossa and Morris Sloman. Implementing Interactive Configuration Management for Distributed Systems. In International Conference on Configurable Distributed Systems (IC- CDS 96), Annapolis, May IEEE Press. [8] Open Software Foundation. OSF Distributed Management Environment (DME) architecture. May [9] Martin Fowler. UML Distilled. Applying the Standard Object Modeling Language. Object Technology Series. Addison Wesley, 7 edition, June [10] Stephen J. Garland and Nancy A. Lynch. The ioa language and toolset: Support for designing, analyzing, and building distributed systems. Technical Report Technical Report MIT/LCS/TR-762, MIT Laboratory for Computer Science, Cambridge, MA, August [11] Thomas J. Howbray and Ron Zahavi. The Essential CORBA. Systems Integration Using Distributed Objects. John Wiley and Sons, Inc., [12] Jeff Magee. Configuration of Distributed Systems., chapter 18, pages Network and Distributed Systems Management. Addison Wesley, [13] Keng Ng, Jeff Kramer, and Jeff Magee. A CASE Tool for Software Architecture Design. Journal of Automated Software Engineering (JASE), Special Issue on CASE, [14] OMG. Common Object Request Broker: Architecture and Specification. rev 2.0, February OMG Document Number Available at [15] Michael D. Rice and Stephen B. Seidman. Using z as a substrate for an architectural style description language. Technical Report CS , Department of Computer Science, Colorado State University, September [16] Mary Shaw and David Garlan. Software Architecture. Perspectives on an Emerging Discipline. Prentice Hall, [17] J. M. Spivey. Understanding Z. Cambridge Tracts in Theoretical Computer Science 3. Cambridge University Press, Authors addresses: M. Cecilia Bastarrica, Department of Computer Science and Engineering, University of Connecticut, cecilia@cse.uconn.edu Steven A. Demurjian, Department of Computer Science and Engineering, University of Connecticut, steve@cse.uconn.edu Alex Shvartsman, Dept. of Computer Science and Engineering, University of Connecticut and Laboratory for Computer Science, MIT, alex@theory.lcs.mit.edu.