{gledson, michael, yuri, jjjunior,

Transcription

1 X-ARM: An Asset Representation Model for Component Repository Systems Glêdson Elias Michael Schuenck Yuri Negócio Jorge Dias Jr. Sindolfo Miranda Filho COMPOSE Component Oriented Service Engineering Group Informatics Departament, Federal University of Paraíba João Pessoa, PB, Brazil, , (+55 83) {gledson, michael, yuri, jjjunior, ABSTRACT Nowadays, one of the most challenging tasks in component-based software development processes is to discover suitable reusable assets that fulfill the requirements of a particular software system under development. In such a context, this paper presents an XML-based asset representation model for describing all kinds of software assets that can be produced or reused within componentbased software development processes. The proposed model is based on asset metadata that provides effective means for developing universal repository systems that can deal with discovery, retrieval and composition of software components. Categories and Subject Descriptors D.2.13 [Software Engineering]: Reusable Software reusable libraries, reuse models. General Terms Documentation, Languages. Keywords Asset reuse, component-based software development, component description, component repository system. 1. INTRODUCTION Component-based development (CBD) focuses on reuse of already available software assets for reducing development time and cost, and besides, improving software quality and productivity [4][8]. However, nowadays, one of the most challenging tasks in CBD is to discover suitable reusable assets that fulfill the requirements of a particular software system under development. In order to address such a challenge, several open and proprietary component repository systems [6][9][11] have been proposed by industry and academia. Although repository systems can adopt different architectures and technologies, generally, all of them must provide the means for storing, discovering and retrieving packaged software components, which are developed by independent or associated producers. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC 06, April, 23-27, 2006, Dijon, France. Copyright 2006 ACM /06/0004 $5.00. However, according to [13] and [14], a repository system must store not only software components, but also metadata describing them. Such metadata ought to be semantically annotated in an unambiguous language and has the purpose of describing what the component is, what interfaces it provides and depends on, what events it fires and catches, what other components compose it, what related assets it has, what quality certification it has, who has certified it, and who can retrieve it, perhaps with side economic constraints. Once available in repository systems, metadata can be employed for indexing and classifying software components, making possible to develop search engines capable of discovering suitable reusable assets required by a given software project. It is important to emphasize that metadata must be associated not only with software components (executable code), but also to any software asset, which can be considered any artifact of the software process that can be produced or reused, including executable code, source code, interface specification, usage documentation, use cases, class diagrams, test plans and so on. Consequently, the adoption of an asset representation model for describing metadata about all kinds of software assets is of paramount importance for leveraging reuse throughout all phases of the component-based software development process. In such a context, this paper presents an XML-based asset representation model, whose purpose is to semantically describe all kinds of software artifacts that can be stored in a component repository system. The proposed model is called X-ARM, an acronym for XML-based Asset Representation Model. For each asset, the respective metadata is described as an XML document, which facilitates its distribution and processing. X-ARM defines three types of XML documents for representing distinct categories of software assets. Besides, it also defines rules for packaging assets. In essence, X-ARM is based on asset metadata that provides effective means for developing universal component repository systems that can deal with discovery, retrieval and composition of software components. The remainder of this paper is organized as follows. Section 2 discusses some related work. Section 3 introduces the main features of the proposed model. In Section 4, we present the three asset types and introduce the asset packaging. Finally, Section 5 presents some concluding remarks. 2. RELATED WORK In this section we discuss two existing solutions for describing software components and related artifacts: RAS (Reusable Asset Specification) [12] and OSD (Open Software Description) [10]. 1690

2 2.1 RAS RAS [12] defines a standard way for asset packaging. In such a scope, asset is defined as a collection of artifacts to solve a specific problem. Instead of packaging only a compiled component (executable code), RAS also packages all related artifacts. For each asset, its metadata is stored in a manifest file, which is an XML description of the artifacts and features related to that asset. In order to describe the XML manifest files, RAS defines two major categories: Core RAS and Profiles [12]. In the former, asset is the root element and specifies the common XML elements for asset specification, including elements for describing classification, usage, asset artifacts and related assets. The Core RAS can be extended with Profiles, which can add new features, but can not change or exclude Core RAS elements and attributes. RAS specification defines three profiles: Default Profile, Default Component Profile and Default Web Service Profile. The first is a Core RAS realization. The remainder profiles are Default Profile extensions to represent component and Web services features. Although it covers several component features, RAS is not fully appropriate to solve issues such as fine-grain reuse, extensibility, certification, access control and business model. For example, in the RAS context, an asset encloses an entire and closed set of artifacts that solve a specific problem. Therefore, it is difficult an asset to reuse artifacts included in other ones. Besides, it also turns more difficult component extensibility, which means the addition of interfaces to new component releases, maintaining only references to other interfaces of previous releases. In RAS, instead of referencing reused interfaces, it is needed to unpack the old asset, for copying the reused interface description, and, then, to pack again in the new asset description. Another disadvantageous point is its access control, which is specified using a single string declared in the manifest and does not assign any associated semantic context. 2.2 OSD OSD is an XML-based vocabulary that has the goal of describing software packages and its relationships with other packages. In OSD, it is possible to express several features such as versioning, internal packaging structure and existing dependencies [10]. The purpose of OSD is to provide support for automated software distribution environments. In such a scope, a tool is responsible for reading an OSD file and retrieving needed information in order to download and either install or update the respective software package, taking into account its dependencies. It is important to highlight that, although the OSD focus is the general software distribution description, it covers some components characteristics. For example, OSD handles features as naming, versioning, dependencies and non functional requirements [10]. However, due to the OSD goal being basically the description of software ready for execution by final users [10], several component particularities are not covered. For example, OSD does not specify interfaces, business models information, certification, visibility and events. 3. X-ARM FEATURES In X-ARM, asset is defined as a set of software artifacts useful to component-based software development processes. In order to make possible to represent the most kinds of assets and improve their reusability, they are categorized into component interfaces, executable components and resources. In such a sense, X-ARM is a model, defined by, to describe the features of those three types of assets through XML documents, enabling the required metadata representation. Considering that a software producer accesses a component repository system looking for software components, such an asset type can be considered the main asset in the X-ARM context. In other words, component descriptions can reference interfaces, resources and even other components, in the case of component composition. X-ARM is intended to be model independent, supporting the description of components implemented according to several component models such as CCM (CORBA Component Model), JavaBeans, Enterprise JavaBeans and COM (Component Object Model). Future component models and other features of existing models can be aggregated to X-ARM by adding appropriate XML elements. Interfaces represent a group of operations offered by a given component to its clients [14]. Generally, interfaces are represented using interface description files, depending on the component model, such as CORBA IDL (Interface Description Language) and Java interface files. In practice, several components can implement the same interface. In X-ARM, descriptions of different components, possibly developed by distinct producers, can reference a specific X-ARM interface description, provided that they implement the interface operations and their component models are compliant with the interface description language. On the other hand, resources are typically component specific. Unlike interfaces, however, resources can not be easily and entirely reused by more than one component. Such a situation occurs because resources are artifacts specific to exclusive components, such as documentation, source code, class diagrams, test plans. Nevertheless, unusual exceptions can happen when all artifacts represented in a resource description file are valid for different component releases. Perhaps, such exceptions are more probable when different releases refer to the same component with different versions or development status (for instance: beta, stable, mature). X-ARM offers support to several features, such as unique identification, visibility control, component development process, asset classification, composition, and so on. Such features are briefly introduced in the following subsections. 3.1 Unique Identification A repository system can not allow duplicate asset names in order to avoid ambiguous retrievals. In such a way, X-ARM adopts a global identification scheme, which is both human and machine readable. Besides, such a schema provides location transparency and independency, even considering the context of distributed and replicated repositories. X-ARM identifiers are composed of three XML attributes: id, version and status. The id attribute has a hierarchical, URL-like name structure [3], but without any physical location reference. In X-ARM, stored assets are logically grouped in domains, adopting an approach similar to DNS (Domain Name System) [17]. Such a location transparency allows asset distribution and replication. In such a sense, domains represent logical groups in order to distinguish asset producers and their family of products. Figure 1 exemplifies the name hierarchy, where the root domain is represented by a dot. 1691

3 br. com which includes the Component Specification stage. In such a stage, Interface Specification, Component Specification and Architecture Specification represent artifacts that can be generated during the development process. compose xmlparser ufpb xmldoc alpha Figure 1. X-ARM name space example beta According to Figure 1, we can say that br.compose.xmlparser identifies the xmlparser asset developed by the br.compose domain. A sub-domain is any domain below other one. For example, br.ufpb is a sub-domain of the br domain, which in turn is a sub-domain of the root domain. The version attribute informs the asset version and consists of a sequence of one or more dot-separated natural numbers. The status attribute indicates the asset maturity stage and can have the following ordered values: planning, pre-alpha, alpha, beta, stable, mature and inactive. Together, version and status provide the means to represent the history of the asset evolution. 3.2 Visibility Control In order to manage the access of software producers to assets stored in a repository system, X-ARM provides two approaches for visibility control. First, it includes the boolean attribute indexable that specifies whether or not the respective asset can be indexed. When an asset is not indexed, it can not be found using search engines, but can be retrieved directly using its identifier. Second, X-ARM defines the retrievable element that allows a producer to control which domains can have permission to retrieve an asset. If the retrievable element is not present, the respective asset can be retrieved by anyone. On the other hand, if the retrievable element is present, only the specified domains can retrieve the asset. The retrievable element defines the permit and deny attributes, which identifies domains that can retrieve or not the asset. By using such attributes, it is possible to permit a domain and subsequently to deny one of its sub-domains. Such a control is important to allow the asset developer to create private assets, only accessed by enterprise or project members. Figure 2 presents the visibility element of a given asset. The asset is indexable and cannot be directly retrieved by anyone other than users that belong to the br.compose domain, except those in the br.compose.tmp sub-domain. <visibility indexable= true > <retrievable permit= br.compose /> <retrievable deny= br.compose.tmp /> </visibility> Figure 2. Description of visibility 3.3 Development Process Several development processes guide component-based software engineering, such as UML Components [5], Catalysis [7] and Kobra [2]. X-ARM provides support to control generated artifacts in each phase of a given process. In order to provide such a support, development process descriptions can be created through XML documents and validated against an. Both descriptions and schema are stored in a repository system as resources. Figure 3 illustrates a section of the UML Components process description, representing the Specification workflow, <process name="uml Components"> <part name="specification" parttype="workflow"> <part name="component Specification" parttype="stage"> <artifact maxoccurs="unbounded">interface Specification</artifact> <artifact maxoccurs="unbounded">component Specification</artifact> <artifact maxoccurs= unbounded >Architecture Specification</artifact> </part>... </process> Figure 3. UML Components description After describing a development process, descriptions of assets created according to such a process can make reference to the identifier of the resource that represents the development process. Therefore, it is possible to provide a set of integrated development tools that make use of a component repository system for managing development processes and their artifacts. 3.4 Asset Classification The reuse success is directly related to finding suitable assets [9]. In such a sense, it is essential an effective asset classification mechanism. X-ARM supports two classification styles: keywords and hierarchical application domains. In the former, it is possible to insert any number of keywords that reflect the asset characteristics. In the latter, the asset developer can choose from a predefined hierarchical classification the application domains that best represent the asset features. The predefined hierarchical classification is also described in an XML document, which can be created by any registered developer of the repository. Classification descriptions can also be validated against an XML Schema. Similar to development processes, both descriptions and schema are stored in a repository system as resources. Figure 4 illustrates a segment of a description file of application domains. <domains> <domain name="engineering"> <domain name="civil"> <domain name="design"/> <domain name="geographic Data"/> </domain> </domain> </domains> Figure 4. Description of application domains As can be seen in Figure 4, two application domains are specified: Engineering.Civil.Design and Engineering.Civil.Geographic Data. 3.5 Business and Certification Models X-ARM supports representing business models for negotiating assets (components and resources). Such business models are specified using XML elements with attributes that represent negotiation data in a key/value format. Such an approach provides freedom to developers to define how assets can be purchased by consumers. For instance, the key can be a range of the number of installed copies and the value can be the respective cost. X-ARM also allows indicating a textual file containing license terms. Such a file can be stored in the repository as a resource or even included in the asset package. 1692

4 The component quality, reliability and functionality can be certified by certifier entities [16]. In order to allow representing certification data, X-ARM defines the certifications XML element and its children elements. Certification issues are also defined using key/value attribute pairs. For instance, the key can be a quality parameter and the value can be the degree at which the asset meets such a parameter. Notice that the certification of isolated interfaces and resources makes no sense. Therefore, only components can be certified, which involves the adequateness of their interfaces and resources. 3.6 Component Composition Software components can be composed of other components [14][16]. X-ARM provides support for representing this feature in two ways. In the first way, the composition element enables referencing to other components stored as assets in the repository system. In the second way, the package element refers to serialized components, whose state was already configured through properties or accessor methods. After configured, the component is stored in a binary file. Such mechanism is very usual in JavaBeans [15]. Thus, serialized components are stored in the asset package of the composed component. The component description points to serialized components in the same manner as it refers to files of the executable component. Figure 5 presents a part of a component description representing component compositions. By using the asset identifier, the component element makes a reference to another component stored in the repository. Besides, the second archive element indicates the file inside the asset package that contains a serialized component. Notice that the first archive element describes a code file of the component under description. <composition> <component id="br.compose.search" version="1.5" status="mature"/> </composition> <package> <archive reference="b/xmlparser.class" description="java Classes"/> <archive reference="b/graph.bin" description="serialized Component"/> </package> Figure 5. Description of composition 3.7 Non-Functional Requirements In order to describe non functional requirements, X-ARM defines the context element to indicate prerequisites necessary to make the correct deployment and usage of the asset. In X-ARM, nonfunctional requirements are separated into two types, according their importance. The mandatory requirements are predefined by X-ARM, such as operating system, processor family and required storage space. Optional requirements are represented by key/value attribute pairs for allowing developers to specify specific requirements, such as memory space, required tools and so on. 4. X-ARM ASSET TYPES This section presents the description of the three asset types, in which the X-ARM features are applied. Besides, some issues of the asset packaging are discussed. 4.1 Interfaces An interface is one of the three asset types maintained by an X-ARM compliant repository system. Each X-ARM interface description specifies a single interface, enabling the interface reuse. Each interface description specifies the operations that ought to be implemented by component assets that implement it. An X-ARM interface description has five XML elements under the root element, named interface. The classification and visibility elements represent information about interface classification and visibility control, respectively. The changelog element represents the interface evolution history, exposing information related to changes over previous versions. The package element indicates files, inside the asset package, that describe the interface using specific interface description languages. Finally, the operations element describes the provided operations in terms of parameters, their types and directions (in/out), and also return types. 4.2 Resources Most of the resource types are just for allowing a repository system to provide support for specific approaches. Such resources, classified in Figure 6 as Special Resource Types, are: application domains schemas, development process schemas, application domains descriptions, development process descriptions, license terms and even the X-ARM schemas. The usage of such special resources has already been discussed in previous sections. The most common resource type in a repository system refers to artifacts generated throughout the component development process. In Figure 6, General Resources represent such kind of resources, which can be for example use cases, class diagrams, API documentation, source code and test plans. When the development of a component follows a development process, the X-ARM resources description allows indicate the type of each resource and the phase where it has been generated. Special Resource Types Devel. Process App. Domains X-ARM Resource General Resources Licenses Types Figure 6. Classification of resource types App. Domains Description Devel. Process Description An X-ARM resource description has six XML elements under the root element, named resource: changelog, classification, visibility, package, businessmodels and context. The four former elements have purposes similar to interface descriptions. The businessmodels element defines the allowed ways to purchase the resources and context defines non functional requirements. 4.3 Components A component description is the specification of functionalities of an executable component. All X-ARM features, presented in previous sections, are applicable in the component context. Moreover, the other asset types (interfaces and resources) exist in order to complement the component functionality, thus, having their descriptions referenced by component descriptions. In order to simplify the component representation, Figure 7 employs UML notation for illustrating the basic XML elements of a component description. As can be seen, component is the root 1693

5 element. Besides the features presented in this paper and the elements introduced in the Sections 4.1 and 4.2, the componentmodel element is defined, in, as an abstract type whose goal is to represent the component features, such as interfaces and events, according to the component model. Figure 7. Component description elements Currently, X-ARM supports the description of components according to six models: CCM, COM, JavaBeans, EJB,.NET and Web Services. Such models are defined in, as concrete subtypes of the abstract componentmodel type. CCM is the most complex model, supporting provided and required interfaces, and besides, interfaces for configuration and component life-cycle management. CCM also supports properties and events. The differences in other component models are in terms of the existence or not of such CCM features. 4.4 Asset Packaging In the X-ARM context, every asset must be described and controlled by one asset description file, called manifest.xml. The files that compose the asset must be inside the package archive and must be referenced in the package element of the manifest. The manifest and all referenced files are packaged in a single archive file using the ZIP compression algorithm [1]. The manifest files enable: (a) verify consistency of packaged files before storing the asset in a repository system, ensuring that referenced assets are already registered in the repository; (b) download required assets during runtime or development time; and (c) detect dependencies among assets, making possible to assure that an asset can be excluded from a component repository. 5. CONCLUSION The proposed XML-based model, called X-ARM, has the potential to semantically describe software assets. Such a model defines three asset types: interfaces, resources and components. By exploring X-ARM, a compliant component repository system can provide effective means to store, discover and retrieve required assets. As opposed to existing proposals, X-ARM is a novel approach, which solves serious problems and overcomes significant limitations of previous solutions. X-ARM is an advancement in its own, given that no prior proposal could show support for the following features: business model, visibility control and certification. Once we have concluded the asset representation model, future work should focus on the design and implementation of a compliant component repository system, including approaches for indexing mechanisms and search engines. 6. ACKNOWLEDGEMENTS We thank the Brazilian agency FINEP (Research and Projects Financing) for financial support. 7. REFERENCES [1] A. Moffat, T. C. Bell, I. H. Witten. Lossless compression for text and images. International Journal of High Speed Electronics and Systems 8 (1), pp , [2] Atkinson, C. et al. Component-Based Product Line Engineering with UML. Addison-Wesley; 1 st edition [3] Berners-Lee, T., Masinter, L. and McCahill, M. Uniform Resource Locators (URL). RFC1738. December (last access on November 02, 2005). [4] Boehm, B. Managing Software Productivity and Reuse. IEEE Computer 16(9), p , [5] Cheesman J., Daniels J. UML Components: A Simple Process for Specifying Component Based Software. Addison-Wesley [6] ComponentSource. (last access on November 02, 2005). [7] D Souza D. F, Wills A. C. Objects, Components, and Frameworks with UML. The Catalysis Approach. Addison- Wesley, [8] Gill N. S. Reusability Issues in Component-Based Development. ACM SIGSOFT Software Engineering Notes, Volume 28, Issue 4, July [9] Henninger, S. Using Iterative Refinement to Find Reusable Software. IEEE Software, 11(5), [10] Hoff, Arthur van; Partovi, Hadi; Thai, Tom. The Open Software Description Format (OSD). Submission to the World Wide Web Consortium (W3C), w3.org/tr/note-osd (last access on November 02, 2005). [11] Inoue, K.; et al. Component Rank: Relative Significance Rank for Software Component Search. In ICSE, pages 14-24, Portland, OR, [12] OMG. Reusable Asset Specification Version (last access on November 02, 2005). [13] Orso, A., Harrold, M. J., and Rosenblum, D. S. Component Metadata for Software Engineering Tasks. In Proc. 2nd International Workshop on Engineering Distributed Objects (EDO 2000). Springer, Berlin, 2000, [14] Sametinger, J. Software engineering with reusable components. Springer-Verlag New York, Inc., NY, [15] Sun Microsystems. JavaBeans Specification Version (last access on November 02, 2005) [16] Szyperski, C., Gruntz, D., and Murer, S. Component Sofware: Beyond Object-Oriented Programming. Second Edition, Addison-Wesley / ACM Press, [17] Tanenbaum, A. S. Distributed Systems: Principles and Paradigms. Prentice Hall,