Summary
In the paper the proposal of customization of RUP methodology for service-oriented programming is introduced. The proposed extensions embrace three lifecy-cle phases and an additional core process workflow, and some core supporting workflows necessary for adopting RUP for the usage in services environments. In the paper the concept Web 2.0 is also taken into consideration. Some of the aspects of services modeling are also discussed.
Keywords: service-orientation, software development for e-business, Web 2.0, SOA 1. Introduction
The globalization of business enabled through the Web presence [6] contributes to the pres-sure on the contemporary enterprises to deliver their goods by minimizing the time-to-market, while keeping possibly low costs and stay adaptable in order to customize their products and ser-vices to changing customer needs. The organizations use the business process modeling languages like the standardized UML [1], which are applied to precisely model the business processes. The schema languages are needed in order to model the business information exchanged in e-business messaging on the basis on XML. Also a standardized methodology for the organization of the e-business activities [6] in the software project is needed.
Current accepted object-oriented software development process models are no longer like the waterfall model, but are more spiral, and iterative-incremental process based models. A prominent example of such a process is The Unified Software Development Process UP originated in the best practices of OMT, method of G. Booch and I. Jacobson’s Objectory [8]. The Unified Process can be considered as de facto standard, UML-based, object-oriented software engineering process. The industrial variant of UP is the Rational Unified Process RUP [3,4], a process product [2]. More-over, RUP has a process framework that can be adapted and extended to suit the needs of the or-ganization.
In the paper a proposal of the extensions for the Rational Unified Process for service-oriented software development in e-business is topic of section 3, where the needed additional lifecycle phases and workflows for the RUP for services are introduced. In section 4 the work is concluded. 2. Basic concepts
I. Sommerville defines [9] a service as “an act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production”.
The provision of a service is according to this definition independent of the application using the service; therefore there are different stakeholders involved in a provisioning of a service, such as the end-users, the facilitators, the service providers, an aggregator and an element provider [7].
Fig. 1. The RUP Process- Phases and Workflows
The idea of Service-Oriented Architecture SOA based around the notion of externally pro-vided services and service-oriented computing [6] supports the connection of the systems in the novel way.
The UP process is organized within two dimensions: the time and process components. In the time dimension (horizontal) there are four main phases:
• Inception, • Elaboration, • Construction, • Transition.
Each of them consists of a sequence of iterations separated by the milestones. The process components, i.e. “Core Workflows” on the vertical axis, are analogous to the steps in the classical waterfall-based development approaches. The “workflows” which are organizing the activities, produced “artifacts” and “workers” are the key notions in the description of the process. In new RUP versions the “workflows” are referred to as the “disciplines” [3,4].
RUP is an industrial variant of the Unified Process that has comprehensive tool support for the development process. It also contains in the “Core Supporting Workflows” (see Figure 1) the means for the configuration and change management, which were lacking in the origin UP. RUP is based on the “best practices” for the object-oriented software development, has a comprehensive tool support and may be regarded as an industrial quasi-standard. Nevertheless, it is clear that such
Organization along Time
Organization along Content Core Process Workflows Phases
Inception Elaboration Construction Transition
Business Modeling Requirements Analysis and Design Implementation Test Deployment Core Supporting Workflows Configuration and Change Management Project Management Environment Prelim inary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m +1
typical object-oriented processes as RUP designated for a development of one system at a time, bear some significant shortcomings if applied for the software development for the services. The operation of the products containing a service is not regarded. What is more, the support for multi-projects is missing in RUP. The evolution of a service and the resulting feedback are not included in the process. Nevertheless, the changes caused by the evolution lead to new versions of the reuse infrastructure. The last phase (not included in RUP) should be the decommissioning of the service. In this phase a new and fully independent service may replace the former one, or it is taken out of service after the end of its useful operational lifetime.
3. Extensions for the Rational Unified Process for Service-Oriented Software Development The proposed extensions comprise three new lifecycle phases, a new process workflow and a new supporting workflow. The new proposed lifecycle phases are:
• Operation, • Evolution, • Decommissioning.
Fig. 2. Suggested Extensions for Services to the RUP Process Structure
The new core process workflow is: • Maintenance and Support. The new core supporting workflow is:
• Process and Organization Management.
According to the principles of Web 2.0 [5] the lifecycle of the service is continuous. Its life cycle is not restricted to the moment of the product deployment, as it was proposed in the RUP process. As long as a service operates, the products containing it will be maintained and the
feed-O rg a n iza tio n a lo n g T im e O rg an iza tio n a lo n g C o n ten t C o re P ro c e s s W o rk flo w s P h a s e s
In c e p tio n E la b o ra tio n C o n stru c tio n T ran s itio n
B u s in es s M o d e lin g R e q u ire m e n ts A n a lys is a n d D e s ig n Im p lem e n ta tio n T e st D ep lo ym e n t P r elim in a ry Ite r a tio n (s ) Ite r. # 1 Ite r . # 2 Ite r . # n Ite r. # n + 1 Ite r. # n + 2 Iter . # m Ite r . # m + 1 C o re S u p p o rtin g W o rk flo w s C o n fig u ra tio n a n d C h a n g e M a n a g e m en t P ro je c t M a n a g e m e n t E n v iro n m e n t M a in ten an ce an d S u p p o rt P ro ce s s a n d O rg a n iz atio n M a n a g e m en t O p e ra tio n
back causes the evolution. Thus see in Figure 2 the proposed “Operation” phase for each service and the additional “Maintenance and Support” process workflow. Accordingly, the “Evolution” and “Decommissioning” are new phases, which are desirable within the life-cycle phases of the service.
Moreover, in the “Core Supporting Workflows” an additional step needed is the management of the whole reuse infrastructure. It is necessary to enable the large-scale reuse opportunities in a service-oriented software development.
The proposed extensions to the overall RUP architecture are graphically depicted in Figure 2. Firstly, these apply to the part of the diagram that represents the process organization along time. In addition to the four former RUP process phases there is a supplementary fifth process phase named the “Operation”. It has been incorporated and is shown graphically on the horizontal axis. Secondly, there are two workflows supplementing the hitherto existing process workflows in the organization along the content of the RUP process. In particular, there is the further core process workflow referred to as the “Maintenance and Support” and also the additional core supporting workflow, the so-called “Process and Organization Management” workflow. These three exten-sions to the RUP process structure are marked in the diagram in Figure 2 by underlined font.
The two remaining supplementary process phases needed for service development, are the “Evolution” and the “Decommissioning”. These are not graphically depicted in Figure 2. It is caused by the fact that their presence is justified in a system engineering process covered in the case of the product family development [8] but in the case of service-oriented software develop-ment, these are not the strict parts of the software development process. Nevertheless, these in-volve some important technical management issues in a system engineering process.
During the Evolution phase the needed extensions of the service scope and the technical man-agement efforts for the integration of the changes are made. The activities encompassing the needed evolutionary efforts within the system services context are mainly concentrated in the Process and Organization Management core supporting workflow. The efforts needed for main-taining the organizational standards and guidelines and also the organization wide core models, which evolve in the service development, are carried out in this phase. Therefore these efforts may also be enclosed in the Process and Organization Management workflow without a need for denot-ing it as an extra process phase. They are represented as the last item of the core supportdenot-ing work-flows in the RUP process organization along the content and graphically depicted in Figure 2. These activities take place continuously during all phases of the development process of the ser-vice.
In the Decommissioning phase the considerations of the possible substitution of the existing service with an entirely new one, or with the specialization of the existing service etc. are made. As a result of this phase, the service is retired after the end of its operational lifetime.
The service-oriented development process may generally be viewed as a multidimensional version of the development process for one system at a time. The first dimension includes the domain engineering stage which denotes the development of core assets for the services. The sec-ond dimension is the stage with the development of the instances of a service. These two are ac-companied by the third dimension which is the management of the both evolving stages. Nonethe-less, as mentioned above, the technical and organizational infrastructure management is not strictly a separate phase of the product family development process. Therefore its activities are comprised in the Process and Organization Management core supporting workflow and partially in the Main-tenance and Support core process workflow. The mainMain-tenance and support efforts provide
feed-back that is inevitable for the evolution. It is especially important in the services context. The preparation and the prearrangement of the support of the stakeholders with artifacts such as the manuals, teaching materials, test cases etc. starts in the early software development phases (see Figure 2).
The software development of one system at a time with the Rational Unified Process is a use-case driven approach. In the service-orientation context, the analysis models in conjunction with the use-cases constitute the foundation for the remainder of the whole software development proc-ess accomplished in the procproc-ess workflows, such as design, test, and the management efforts. The application of the reverse engineering techniques may prove very useful in the case of the neces-sity of the integrating legacy systems into the core assets base.
The iterative approach recommended by the Rational Unified Process facilitates the gradual refinement of the models. Consequently, it supports the incremental introduction of the extensions to the core assets stored in the repository and to the service-specific assets. At the beginning of the development the assets will contain the common parts along with some built-in variable parts inclosing the default values that have been preset for the variants. Thus the basic RUP models require to be supplemented by the adequate models representing the commonality and variability in the service assets.
Furthermore, in comparison to one-of-the-kind system development with RUP, there are some slight changes in the responsibilities of the activities in the core process workflows and the core supporting workflows for the service-oriented development. These are described below.
In addition to those mentioned, there are some further differences between service-oriented de-velopment and a dede-velopment of one system at a time with the Rational Unified Process. First of all, during the first iteration of the inception phase the decisions concerning the viability of the service are to be made and the scoping activities are carried out. Then the initial models are devel-oped in order to determine the size, functionality and also the commonality and variability of the service. In the inception phase the core assets such as the core use-cases, and the other models are gradually developed. In this phase the use cases constitute the major reference models for the ser-vices. Moreover, the relationships between the technical side of the service and the needed re-sources should be established [7]. The requirement engineering should additionally take into ac-count such activities like determining of the quality of service QoS according to the Service Level Agreements SLA [6].
After the Inception phase in the following elaboration phase the use-case models and the other models represent the central development artifacts. Secondly, based on the earlier iterations and the patterns which have been analyzed, the kernel of the core assets for services is developed. Beginning with the core optional parts and variant parts, the initial models are gradually extended in the following iterations to include the needed options and variants. If needed, any supplemen-tary variants of the assets may then be implemented in the next stage. The most important artifact in the elaboration phase constitutes the service family reference architecture. In this phase the usage of the open standards facilitates the availability of the service for the wide scope of users.
Then in the Construction phase the core components are designed, implemented and tested. After that, in the following transition phase the integration and functional testing of a core system with core components and any default components is performed. In the construction phase, at first, only a subset of the components that are needed for the service platform is selected. Next in the following iterations the options and the variants can incrementally be added. The same pertains to the testing of the components which constitute the core system. Primarily the core components of
the platform are tested, then its default optional and variant parts. During the Transition phase the core executable release of a service is transferred for testing to the stakeholder. The usage of the system during the transition and operation phases provides feedback which can be used to tune the basic service models.
Finally, following the Transition phase the reuse infrastructure is prepared for the Operation of the service. Furthermore, the process and organization management and the projects manage-ment activities are carried out. All those are denoted as the process workflows with the according names. Some additional activities are needed for the configuration of the service. The registration of the service in an appropriate registry enables the users (or their brokers) to discover and find an appropriate service and then bind to it [PR06].
4. Concluding remarks
The UP is just an exceedingly feature-rich method which is both: a strength and a weakness of it. The RUP product includes several thousand pages of definitions, guidance and templates. Most of the modern software engineering concepts like incorporating UML as the modeling language, use of use-cases, patterns, components and architectures are integrated into it. The problem is that they are not integrated in the orthogonal way, i.e. RUP is simultaneously “architecture-centric” and “use-case-driven”. Nevertheless, in the case of the service-oriented development that may be regarded as advantageous. Even though the fact that the mentioned drawbacks and the underlying waterfall-based phases dominate the organization of the RUP process, there are groups within many leading companies which are still adopting it.
Therefore, after some extensions the RUP process could be adopted for the needs of the ser-vice-oriented software development for e-business.
Bibliography
1. Grady Booch, James Rumbaugh, Ivar Jacobson (2001): UML – przewodnik uĪyt-kownika; Warszawa: WNT 2001.
2. IBM online: http://www-306.ibm.com/software/rational; accessed 1.05.2007. 3. Per Kroll, Philippe Kruchten (2007): Rational Unified Process od strony praktycznej;
Warszawa: WNT 2007;
4. Philippe Kruchten: Rational Unified Process od strony teoretycznej; Warszawa: WNT 2007
5. Tom O’Reilly; What is the Web 2.0. http://www.oreillynet.com /pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html; accessed 1.05.2007. 6. Michael Papazoglou, P.M.A Riebes (2006): e-Business: Organizational and
Techni-cal Foundations; Chichester, John Wiley & Sons Ltd.
7. S. Robak, B. Franczyk(2006) : Problemy tworzenia oprogramowania dla usług. Studia i Materiały Polskiego Stowarzyszenia Zarządzania Wiedzą. 2006, nr 7, p. 156-161.
8. Silva Robak (2006): Contribution to the improvement of the software development process for product families. Monografia. Zielona Góra: Uniwersytet Zielonogórski, 2006. ISBN: 83-7481-064-5.
Silva Robak
Zakład ZastosowaĔ Informatyki Uniwersytet Zielonogórski
Wydział Matematyki, Informatyki i Ekonometrii Ul. prof. Z. Szafrana 4a, 65-516 Zielona Góra e-mail: s.robak@wmie.uz.zgora.pl
