Architectural Views for Designing Relationships in Distributed Systems

Architectural Views for Designing Relationships in Distributed Systems Anca Daniela IONITA 1, Jacky ESTUBLIER 2 1 University Politehnica of Bucharest Splaiul Independentei 313, 060042, Bucharest, Romania Anca.Ionita @ mag.pub.ro 2 LIG-IMAG, 220, rue de la Chimie BP53 38041 Grenoble Cedex 9, France Jacky.Estublier @ imag.fr Abstract The paper studies the detailed design of relationships between concepts, taking into account four architectural views: logical, process, implementation and deployment. The classical patterns, applied if one considers the conceptual relationships from the logical view, are not enough for distributed applications, because the related elements may pertain to different computing nodes. More criteria should be used for the detailed design, like the technology used for communication paths - e.g. for Service Oriented Architectures - or the rights to modify the subsystems containing the related elements - if the distributed system is based on composing reusable assets. Moreover, the object oriented approach may need to be leveraged by a design based on aspects, for grasping crosscutting issues. Index Terms Aspect-Oriented Software Development, Design methodology, Distributed systems, Object oriented methods, Service Oriented Architectures I. INTRODUCTION The relationships between concepts are essential in modelling languages, as in Entity Relationship (ER) Diagrams used for databases, in the class diagrams from Unified Modeling Language (UML) and in Domain Specific Languages (DSLs). Taken the UML classification of relationships, generalization has a direct mapping on object oriented languages, but associations and aggregations may be designed in various ways. The difference between them is not structural - it stands in the life cycle of the related elements [1]. Qualified associations, aggregations and compositions may be decomposed into simple associations, enriched with OCL constraints [2], transforming complex UML concepts into basic ones, for easier transformations to executable code. Besides the associations expressing structural relationships, there are others, resulting from communication links, expressing a behavioural relationship [3]. Normally, they should not appear in class diagrams [4], but the related objects may pertain to different subsystems, as in the new law of Demeter [5] for concerns, so they need a structural support for interacting. The paper investigates the case of associations, for situations where they cross subsystem boundaries, in distributed systems. For doing this, we investigate the implications of various architectural views, which are created for modelling the system from the viewpoints of various stakeholders, as defined in the standards IEEE Std 1471-2000 and ISO/IEC 42010:2007. Specific view models were defined for distributed architectures (like RM-ODP, the Reference Model for Open Distributed Processing [6], adopted by ISO) and for Service Oriented Architectures (SOA) (like the Reference Architecture for SOA [7], from OASIS). For the purpose of this study, we used the variant of the 4+1 View Model that binds the Philippe Kruchten s views [8] on UML notation [9]. The logical view represents the structural elements, the process view shows the sequencing of activities, the implementation view presents the decomposition in subsystems and the deployment view outlines the distribution on physical nodes. The multiple views of the system have an important role in its description and documentation for various stakeholders (see Table 1). The study starts with the classical, object-oriented patterns for designing relationships (Chapter II) and continues with two kinds of relationships: - The former - relating concepts across distributed nodes, for example with Web services (see Chapter III); - The latter - relating concepts that belong to immutable, reusable assets, using aspect oriented design (see Chapter IV). Then, two case studies are discussed as real-world examples: a transnational e-business system developed in LD-CAST project [10] (Chapter V) and the horizontal relationships introduced in Mélusine [11] (Chapter VI). Views Logical Process Implementation (Development) Deployment (Physical) Use Case TABLE I. THE 4+1 VIEWS Characteristic UML Stakeholders Diagrams Class Package End users State Machine Sequence Communication System integrators Activity Component Programmers Deployment Use Case Activity System engineers All (Connecting the 4 views) II. CLASSICAL PATTERNS FOR DESIGNING RELATIONSHIPS The design of associations depends on their properties, specified in the Logical View with the UML class diagrams, like in Figure 1. Navigability and multiplicity are the most important, involving structural differences; for example, for unidirectional, N-ary ordered associations, one introduces a new attribute that represents a list of references to the associated objects, plus various operations that manipulate them (see Figure 2) 363

Figure 1. Logical view with N-ary, unidirectional and ordered association. Figure 2. Classical pattern for the structural design of associations. Figure 3. Relating concepts from different subsystems. The UML Component Diagram. Figure 4. Example of UML deployment diagram. «InnerProvider» SubsystemB «CoreServ» IRelatioshipAB «Message» ConceptBInstanciation Figure 5. Representation of the relationship service with UML. Moreover, there are also behavioral aspects that have their influence, like the moment when the source and destination instances are linked. The binding may be performed: - early, creating the link immediately after the instantiation of the source, in the ConceptA constructors; - late, creating the link when its navigation is demanded, by calling an operation like setassociatedobject at the right moment; this is specified in UML in the sequence diagram pertaining to the Process View. Moreover, the moment of creating the associated object may also be influenced (as described in the sequence diagrams); it might have existed before instantiating the relationship, or may be created when the link is requested. Still, the life cycle should not be influenced more than this; the associated object should evolve independently, if one respects the nature of the relationship. This paper is not concerned with the life cycle for aggregations. From the non-functional point of view, the link persistency may also be important; generally, information related to association instances are saved together with the related objects. However, one should pay attention to the association classes, which should be separately considered for serialization, or for creating new table entries in databases. III. DESIGNING RELATIONSHIPS IN DISTRIBUTED SYSTEMS Besides the logical information grasped in the class diagram, the Implementation (Development) View may reveal that the related concepts pertain to different subsystems, so they may be linked through an appropriated interface, as depicted in Figure 3. The Deployment View comes along with the possibility that the two concepts are actually implemented on different nodes, imposing a proper design for the connectors, in respect with the adopted standards, like HTTP and SOAP in Figure 4, where one supposed that the communication is performed with Web services. For modeling the service in UML, one may use the profile proposed in [14], where SubsystemB was considered a provider of inner services, the interface became a core service - supporting functionality for implementing distributed links - and the service exchanges information tokens through a message (see Figure 5). A standard entitled UML Profile and Metamodel for Services is in course to be adapted by Object Management Group (OMG). The paper will exemplify this situation on the LD-CAST prototype, which was developed to support local development cooperation actions using a Service Oriented Architecture (SOA) and semantic technologies (Chapter V). IV. RELATING CONCEPTS FROM IMMUTABLE SUBSYSTEMS The evolution of tools is towards growing in size, complexity and functionality. Along with the increasing demands for complex requirements, software industry has developed larger and larger systems, which are difficult to build, maintain, learn and customize. However, there is also an opposite trend, trying to build applications by allowing pieces of existing software to interoperate. The purpose is to build new applications with rich functionalities, while not increasing the dimensions of individual tools, but making them inter-operate with either new or existing programs. This alternative trend places a strong emphasis on reusability of non-homogenous artefacts, like COTS (Commercial Off The Shelf), legacy software or any other products available on the market, designed to interoperate or not. 364

Figure 6. Defining aspect oriented relationships. This chapter analyzes the design decisions entailed by the constraints of this second trend: (i) one does not have access to modify the code of the composed subsystems, and (ii) conceptual relationships should be established between elements situated in immutable pieces of code. A pattern for overcoming this constraint is given by Aspect Oriented Software Development (AOSD) [15], which is able to extend the structure and modify the behaviour without touching the original code. In this case, the relationships cannot be treated with the classical, object oriented approach, presented in Chapter II, because they become crosscutting concerns, whose life cycle has to be managed separately. Figure 6 presents two subsystems that cannot be modified, but expose the interfaces of their factories for objects instantiated from ConceptA and ConceptB respectively. To design a relationship between the two classes, one has to create an aspect that incorporates all the code related to its structure, life cycle management and interactions performed across its links. The aspect can prepare the relationship structure by reifying the pattern from the object oriented design and declaring inter-type members owned by ConceptA, like: private ConceptB ConceptA.associatedObject; public ConceptA.setAssociatedObject(ConceptB ob) {} Alternatively, one may declare a new interface, ConceptABFactory, which extends ConceptAFactory and creates objects of type ConceptAB, an extension of ConceptA. An example of this approach is given in Chapter VI. This pattern should be carefully used, as it disobeys the encapsulation principle, adopted when designing the original subsystems. V. CASE STUDY 1: RELATIONSHIPS IN AN E-BUSINESS PLATFORM BASED ON SOA This chapter analyzes relationships between concepts in a system for facilitating business cooperation, designed and developed in LD-CAST STREP project. From the logical point of view, the main concept is BusinessService, which may be supplied through various business processes, as depicted in the UML class diagram from Figure 7. The complex business services are supplied by orchestrating Web services delivered by various suppliers across Europe, like chambers of commerce or financial institutions. Before being able to present such a service to the End- User, at design time, the system has to represent the Business Process Models (BP_Model) that describe it, with the BP Modeler subsystem, which is deployed on another platform and uses a language that is easy to understand for business experts. After that, one has to define the correspondent Abstract Workflow (AbstractWF) - hosted by the Process Execution Manager (PEM) and written in an executable language (BPEL). At run time, the End-User has to make some choices for requesting the appropriate business service and, according to them, one determines the concrete workflow (ConcreteWF) that is going to be executed on PEM, according to the configuration of Web services (WS_Configuration) that best fits the user preferences. The relationships between these concepts appear in the Logical View, as seen in Figure 7, but the problem is that the related concepts are actually implemented and persisted in different subsystems (see Table II). Moreover, these subsystems are deployed on different nodes (Figure 8). The solution adopted in LD- CAST was to define Web services for the communication between distributed nodes, because the system was already using services for implementing workflow activities. TABLE II. RELATED CONCEPTS IN LD-CAST ConceptA ConceptB Name Subsystem Name Subsytem Business Service Run-Time Group of BP Models BP Modeler Process Run-Time BP Model BP Modeler BP Model BP Modeler Abstract WF PEM Requested BS Run-Time Concrete WF PEM Concrete WF PEM WS Search & Configuration Discovery Figure 7. Logical View of LD-CAST. Figure 8. Deployment View of LD-CAST. 365

VI. CASE STUDY 2: ASPECTS FOR RELATING IMMUTABLE DOMAINS This chapter analyzes relationships between concepts pertaining to different models, in a federative architecture based on composing subsystems called domains, whose execution is driven by specific metamodels and is supported by Mélusine platform [11]. A complex application may pertain to a composite domain, characterized by several models (one for each sub-domain) connected by interdomain relationships. This case study in based on RichProduct, a domain obtained by composing the autonomous domains Product and Document, while preserving their original implementation. The Product domain can manage versions of products characterized by typed attributes; these products are empty - they do not contain any file to describe them better. The Document domain manages versions of documents and stores them in a remote repository. Documents may be files or directories, and there may be an exclusion pattern for ignoring certain files in a directory. The idea behind RichProduct domain was to have a versioning system for complex, rich elements, characterized by some attributes (managed by Product domain) and by supplementary information stored in one or more files (managed by Document domain). If Product domain alone rather corresponds to a PDM (Product Data Management) tool [16], RichProduct - obtained through its composition with Document may be used in many other complex systems, e.g. for document management or for software configuration management. For this purpose, one has to establish inter-domain relationships between the subdomains correspondent concepts, as seen in Table III. TABLE III. RELATED CONCEPTS IN RICH PRODUCT ConceptA ConceptB Name Sub-domain Name Sub-domain Product Product Document Document Branch Product Document Branch Document Revision Product Document Document Revision Figure 9. The Logical View of Rich Product Domain. Figure 10. Deployment View of Rich Product Domain. The constraint imposed by the federative methodology [17] was to keep unchanged the code for Product and Document domains. The inter-domain relationships between them have been designed as aspects that extend the classes of Product domain, in the manner presented in Chapter IV. The concepts RichProduct, RichBranch and RichRevision from RichProduct domain, described in the class diagram from Figure 9, are extensions of the classes Product, Branch and Revision from Product domain. For example, RichProduct is an extension of Product class from Product domain, such as to have an association with the Document class from the Document domain. RichProductDomain, allowing the creation of products with associated documents, is also an extension of the product factory: ProductDomain. An example of AspectJ code for the method createproductwithcontent, which creates objects of type RichProduct, is presented in Appendix A; exception treatment has been removed for outlining the paper ideas. The solution takes into account that the documents are hosted by a different node (see Figure 10). It was considered that Product domain is active, because its components are interactive and are influenced by non deterministic actors, like humans. On the contrary, Document domain was considered passive, only performing actions requested by other domains; therefore, its concepts are hidden to the user of the composite domain. The life cycle of documents, with their branches and revisions, is under the complete control of products, with their respective revision tree. Thus, as observed in the example, the destination life cycle is dependent on the source one. Along with the methods for managing relationships lifecycle, the aspects may include other methods - introduced for designing interactions - as also performed by Blay [18], or by Lieberher, with aspectual collaborations [19]. VII. CONCLUSION Designing relationships between concepts is a complex task, which has to take into account multiple issues: (i) the structural elements shown in the Logical View, (ii) the behavior imposed by the type of relationship, or by the description from the Process View, (iii) the Implementation View, which may reveal that concepts are managed by different subsystems, (iv) the Deployment View, if the system is distributed over several computing nodes and, last but not least, (v) the possibility to modify the code correspondent to these concepts. Experience showed that an object oriented approach may not be enough in this last situation, but an aspect oriented design in necessary. APPENDIX A Relationship Implemented with AspectJ public aspect RelH_Product_Document extends FedeAbstractAspect { public RichProduct ProductDom.createProductWithContent (ProductType producttype, Map attributesmap, String host, URI directory, Pattern exclusion) { Product product = createproduct( producttype, attributesmap ); 366

} DocumentDom documentdom = (DocumentDom) MelusineCore.getDomainRoot (DocumentDom.NAME); DocumentType documenttype = getdocumenttype (product.getproducttype(), documentdom); Document document = documentdom.createdocument (documenttype, product.getidentificator(), host, directory, exclusion); product.link(document); return (RichProduct) product; ACKNOWLEDGMENTS Special thanks to the LD-CAST partners for the experience gained during the project, which inspired the first case study of the paper. This work was supported in part by CNCSIS -UEFISCSU, project number PNII - IDEI 1238/2008. REFERENCES [1] Y-G. Guéhéneuc, H. Albin-Amiot, "Recovery Binary Class Relationships : Putting Icing on the UML Cake", Conference on Object-Oriented Programming, Systems, Languages & Applications (ACM / OOPSLA 04), Vancouver (Canada), pp. 301-314, 2004. [2] M. Gogolla, M. Richters, "Equivalence Rules for UML Class Diagrams", in The Unified Modeling Language. <<UML>> 98: Beyond the Notation, First International Workshop, Mulhouse, France, J. Bezivin, P.A. Muller (Eds.), LNCS, Vol. 1618, pp. 92-106,1999. [3] P. Stevens, "On the interpretation of binary associations in the Unified Modeling Language", Journal on Software and Systems Modelling, Vol. 1, No. 1, pp. 68-79, 2002. [4] G. Génova, J. Llorens, J. Fuentes, "UML Associations : A Structural and Contextual View". Journal of Object Technology, Vol. 3, No. 7, pp. 83-100, 2004. [5] K.J Lieberherr. "Controlling the Complexity of Software Designs", Proc. of the 26th International Conference on Software Engineering (IEEE/ICSE 2004), Scotland, United Kingdom, pp. 2-11, 2004. [6] N. May, "A survey of software architecture viewpoint models", Proc. of the Sixth Australasian Workshop on Software and System Architectures, Melbourne, Australia, pp. 13-24, 2005. [7] "OASIS Reference Architecture for Service Oriented Architecture Version 1.0", Public Review Draft 1, 2008, Available: http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf [8] Ph. Kruchten, "Architectural Blueprints The 4+1 View Model of Software Architecture", IEEE Software, Vol. 12, No. 6, pp. 42-50, 1995. [9] FCGSS, "Applying 4+1 view architecture with UML2", White Paper, 2007, Available: http://www.sparxsystems.com/downloads /whitepapers /FCGSS_US_WP_Applying_4+1_w_UML2.pdf [10] A.D. Ionita, M. Florea, L. Jelea, "4+1 Views for a Business Cooperation Framework Based on SOA", IAENG International Journal of Computer Science, Vol. 36, No. 4, pp. 332-343, 2009. [11] A.D. Ionita, J. Estublier, Th. Leveque, T. Nguyen, "Bi-dimensional Composition with Domain Specific Languages", e-informatica Software Engineering Journal, Vol. 3, No. 1, pp. 27-41, 2009. [12] E. Barra, G.Génova, J. Llorens, "An approach to Aspect Modelling with UML 2.0", Proc. of Aspect-Oriented Modeling Workshop at UML'2004, Lisbon, Portugal, 2004 [13] C. Larman, "Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and the Unified Process", Pearson Education, Prentice Hall, 2003. [14] M. Lopez-Sanz, C. Acuna, C. Cuesta, E. Marcos, "Modelling of Service-Oriented Architectures with UML", Electronic Notes in Theoretical Computer Science, Vol. 194, No. 4, pp. 23-37, 2008. [15] R.E. Filman, T. Elrad, S. Clarke, M. Aksit, "Aspect-Oriented Software Development", Addison-Wesley Professional, 2004. [16] J. Estublier, G. Vega, "Reconciling software configuration management and product data management", Proc. of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, Dubrovnik, Croatia (ACM/ ESEC-FSE '07), pp. 265-274, 2007. [17] J. Estublier, A. D. Ionita, G. Vega, "Relationships for Domain Reuse and Composition", Journal of Research and Practice in Information Technology, Vol. 38, No. 4, pp. 287-301, 2006. [18] M. Blay-Fornarino, A. Charfi, D. Emsellem, A-M. Pinna-Dery, M. Riveill, "Software Interactions", Journal of Object Technology, Vol. 3, No. 10, pp. 161-180, 2004. [19] K. Lieberherr, D.H. Lorenz, J. Ovlinger, "Aspectual Collaborations: Combining Modules and Aspects", The Computer Journal, Vol. 46, No. 5, pp. 542-565, 2003. 367