Achieving Quality Software Development for Distributed Environments

Transcription

1 Achieving Quality Software Development for Distributed Environments Stephen S. Yau Computer Science and Engineering Department Arizona State University Tempe, AZ , USA Abstract With the rapid advances of computer networking and wireless technologies, the applications of information technology have been drastically broadened. However, there are also more challenges in developing quality software for these applications. In this paper, recent advances to meet these challenges are discussed. In particular, among these advances, componentbased software development, middleware, and design patterns to improve the development of quality software in distributed environments are considered. Keywords: Quality software development, distributed environments, component-based software development, middleware, design patterns 1. Introduction Rapid progress in computer networking and wireless technologies has the great potential of drastically expansion of applications of information technology in various distributed environments. In order to exploring this potential, it is necessary to have effective approaches to developing quality software for applications in distributed environments. Developing software for distributed applications is more challenging than that for centralized computing due to heterogeneity of environments and platforms, changes in requirements, providing security, timing, reliability, availability and fault-tolerance [1]. Moreover, with the increased use of mobile and embedded devices in different wireless ad-hoc networks, distributed-system developers will likely to face additional challenges, such as sensor information processing, context awareness, adaptation, and reconfiguration. In this paper, we will discuss component-based software development, middleware, and design patterns to improve the development of quality software and to meet the challenges in distributed environments. 2. Component-based Software Development The component-based software development (CBSD) approach has shown promises in application software development, especially where the target software is distributed and spans across different computing platforms and environments. Unlike traditional software development practices, CBSD focuses on construction of software, rather than programming. Although programming is still required at the implementation phase, CBSD removes the detailed programming task from software developers to component developers, who are usually well versed in specific problem areas. Distributed software development often becomes the tasks of a third party, which identifies a set of pre-developed components from a repository, possibly customizes them to fit specific requirements, and finally integrates them to build the application software. The CBSD approach thus facilitates better software reuse and higher productivity in software development. However, most importantly this approach to software development provides the necessary support to reuse existing high-quality components in different cases. In spite of the possible significant production cost of high-

2 System Requirements Architecture and Interface Identification Reusing Customizing Creating Component Generation Component Integration Application Software Figure 1: Component-based Software Development Process quality components, the repeated reuse of these components both justifies the initial cost and guarantees continuous quality assurance of all the target software. 2.1 Component-based Software Development Process: The entire CBSD process can be depicted as shown in Figure 1. The process can be summarized as follows:! Architecture and Interface Identification: After the system requirements are identified, the system architecture is derived. Initially, the system architecture consists of a number of components and connectors [2] and their interrelationships, which provide a sketch of the structure of the system. The initial architecture is usually refined to incorporate the interfaces of the components and different non-functional requirements, such as timing, fault-tolerance, and security.! Component Generation: At this stage, the necessary components are either retrieved from the component repository or created if a suitable component is not found. However, retrieval and creation of components represent two extreme scenarios. In most cases, the number of incompatible components, which almost fit the requirements, but not completely, may be significantly larger than the ones that satisfy the requirements perfectly. To address this case, different component-customization techniques [3] can be applied to make the components seamlessly fit into the target software. Regardless of the nature of the techniques, the overall customization process could be divided into two phases. As shown in Figure 2, the first is compatibility check [2] phase. At this stage, the degree of compatibility of the incompatible components with the target architecture is determined. The information is then fed into the customization phase. Here, the necessary customizations are applied to make the component compatible with the target architecture. Depending on the nature and criticality, customization can be applied either inside or outside the components. While external customization could be straightforward, for example, using adapter generation [4], internal customization requires special support from the components, and hence it can be complicated if necessary design-time information is not present inside the components. In other words, the design and the packaging of components affect

3 Compatibility Check Customization Integration process. Detailed information about component integration can be found in [2,4-6]. The process can be divided into the following stages: Incompatible Components Compatible Components Figure 2: Component Customization Process the success of its customization, and ultimately its degree of reusability. To address this issue, we presented a Real-time Component Framework (RCF), as shown in Figure 3, and built-in customization techniques specifically for building self-customizing components to be used in real-time software [3]. More information about RCF and customization techniques is available in [2] and [3]. 2.2 Component Integration: At this stage, the components are integrated to form the actual software to be developed. Now, we would like to discuss the Distributed Component! Visualize the distributed components and their interfaces The integration tool allows the software developer to open the components that can be retrieved over the common object environment to construct a whole software structure using Drag-and-Drop.! Generate component adapter The integration tool generates an adapter for each component to link distributed methods using Distributed Component Common Interface based on user interaction. The link information is not available when a component is built. Only at integration stage, the developer specifies source and target methods of connections. The adapter stores this information for the component and establishes remote method invocations through the common object environment at run-time.! Modify properties <<Interface>> IRTService <<Interface>> IRTCompatible <<Interface>> IRTManage <<Interface>> IRTCustomize <<Interface>> IRTOutgoing <<Façade>> RTDispatcher RTArbitrator RTCore RTMediator RTObject Store RTMonitor Outgoing Event Queue Incoming Event Queue The RTManagement Layer [common to all RCF-compatible components] Object 3 Object 1 Object 2 Object n Object 4 The RTSolution Layer [unique to each to component] Figure 3: A Simplified View of the Real-time Component Framework (RCF)

4 The tool lists the public changeable properties of a component and allows the developer to modify their values so that a versatile component can be tailored to a specific software system.! Generate group adapters To keep state consistency maintenance among replicated distributed components transparent to developers, we use special group adapters with extra negotiation methods besides regular components. At the time of integration, the integration tool assigns the membership list and the prime membership ID into each group adapter s changeable attributes. Upon receiving remote requests, a group adapter will forward these requests to the prime member who will then broadcast to the others. All members of the group respond in the same way and therefore update their states accordingly while only the prime component will be allowed to send out remote requests through its group adapter if the current request triggers other components. If a member fails to contact the prime host, it will broadcast exception to all the remaining members using Distributed Component Replication Interface, negotiate for a new prime replica, retrieve and re-establish state consistency when a new member joins as a new backup component. 4. Component-based Software Development Using Design Patterns: While it is important to have well-developed and customizable components and an effective integration mechanism, the absence of a sound architecture can negatively affect the quality of the target software. Although it is difficult to derive an appropriate architecture at the first try, judicious use of design patterns can help in two ways: First, design patterns are solutions to recurring design problems [7], and the solutions usually embed distilled design experience by other developers. Second, good patterns can be formally represented, analyzed, and incorporated into the other phases of software development. The first characteristic of design patterns provides a mean for using well-accepted design for producing high-quality software. The second characteristic ensures that the high quality of the patterns can be consistently and almost automatically applied throughout the software development lifecycle. In [8], we present an approach to use design patterns in component-based software development. Specifically, this approach uses a formal design pattern representation and a design pattern instantiation technique for Sub-component Legacy software unit wrapping D istributed Com ponent Com m on Interface wrapping Component Replication Interface wrapping IDL Real-time Specification Interface Distributed component IDL IDL Interact w ith Replicable component Integration Tool Real-time component generate adapter IDL IDL generate Real-time adapter Replicated components Distributed Component-based Software Common Object Environment Figure 4: Distributed Component Integration Process

5 automatic component wrapper generation from design patterns. Design patterns are organized in a design pattern repository, where patterns are represented using our design pattern representation. Components and their descriptions can be retrieved from a component repository. The component description includes component interfaces expressed in IDL and semantics of services provided by components, such as the component information described in [4,6]. make sure user requirements and application specific constraints are satisfied. How to select components based on user requirements is described in [9,10]. Some guidelines are given for pattern selection [11]. Eliciting and monitoring application specific constraints are described in [12,13]. The major steps of the process are given in [8]: Prepare design pattern instantiation information, which includes the association between design pattern elements and design Requirements & Application Specific Constraints Identify Components Select Design Patterns Prepare Design Pattern Instantiation Information Instantiate Patterns Software Design Verify Application Specific Constraints Verify Pattern Consistency Verify Design Generate Wrappers ok Not ok Test Requirements & Application Specific Constraints The component-based software development that adopts design patterns can be summarized in Figure 5. According to the user requirements and application specific constraints, components are identified and design patterns are selected to specify component interactions. Software design is obtained by instantiating design patterns based on the design pattern instantiation information. If the generated design is consistent with the selected design patterns and satisfies application specific constraints, component wrappers are automatically generated to produce application software. The application software is tested to Figure 5: CBSD Process Using Design Patterns elements, and relationships between selected design patterns. Design pattern elements refer to the constituents contained in a design pattern. Design elements include components, services provided by components, and events generated by components. Usually several patterns are applied in a software design and their relationship may have impact on the pattern application. Instantiate patterns. The design pattern instantiation information is used to convert the abstract solution in design patterns to part of a

6 specific software design. The resulting component-based software design consists of all the components used in the software, the static relationships among these components, and the dynamic interactions among them. Verify pattern consistency. Instantiated design patterns should be consistent with the original design patterns. The consistency includes the static structure consistency, dynamic behavior consistency, no violation of design pattern constraints, and satisfaction of component services with requirements of design pattern participants. Generate wrappers. Component wrappers act as decorator [7] of components. All the interactions among components are through wrappers. 5. Middleware In general, anything between the application software and the operating system can be called middleware. However, from the perspective of high-quality software development, most mainstream middleware implementations have the following goals:! To increase the degree of interoperability among software packages, which are distributed and are developed using different languages, operating systems, and hardware platforms.! To facilitate the interactions among distributed objects/components by elevating the programming abstraction and forcing a clear separation between interface and implementation. Based on the goals stated above, it is clear that middleware can be used as a supporting environment to facilitate high-quality software development. Specifically, the abstractions provided by the middleware allow the developer to focus on the actual application software development, rather than concentrating on system aspects to address the interoperability problems. Mainstream middleware specifications, such as CORBA [14] and COM [15], take this approach. While CORBA and COM can be generally used in any distributed enterprise-oriented software development, TINA-C [16] is specifically for telecommunication software. Moreover, recently published specifications, such as Real-time CORBA [17,18] extend the CORBA architecture in real-time application domain. Additional work is being done to address issues, such as QoS and reflective middleware [19] based on existing CORBA specifications. The fundamental assumptions adopted by mainstream middleware are that all computing devices are stationary and the underlying network is usually stable. However, distributed computing is increasingly more likely to involve the use of mobile ad hoc networks [MANET] [20], consisting of numerous mobile and embedded devices. This trend presents some new challenges in distributed software development:! Impromptu establishment of network connections: Network connections among embedded devices in an ad-hoc network tend to be more instantaneously established due to their mobility. For example, spatial-aware applications [21] instantaneously establish network connections based on the proximity of other devices (e.g. Bluetooth [22]).! Adaptation and Context-Awareness: Applications running on mobile devices often need to adapt themselves based on the context, which may be based on different factors, such as the location of the device, intensity and directions of signals from other wearable devices, or the Quality of Service (QoS) of the network, etc.! High-Density of Objects: Due to the increased use of networked embedded devices, the number of application objects along with these devices will exponentially increase.! Soft Real-time Requirements: The number of applications with real-time requirements will greatly increase as oppose to applications with hard real-time requirements.! Energy Constraints: Most wireless devices need to function with limited battery power. So,

7 effective utilization of power is an issue, which usually varies in application-specific fashion. In addition to the issues mentioned above, the following observations become obvious based on the trends of embedded systems development:! Improvements in Reconfigurable Hardware: Reconfigurable hardware units, such as Field Programmable Gate Arrays (FPGA) [23] can currently have up to 500,000 gates, which usually doubles in number in every 18 months. Due to the flexibility of reconfiguration, these units are useful for application-specific customization in communications, military, and intelligence applications that often reside in different embedded devices.! Use of Software in Traditionally Hardware- Only Domains: Recent research and industrial development activities in software radio [24], software-based DSP, etc. give an early indication of increased software usage in special-purpose embedded devices, which have traditionally been implemented in completely special-purpose hardware. It is clear that the distinction between software and hardware is continuously being redefined, and its potential impact could be easily seen in the current and future trends of mobile embedded devices. Hybrid Middleware [25] has been presented to address the issues raised above. A Hybrid Middleware is implemented in software and hardware, and combines the power of abstraction provided by mainstream middleware specifications (e.g. CORBA) with the flexibility of reconfigurable hardware to provide adaptive object services for the mobile embedded devices. Specifically, HM is a real-time middleware with the following characteristics: a. Interacts with the reconfigurable hardware of an embedded device to provide adaptive object services. b. Provides hybrid [software and hardwarebased] object services and facilities. c. Provides a context-based reflection and adaptation triggering mechanism suitable for embedded devices in MANET environments. d. Provides a programming abstraction and object interaction mechanisms to allow impromptu and context-aware object communication facilities. e. It could be used in conjunction with mainstream middleware, such as CORBA to allow seamless integration between desktop and Embedded Objects Sensors/ Antennas Hybrid Middeware Context- Reflector Hybrid Services Reconfigurator Aspect Components Other Services from Middleware (e.g. CORBA, COM) Reconfigurable Hardware [e.g. FPGA] RTOS and Other Hardware Components Figure 6: High-Level Architecture of Hybrid Middleware

8 embedded devices. Figure 6 shows a high-level architecture of Hybrid Middleware. The major components, as shown in the figure, are as follows:! Reconfigurator: This component is responsible for reconfiguration of the software and hardware objects. In addition, it translates high-level reconfiguration rules to gate-level logic customizing the reconfigurable hardware of the device.! Context-Reflector: This component manages the sensors and antennas associated with an embedded device, and continuously updates a model of the surrounding environment. It also triggers the necessary adaptation based on the changes in the environment and the previous state of the device.! Hybrid Services: This part represents a collection of interchangeable middleware services, such as encryption or signal processing. These services are used by the embedded objects through well-known interfaces.! Aspect Components: These components are specific implementations for providing nonfunctional services (e.g. exception handling) to the embedded objects. They are dynamically integrated during object activation. Hybrid Middleware provides a cellular-automata based environment-reflection service, which is used for querying the state of the surrounding environment. For example, results from a query may include the location and orientation of the device, intensity of the incoming signals, number of other devices in a specific range, etc. 6. Discussions In this paper, we have discussed three different ways to achieve quality software development of distributed environments. First, component-based software development represents a fundamental shift in the very nature of software development practice. It forces distributed software developers to analyze the problem at hand more conceptually and in coarse-grain level, where different automated techniques and methods can be applied to detect errors and inconsistencies early in the development cycle. In addition, the presence of well-developed components can significantly increase the productivity of the developers and the overall quality of the software. However, it is still remains to see the true potential of this approach, since there is no general consensus for developing high-quality components. Proper industry standardization in various domains and research in component design and development are needed to address this issue. Second, middleware represents the missing part between application software and the operating systems. By introducing a layer of abstraction and providing different object services, most mainstream middleware eases the problem of developing distributed software in distributed heterogeneous environments. In this paper, we have also presented Hybrid Middleware, which is focused on the next wave of distributed computing involving mobile and embedded devices. Middleware research is still in its infancy, and more fundamental research is needed to derive a set of appropriate middleware services for various application domains. Third, we discussed design patterns and its applications in component-based software development. Additional research issues include systematic methods for selecting design patterns and components based on the user requirements and application specific constraints. Despite these advances, high-quality distributed software development remains a very difficult problem. The actual process of creating dependable software need to be continuously improved. There is no silver bullet to achieve high quality software, rather a combinations of proven techniques, proper standardization, and the experiences from large and complex software development projects are needed to address this important issue. Acknowledgement: The author would like to thank Sheikh Iqbal Ahamed, Fariaz Karim and Guobin Pan for their valuable assistance in preparing this paper. References:

9 [1] S. S. Yau, X. Jia, and D.H. Bae, Trends in Software Design for Distributed computing Systems, Proc. Second IEEE Workshop on Future Trends of Distributed Computing Systems, 1990, pp [2] S. S. Yau and F. Karim, Integration of Object-Oriented Software Components for Distributed Application Software Development, Proc. 7 th IEEE Workshop on Future Trends of Distributed Computing Systems, December 1999, pp [3] S. S. Yau and F. Karim, Component Customization for Object-Oriented Real-time Distributed Software Development, Proc. 3 rd IEEE Int l Symp. on Object-Oriented Real-time Distributed Computing (ISORC 2K), pp [4] S. S. Yau and B. Xia, "An Approach to Distributed Component-based Real-time Application Software Development", Proc. 1st IEEE Int'l Symp. Object-oriented Real-time Distributed Computing (ISORC 98), April 1998, pp [5] G. Wang, et. al, Component Assembly for OO Distributed Systems, IEEE Computer, Vol. 32, No. 7, July 1999, pp [6] S. S. Yau and B. Xia, Object-Oriented Distributed Component Software Development Based on CORBA, Proc. 22 nd Int l Annual Computer Software and Applications Conf. (COMPSAC 98), August 1998, pp [7] E. Gamma, R. Helm, R. Johnson, and John Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software, Addison- Wesley Publishing Company, [8] S. S. Yau and N. Dong, Integration in Component-based Software Development Using Design Patterns, to be published in the Proc. of Proc. 24th Annual Int l Computer Software and Applications Conf. (COMPSAC 2K), October [9] C. Ncube and N. Maiden, PORE: Procurement-Oriented Requirements Engineering Method for the Component-Based System Engineering Development Paradigm, Proc Int l Workshop on Component-Based Software Engineering, pp [10] V. Tran and D. Liu, Component-based Development: Challenges and Lessons Learned, Proc. the 8 th Int l Workshop on Software Technology and Engineering Practice, STEP 97, pp [11] G. Odenthal and K. Guibeldey-Cirkel, Using Patterns for Design and Documentation, Proc. 11 th European Conf. on Object-Oriented Programming, 1997, pp [12] A. Gates and C. Kubo, "The Identification of Integrity Constraints in Requirements for Context Monitoring," Proc. the 1997 IEEE Int l Conf. and Workshop on Engineering of Computer Based Systems, Mar 1997, pp [13] A. Gates, and P. Teller, "DynaMICs: An Automated and Independent Software-Fault Detection Approach," Proc. Fourth IEEE Int l High Assurance Systems Engineering Symp., Washington, D.C., Nov 1999, pp [14] Object Management Group, The Common Object Request Broker: Architecture and Specification, Version 3.0, < [15] Microsoft Corporation, The Component Object Model Specification, < [16] TINA-C, Service Component Specification, Version 1.0b, < [17] Object Management Group, Real-time CORBA, Work in Progress, FTF 1.2, [18] D. Schmidt and F. Kuhns, An Overview of the Real-time CORBA Specification, To be published in IEEE Computer - Special Issue on Object-Oriented Real-time Distributed Computing, June [19] D. Schmidt et al, Towards a Reflective Middleware Framework for QoS-enabled CORBA Component Model Applications, Proc. Workshop on Reflective Middleware, April 2000,< rm2000/paper-list.htm>. [20] Internet Draft, Mobile Ad Hoc Networking (MANET), March 1998, [21] F. Hohl, Nexus An Open Global Infrastructure for Spatial-Aware Applications, Proc. 5 th ACM/IEEE Int l Conf. on Mobile Computing and Networking (MobiCom), August 1999, pp [22] Bluetooth, The Bluetooth Specification, 1.0b, 1999, <

10 [23] J. Rosenberg, FPGA-Based System Level Integration, Atmel Corporation, 1999, < [24] D. Tennenhouse et al, Towards the Software Realization of a GSM Base Station, Proc. IEEE/JSAC, Special Issue on Software Radios, Vol. 17, No. 4, pp , April, [25] S. S. Yau and F. Karim, Hybrid Middleware for Embedded Devices in Wireless Mobile Ad-Hoc Networks, 1st OMG Workshop on Real-time and Embedded Distributed Object Computing, July 24-27, 2000, < dex.htm>.