integrates business and software engineering aspects, describes the specific ... business objects operating as cooperative application components in a ...
’98
BOOSTER*Process A Software Development Process Model Integrating Business Object Technology and UML A. Korthaus, S. Kuhlins Universität Mannheim Lehrstuhl für Wirtschaftsinformatik III, Schloß, D-68131 Mannheim Phone: +49 621 292 5075 Fax: +49 621 292 5701 Email: {korthaus|kuhlins}@wifo.uni-mannheim.de
Abstract
The UML is a multipurpose modeling language which should be applied following clearly defined processes aimed at achieving particular goals. Business object technology is an emerging paradigm for business and software engineering with the promise of a high level of reuse and a considerable simplification of software development. In order to use UML in systems development based on business object technology, a process has to be defined which integrates business and software engineering aspects, describes the specific modeling activities, and connects the various UML diagrams. This paper describes a new process model (called BOOSTER*Process) for this purpose, particularly taking into consideration the requirements of business objects and their component character. It propagates a multilevel approach, starting with use case, activity and class modeling at the organizational level, and then shifting to analysis and design of business applications. The process particularly describes ways of using UML features such as packages, interfaces, patterns etc. to foster the assembly of models and applications from existing business object components. Keywords Business Object Technology, Process Model, Unified Modeling Language
1 Promises of UML and Business Object Technology Large enterprises acting in globalized, highly competitive markets depend strongly on information systems to support their business activities. Furthermore, enterprises are constantly forced to adapt their organizations and processes and hence their supporting software systems to changes in environment, competition, technology etc. New trends such as virtual organizations, decentralization, team orientation, electronic commerce etc. require distributed enterprise information systems which can be built and modified very quickly, cause only little expenses, and realize high quality standards. As a consequence of these conditions, progress in the field of software engineering technologies is needed badly in order to overcome the lasting software crisis and to meet the increasing requirements. The paradigm of object-orientation, which has eventually become the mainstream in industry today, is one of the technologies that have improved the process of software development significantly, although recent years have shown that some expectations, in particular with respect to software reuse, were illusory. Nevertheless, object technology has brought numerous benefits, as for example a better abstraction and representation of real world concepts, a seamless use of the same concepts throughout the whole software lifecycle, increased software maintainability etc. Upcoming standards (see below) in the field of object technology, mainly advanced by the Object Management Group (OMG), contribute further to the growing success of object-oriented approaches. As a successor of object-oriented ideas, new component technologies start to emerge rapidly. They build upon the most successful concepts of object-orientation, but go further, e.g. by defining larger-grained units of reuse compared with conventional objects in object technology. These component technologies, e.g. OCX/ActiveX (Microsoft 1998) or (Enterprise) Java Beans (Sun 1998), are no longer limited to the field of GUI components, but begin focusing on the implementation of business concepts and business logic. One of the most interesting developments in this area is OMG’s standardization effort for so-called Common Business Objects (CBOs) and a Business Object Facility (BOF) (OMG 1996). While CBOs are “objects representing those business semantics that can be shown to be common
-1-
’98 across most businesses”, the BOF is “the infrastructure (application architecture, services, etc.) required to support business objects operating as cooperative application components in a distributed object environment.” (OMG 1996). According to the CBO Working Group of the OMG BODTF (Business Object Domain Task Force), business objects capture “information about a real world’s (business) concept, operations on that concept, constraints on those operations, and relationships between that concept and other business concepts. [...] a business application can be specified in terms of interactions among a configuration of implemented business objects.” (OMG 1997a) This definition reflects the object-oriented foundation of business object technology. The vision of CBOs as both designtime and run-time constructs comprises, above all, the goals of interoperability of business object components, including the possibility of ad-hoc integration (i.e. “plug-and-play”), and simplicity of design, implementation, configuration and deployment, so that an average developer is enabled to build business object systems easily (OMG 1996, Sims 1994). The CBO vision aims at a marketplace for standardized “off-the-shelf” business objects which are easily integrated with other business objects through the BOF and are able to interact with each other in order to perform some business function, even if the collaboration was not planned or foreseen by their developers (in the context of ad-hocintegration see also: Corba Component Initiative (OMG 1997b)). The eventual achievement of these goals would bring software engineering a big step closer to meeting the extensive requirements on modern information systems development mentioned earlier. Since the OMG currently is in the process of adopting the Business Object Component Architecture (BOCA) Meta-Model proposal (CBOF 1998a), which includes a specification language (CDL) for OMG business objects, and an Interoperability Specification proposal (CBOF 1998b), progress in this area can be expected very soon. To be more specific about the term business object, two areas of application have to be distinguished (OMG 1997a, cf. Korthaus 1997): • The term modeling business object designates the use of business objects in business models to capture business concepts and express an abstract view of the business; • The term systems business object reflects the realization of business concepts (represented by modeling business objects) in software. This term is used in the context of software system design or program code. Furthermore, a taxonomy of entity business objects (e.g. product, order), process business objects (e.g. order fulfillment, procurement), and event business objects (e.g. account overdrawn, end of fiscal year) has been established to organize different kinds of business objects. For the purpose of modeling business and software systems with business objects, a suitable object-oriented analysis and design (OOA&D) method is needed (Korthaus 1998). Object-oriented modeling is another area where the OMG has seeked standardization and has been successful recently through the adoption of the Unified Modeling Language (UML) in Nov. 1997 (OMG 1997c-h). UML stands at the top of a historical evolution of OOA&D methods. As the usefulness of systematic object-oriented analysis and design was broadly recognized in the beginning 1990s, a considerable number of OOA&D methods came into being, which were largely based on the same concepts, but used different notations and processes. The variety of OO methods was an impediment to a free exchange of modeling knowledge and caused unnecessary learning curves for software engineers and other people involved in software development. With OMG’s adoption of UML 1.1 as the official industry standard for object-oriented analysis and design languages, these problems have been overcome, at least partially. UML combines common concepts of earlier analysis and design methods, enhances this set with new modeling concepts meeting the requirements of current modeling tasks, and defines standard notational symbols for those concepts. As a general purpose language, UML is designed to model a wide range of different types of systems, from purely technical (non-software) through software to business systems. In contrast to many of its predecessors, UML is merely a modeling language, not a complete methodology, because there is no specification of a particular software development process included in the standard. A modeling language, specifying modeling elements, their associated semantics, and their syntactical correct application, can be seen as a kind of tool which is rather worthless without a defined way how to deal with it. Since the structure of a process for modeling systems with UML is strongly dependent on the kind of system under development (e.g. business/software/technical system) as well as on other determinants (e.g. project size), no process description has been included in the standard. Process definitions have to state which techniques are appropriate at various levels of detail during development, which deliverables have to be produced, who should produce them, and which inspections, standards, metrics, and tests should be used to control quality and certify system correctness (Allen and -2-
’98 Frost 1998, Jacobson et al. 1997). In order to use UML for systems development based on the business object paradigm, a process has to be defined which spans the whole range from business engineering (using modeling business objects) to application engineering (with an emphasis on reusing pre-built systems business objects in the form of software components) and business object component engineering (in order to build new business objects). In this paper, we will describe the basics of a process model for this purpose. The ideas presented in this paper will be elaborated in a project called BOOSTER, which has just been launched at the University of Mannheim. BOOSTER is an acronym for “Business Object Oriented Software Technology for Enterprise Reengineering”. BOOSTER will examine topics around object-oriented business and software engineering, OMG business object and infrastructure standards, architecture, analysis, design, and implementation of distributed business object systems, component technologies (e.g. Enterprise Java Beans (Sun 1998)), web object models, business object frameworks (e.g. IBM San Francisco (IBM 1998)) etc. BOOSTER*Process is a part of the project which will provide a description of an UML-based system development process integrating business engineering aspects and software engineering based on OMG business object technology.
3 Multileveled UML-Based Business Systems Development According to Eriksson and Penker (1998) and Jayaratna (1994), processes must be viewed from four aspects: process context, process user, process steps, and process evaluation. The process context describes the problem domains, in which the process is applicable. Since no generic process can be defined that handles all potential problems, the definition of the process context is important in order to uncover the underlying assumptions of the process model. BOOSTER*Process is aimed at object-oriented modeling of organizations, business processes, and business information systems of a certain size, involving a number of different stakeholders such as customers, end users, software developers etc., based on OMG business object technology. Process users must be identified and given guidelines for how the process should be adopted and used. BOOSTER*Process primarily involves customers, end users, business engineers, and software engineers. The backgrounds of these different stakeholders have to be considered explicitly within the process guidelines. Process evaluation issues specify how to evaluate the results of the process, such as documents, products, experience etc. Metrics are a key technique in this context. In the following subsections, we will concentrate on the foundations and basic principles of BOOSTER*Process as well as on the process steps, which describe the activities to be taken and the UML techniques to be applied during the process. Although UML does not include a specific process, its designers had certain basic process principles in mind which are derived from the most popular existing methodologies – above all Booch (1994), OMT (Rumbaugh 1991), and OOSE/Objectory (Jacobson et al. 1992), the direct predecessors of UML. The UML documentation (OMG 1997c-h) mentions that processes using UML should be use-case-driven, architecture-centric, iterative, and incremental. These are important principles of object-oriented development, and they are especially significant in business object system development. Iterative and incremental development means that UML models should be developed in a sequence of steps, adding new information during each iteration. An iteration should be concluded by an evaluation of the results, thus providing continuous feedback. Typically, parts of the system that are most important, carry the highest level of risk, or have the highest impact on the system architecture are built in earlier iterations, whereas less important details are postponed, so that the overall risk of the project is reduced. As a result of the iterative process, the system is delivered in increments or versions. Iterative, incremental development contrasts strongly with early software engineering process models such as the waterfall model (Boehm 1976), which prescribed a purely sequential and singular performance of the development phases analysis, design, implementation, and test. The next basic principle to be followed is the idea of a use-case-driven development which traces back to the OOSE methodology of Jacobson et al. (1992). As a concept to capture the functional requirements of software systems or the business processes of an enterprise, use cases represent the starting point of systems development, serve to validate, verify, and test the system functionality, and provide an important basis for project management. The last principle mentioned above refers to the need of a good system architecture, since it is very important to define a system that can be modified easily, that can be understood intuitively, and that enables reuse. UML provides a lot of modeling elements, such as packages, components, interfaces, and a pattern notation, that aid in architectural design. BOOSTER*Process sticks to these basic principles, although the concept of use cases is not over-emphasized. The most important foundation of BOOSTER*Process is a multilevel approach to business object system development, which is represented by a process architecture. This multilevel process architecture defines a
-3-
’98 framework for the activities which have to be performed. The macro process constituted by the architecture levels of BOOSTER*Process is broken down into micro processes, which roughly reflect the well-known activities of requirements gathering, object-oriented analysis, design, implementation, and test. The process architecture of BOOSTER*Process is shown in Figure 1. As can be seen from the figure, the levels business engineering, system architecture engineering, application engineering, and business object component engineering are distinguished. The different kinds of arrows indicate more or less significant directions of information flow and express the principle of iterations and increments, which can be found even in the macro process depicted in Figure 1. On the right side, those UML diagrams are listed that are most important for the respective engineering activity/activities. B O O ST ER *Process Architecture Business Engineering
Central UM L Diagram s U se Case D iagram s, Activity D iagram s, Class/Collaboration D iagram s
Com ponent D iagram s, D eploym ent D iagram s, Class D iagram s
System Architecture Engineering
Application Engineering
Business Object Com ponent Engineering
U se Case D iagram s, Class/O bject D iagram s, State D iagram s, Sequence D iagram s, Collaboration D iagram s, Com ponent D iagram s, D eploym ent D iagram s
Figure 1: Process Architecture of BOOSTER*Process While business engineering and software engineering activities have different viewpoints and different levels of abstraction, they are not independent of each other. Modeling business goals and processes is the basis for deriving requirements on the information systems needed to support the business. New information system technologies, on the other hand, influence the way how the business processes are to be shaped to provide the best customer value. Therefore, it is very important to integrate these different viewpoints within a comprehensive process, using the same underlying technologies, i.e. UML modeling and business object concepts. The significance of an integrated approach is also emphasized by a number of authors in literature (see e.g. Taylor’s (1995) ideas of “convergent engineering”). System architecture engineering serves for designing a stable system architecture as a basis for the development of a number of related applications. Fortunately, a basic system architecture for OMG business object systems is already part of the submissions to the BOF RFP (OMG 1996) (see subsection 3.2). This basic layered architecture has to be refined by company-specific enhancements. Application engineering and business object component engineering need not always be part of a system development together. Application engineering is an activity resulting in a new software application for the organization. One of the central aspects in application engineering is the reuse of pre-existing business objects, at the modeling level as well as at the software component level. If the application can be built up completely with existing business object components and only some glue code is needed, no business object component engineering process will take place. The latter is the process of designing and implementing new business object components for reuse. This activity may be independent of a concrete application engineering process. Similar distinctions between these two kinds of processes can be found in several approaches: Allen and Frost (1998), for example, distinguish between solution projects and component projects, while Jacobson et al. (1997) speak of application system engineering and component system engineering. The normal course of activities begins with a business engineering process as the starting point, followed by a system architecture engineering process. When the system architecture is defined, several application engineering processes will be performed, concurrently with several business object component engineering processes, which are a result of
-4-
’98 the requirements generated by the application engineering processes, or which independently produce components for future needs, in the sense of a domain engineering activity. In the following subsections, the individual levels of BOOSTER*Process are described in detail.
3.1 Business Engineering A key characteristic of BOOSTER*Process is that it starts at the enterprise level with a business (re-)engineering activity. Hammer and Champy (1994), who have popularized the concept of Business Process Reengineering (BPR), claim that the entire operation of a business, viewed as a number of business processes which provide value to the customers, should be fundamentally rethought and radically redesigned from time to time to achieve dramatic improvements in cost, quality, service, speed, and other measures of performance. Although the radical reengineering approach has been weakened over time because of a considerable number of BPR project failures, the focusing on and optimization of business processes stays to be the best practice for reaching competitive advantages for an enterprise. Part of a successful business (re-)engineering activity is the modeling of the business with its goals, rules, resources, actions, workflows etc. UML provides a number of diagrams which are very useful for this purpose, namely use case diagrams, class diagrams, and activity diagrams (for a detailed discussion see Korthaus 1998). Jacobson et al. (1995) describe a well-defined process for object-oriented business engineering, which nearly exclusively builds on the use of use cases for modeling business processes. BOOSTER*Process takes up those ideas, but supplements the use case models with activity diagrams and high-level class models. The basic steps in business engineering take pattern from those described by Jacobson et al. (1997), but are adapted to the needs of BOOSTER*Process: • Formulate a business vision: Define the rationale and the goals of the BPR activity, discuss it with managers and employees, consider new technologies which might be helpful to improve the business, formulate objectives and high-level descriptions of future business processes. • Reverse engineer the existing business: Build use case models, class models, and activity models of the existing business structures and processes to be improved in order to facilitate a detailed problem identification and analysis. Transform perceived business concepts into suitable modeling business objects, i.e. entity, process, and event business objects. • Forward engineer and implement the new business: Produce a detailed description of the new processes and the internal organization of the business in the form of new versions of the use case, class, and activity models. Identify suitable business objects and map them to standardized Common Business Objects and existing domain specific business objects as early as possible in the process. Identify areas of operation which can be supported by business information systems. Implement the new business incrementally and develop the associated software systems. In the context of business engineering, use cases appear as business use cases. Business use cases model sequences of work steps performed in a business system which produce a result of perceived and measurable value to business actors. Business actors are roles that people or external systems in the environment play in relation to the business. The business use cases, which model business processes, should be detailed with the help of high-level class and collaboration models, expressing the internal realization of the business processes by workers with appropriate competencies and a number of business objects the workers work with. In order to express these elements unmistakably and to facilitate the distinction between UML models at different abstraction levels and with different viewpoints, in BOOSTER*Process UML will be adjusted for business engineering activities appropriately by making use of suitable enhancement techniques such as stereotypes, tagged values, and constraints. An example for such an adjustment is the Extension for Business Modeling specification (OMG 1997d) which is part of the UML documents may be used. However, to be able to represent the business objects taxonomy mentioned earlier, we recommend to define new stereotypes appropriate for this purpose. All models produced during business engineering should be arranged in a top-level package labeled with the stereotype . The realization of use cases should not only be modeled by class and collaboration diagrams, but also by activity diagrams, which are very suitable for expressing workflows and parallel activities. Activity diagrams are similar to conventional approaches for modeling business processes (e.g. Event Driven Process Chains, see Nüttgens 1998), thus making the use of additional modeling techniques apart from UML superfluous. Like use cases, activity diagrams are not object-oriented in nature, and thus render the mapping to object-oriented concepts more difficult. Activity diagrams can help identify activities in the business processes that can be executed or supported by
-5-
’98 information systems. This is where the transition to application engineering takes place. A rule of thumb regarding the mapping from the business models to models of the information systems could be that each business use case, described by an activity diagram, might be supported by and mapped to several information system use cases. Some of the internal workers identified and even some of the business actors might become actors in the information system use cases. Information system use cases might correspond with process business objects, and some of the business objects identified in the high-level class models might be represented by entity business object packages in the information system models. To enable the extensive reuse of existing business object components, the recourse to those components must be considered as early in the system life cycle as possible. Therefore, existing business object specifications must be matched with the business concepts identified in the respective development process. It will be absolutely necessary to standardize the techniques for documentation and specification of business object components. The BOCA submission (CBOF 1998a) to the CBO/BOF RFP (OMG 1996) represents the first step in this direction, because it comprises a Component Definition Language (CDL), which is designed to rigorously specify systems business objects. Common Business Objects (CBOs), which are being submitted for standardization, yet have to be specified in CDL. For convenience and to be able to express more of the semantics, CDL specifications should be supplemented by suitable UML diagrams describing interfaces, structure, and behavior of the business object components. While the standardization of a business object specification technique is a basic requirement, the standardization of CBOs has the additional advantage that even business terminology and semantics are clearly defined, too. Using these standardized semantics and integrating the UML diagrams associated with existing business objects with the models of the system under development, it should be possible to begin reuse activities already at the business engineering level. The earlier the mapping to existing business object components can happen, the better are chances of quick information systems implementation through assembly of existing software components. Thus, business modeling activities should be performed with strict adherence to standardized CBO terminology and semantics where possible.
3.2 System Architecture Engineering The intrinsic complexity of modern large-scale information systems can be managed best with a good software architecture, which, for example, enables parallel development activities. The goal of architectural modeling is to define a robust framework within which applications and subsystems such as business object components may be developed. The system architecture provides the context for defining how applications and business object components interact with one another to perform the needed business functions. As a common base from which all project teams work, a good architecture increases the reusability on system development projects. Enterprise Specific Business Objects Financial Business Objects
Manufacturing Business Objects
Other Business Objects
Common Business Objects Business Object Facility CORBA, CORBAservices, CORBAfacilities Figure 2: Architecture for Business Objects (OMG 1996) For applications built from business object components, the basic architecture required will be part of the OMG standard. Figure 2 shows the proposed architecture for business objects. Integrated in OMG’s Object Management Architecture (OMA), which includes a reference model for distributed object computing and defines OMG’s objectives and terminology, the Business Object Facility (BOF), based on CORBA, provides the infrastructure for CBOs, domain specific business objects, and enterprise specific business objects. This is the basic layered -6-
’98 architecture which all business object systems will be based on. The software is organized in layers according to this layered architecture. Objects and components in lower levels are more general than those in higher levels and encapsulate technical details about transactions, persistence etc. the developer and user of higher-level components does not want to be concerned with. The application engineering process uses the different kinds of business objects to assemble them into software applications. The business object component engineering process produces business objects fitting the architecture of Figure 2. The generic architecture for business objects must be enhanced by an enterprise-specific, change-tolerant application systems architecture, which defines subsystems (using UML packages and components) and defines clear interfaces to reduce communication overhead and to allow graceful system evolution over time. It should be decided which parts of the system are most stable and which will change frequently in order to come to a good subsystem organization. UML provides sufficient modeling capabilities to cleary distinguish between the logical and the physical architecture of the system. While the logical architecture is expressed in the form of class diagrams, for the most part containing only packages, interfaces, and dependency relationships, the physical architecture is modeled by component and deployment diagrams, as can be seen from Figure 1. UML packages on the logical level and components on the physical level are very important during architectural modeling, because they allow the partitioning and control of the overall software structure. At the logical level, both legacy systems that shall be retained and must be wrapped to fit into the architecture as well as large-grained business objects identified during business modeling are modeled as packages. Clear interfaces between these packages have to be defined, so that the packages can be allocated to different teams. Apart from class and component diagrams, deployment diagrams can be useful to structure the physical architecture and start considering the run-time distribution of the components already known. The iterative and incremental micro process of system architecture engineering comprises the following activities: • Capturing requirements: Using the results of business engineering as input and doing further research (e.g. interviews etc.), the global needs and expectations of the (internal) customers and end users must be gathered and modeled with the help of use case diagrams; furthermore, non-functional requirements have to be analyzed in terms of an overall quality plan; • Perform global analysis: Through examination of the requirements, candidate applications and business object components should be identified and modeled as packages. Domain analysis activities as well as feedback from previous application engineering projects about needs for reusable business object components can contribute to the results; • Architectural design: As much as possible of the overall architecture should be specified on a design level now. This includes the precise definition of facades (see subsection 3.4) and interfaces of the applications and business object components to be developed, the legacy systems to be integrated, and the technology components for lower system levels (e.g. ORBs, BOF). For this purpose, it might be necessary to begin a more detailed behavioral modeling involving the use of UML interaction diagrams (not mentioned in Figure 1). • Implementation and test of the layered architecture: At this point the packages identified have to be implemented (if not existent), which involves application engineering and business object component engineering. Finally, the system functionality has to be tested on a global level. In analogy to the business engineering level, a very important task at this level is the adjustment of UML for software engineering based on business object technology. This means that a suitable version of UML has to be defined to meet the given needs. Provided that the BOCA proposal (CBOF 1998a) will become the OMG standard, business object systems will have to be specified in CDL (similar to IDL specifications of CORBA objects). The BOCA metamodel thus becomes a design target for the UML models, so that an appropriate UML variant must be defined to facilitate the mapping between UML and CDL.
3.3 Application Engineering Application engineering is the process during which single business applications are implemented that directly serve the business by supporting the business processes. These business applications are the end product with which employees in the organization and possibly even business partners (e.g. in electronic commerce) do their work. It has been mentioned before that the vision of OMG business objects comprises a considerable simplification of developing business information systems. Therefore, the goals of application engineering in BOOSTER*Process are to
-7-
’98 develop solutions quickly, but on a sound, evolving architectural base, thus producing applications that confer early user benefits at minimum costs and leverage existing legacy systems where possible, while maintainability is retained. These goals are sometimes subsumed under the term Rapid Architectural Application Development (RAAD), as opposed to Rapid Application Development (RAD), where no models are produced and no system architecture is designed (Allen and Frost 1998). Application engineering is very much like conventional software engineering approaches described in literature, extended by aspects of reusing existing business objects. The micro process to be followed is composed of the classical activities of object-oriented analysis, design, implementation, and test, performed iteratively and concurrently in part and involving the complete set of UML diagrams to express structure, behavior, and algorithms of the application system. On the right side of Figure 3, these activities are shown (except for testing) taking pattern from the baseball model of object-oriented software engineering described in Coad and Nicola (1993). The left side shows how the process uses a combination of model-based reuse and component-based reuse. During analysis and design, the developers permanently assess the possibilities of reusing existing business object specifications (the UML techniques used for this purpose are described in subsection 3.4). If appropriate specifications can be found and integrated in the modeling process, this will lead to reuse and assembly of the corresponding business object components during implementation. Business Object UML Models
Business Object Components e.g.
.exe
Design
Analysis
Implementation
.dll
Figure 3: Reuse-Oriented Micro Process for Application Engineering Analysis starts with the definition of use cases and actors, who will interact with the application. As already stated, these requirements can be partially derived from the results of business modeling. More information has to be uncovered in cooperation with the customers and end users to specify the different usage scenarios of the application. If possible, existing use case descriptions belonging to large-grained business object components should be retrieved and used. The second step is to build an analysis model, which should be independent of the technical details of the specific implementation environment. The analysis model shows structural and behavioral aspects of the problem domain. Therefore, class and object diagrams, collaboration diagrams, sequence diagrams, and state diagrams are produced. There are several heuristics about how to identify the modeling elements in this phase, starting from the specified requirements. The realization of the use cases, for example, should be shown by sequence diagrams and collaboration diagrams. The UML notation for patterns can be of help here, and available business patterns stemming from business object documentations should be searched and integrated at this point in preparation of component reuse. During design, technical details are added and the models are adjusted to fit the concrete conditions of implementation. Component diagrams, which contain representations of the runtime business object components, and deployment diagrams are added to the set of models. In order to prepare for the implementation in the BOF environment, the business objects have to be specified in CDL at this point. Probably, UML CASE tools will provide features for transforming UML models into textual CDL specification. In the implementation phase, those parts of the system that could not be assembled by pre-existing components have to be implemented, existing business object components have to be customized, and some glue code may have to be written.
3.4 Business Object Component Engineering Business object component engineering is the process which delivers common, domain specific or enterprise specific business objects. Provided that a marketplace for business objects will evolve, non-software enterprises will primarily have to deal with the production of their own enterprise specific business objects, while more generic
-8-
’98 business objects will be purchased from component suppliers. The specification of CBOs and domain specific business objects has to be adopted by the OMG, anyway, which means a time-consuming procedure. Delivery of business object components is iterative and incremental, no less than application delivery, but the level of rigor and detail is much greater, since the components have to have a high level of quality in order to be reused frequently. If business object component engineering were restricted to delivering runtime components, reuse would be very hard. Instead, the components must be documented in a way suitable to facilitate understanding and retrieval by reusers to allow reuse in early phases of system development, before too many design decisions have been made that cannot be matched with the available components in the implementation phase. The documentation models should be understandable, easy to apply, uniquely interpretable, and easy to customize (i.e., their variability mechanisms must correspond with variability mechanisms of the business object components). While textual CDL specifications are the most rigorous and system-specific tool for documentation, they need to be supplemented by UML models that can be built into the software models during application engineering. It is not sufficient to model the software units as UML components with clearly defined interfaces, because more information about the semantics is needed for reuse. Typical usage patterns, modeled as collaborations, allowed sequences of messages, represented by state diagrams and illustrated by exemplary sequence diagrams, and the business concepts implemented, modeled with the help of class diagrams, can ensure the usability of the components. What can be seen and used by a reuser of the component is called the external design of the business object component. It does not necessarily need to reveal the internal implementation of the component. The internal implementation again builds upon the complete set of UML diagrams. Only those internal aspects of a business object component that are needed to reuse it should be exported via facades (see Gamma et al. 1994), which represent a simplified model of the component and reveal only those parts that need to be directly visible and understood by the application developer. Input to the business object component engineering process are the requirements, models, and documents produced during business engineering, potential domain analysis activities, and primarily the needs of application systems under development. A new business object component finally has to be modeled as a UML package that contains the implementation files (executable component) as well as the documentation and usage guidelines (which can be viewed as source components, in a broader sense than defined by UML).
4 Conclusion In this paper, we have described basic elements of a new business and software system development process model, which uses the UML as its modeling language and focuses the concepts of OMG business object technology. Due to the lack of available space in this paper, it was impossible to go into details, and many aspects could not be mentioned at all. Nevertheless, we have tried to emphasize the necessity of an integrated approach of business and software engineering, building on a clearly defined and stable underlying business object system architecture in order to provide for ease of system enhancement and modification and to allow the seamless integration of business object components conforming to OMG standards. Since the current BOF proposals are not yet adopted and hence no corresponding business object tools are available, BOOSTER*Process will certainly have to evolve and be adapted to the eventual technology. In particular, the use of tools during the process, which is dependent on their functionality and scope, has to be considered explicitly and the role of business object specification with CDL has to be clarified. Furthermore, the relationships to important non-OMG standards such as RM-ODP (ISO/IEC 1995), the Reference Model of Open Distributed Processing, have to be examined in order to provide conformance. It appears that the specialized architecture of BOOSTER*Process can easily be mapped to the more general viewpoints architecture of RM-ODP, which defines an enterprise, an information, a computational, an engineering and a technology viewpoint.
References ALLEN, P. and FROST, S. (1998): Unravelling the Unified Modeling Language. Application Development Advisor, SIGS Publications, January. ATKINSON, C. (1997): Adapting the Fusion Process. Object Magazine, November 1997, 32-39. BOEHM, B.W. (1976): Software Engineering. IEEE Transactions on Computers 25 (12), 1226-1241. BOOCH, G. (1994): Object-Oriented Analysis and Design with Applications. 2nd edn. The Benjamin/Cummins Publishing Company, Redwood City, CA. COAD, P. and NICOLA, J. (1993): Object-Oriented Programming. Yourdon Press, Englewood Cliffs, New Jersey. CBOF (1998a): Combined Business Object Facility – Business Object Component Architecture (BOCA) Proposal. -9-
’98 OMG Business Object Domain Task Force BODTF-RFP 1 Submission. Revision 1.1. Data Access Technologies et al. OMG Document bom/98-01-07. CBOF (1998b): Combined Business Object Facility – Interoperability Specification. OMG Business Object Domain Task Force BODTF-RFP 1 Submission. Electronic Data Systems et al. OMG Document bom/98-04-05. ERIKSSON, H.-E. and PENKER, M. (1998): UML-Toolkit. Wiley Computer Publishing, New York. GAMMA, E., HELM, R., JOHNSON, R., and VLISSIDES, J. (1994): Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, Massachusetts. HAMMER, M. and CHAMPY, J. (1994): Reengineering the Corporation – A Manifesto for Business Revolution. Nicholas Brealey Publishing, London. IBM (1998): IBM San Francisco. IBM Inc. http://www.ibm.com/Java/Sanfrancisco/ (May 1998). ISO/IEC (1995): Reference Model of Open Distributed Processing. ISO/IEC 10746-1 – 10746-4 (ITU-T X.901 – X.904). http://www.iso.ch:8000/RM-ODP/ (May 1998). JAYARATNA, N. (1994): Understanding and Evaluating Methodologies – NIMSAD. McGraw-Hill, New York. JACOBSON, I., CHRISTERSON, M., JONSSON, P., and ÖVERGAARD, G. (1992): Object-Oriented Software Engineering – A Use Case Driven Approach. Addison-Wesley, Wokingham, England. JACOBSON, I., ERICSSON, M. and JACOBSON, A. (1995): The Object Advantage – Business Process Reengineering with Object Technology. Addison-Wesley, Wokingham, England. JACOBSON, I., GRISS, M., and JONSSON, P. (1997): Software Reuse – Architecture, Process and Organization for Business Success. Addison Wesley Longman, Harlow, England. KORTHAUS, A. (1997): Business Objects as Constituents of Future Distributed Object-Oriented Business Information Systems. Discussion Paper 1-97. Lehrstuhl für Wirtschaftsinformatik III, Universität Mannheim, D-68131 Mannheim. KORTHAUS, A. (1998): Using UML for Business Object Based Systems Modeling. In: SCHADER, M. and KORTHAUS, A. (1998), 220-237. MICROSOFT (1998): Microsoft COM Homepage. Microsoft Corp. http://www.microsoft.com/cominfo/ (May 1998). NÜTTGENS, M., FELD, T., and ZIMMERMANN, V. (1998): Business Process Modeling with EPC and UML – Transformation or Integration? In: SCHADER, M. and KORTHAUS, A. (1998), 250-261. OMG (1996): Common Facilities RFP-4, Common Business Objects and Business Object Facility. Request for Proposal. OMG Document cf/96-01-04. Object Management Group. OMG (1997a): Business Object DTF – Common Business Objects. OMG Document bom/97-11-11 Version 1.3. Object Management Group. OMG(1997b): CORBA Component Model RFP. Request for Proposal. OMG Document orbos/96-06-12. Object Management Group. OMG (1997c): Object Constraint Language Specification. Version 1.1, 1 September 1997, Rational Software Corp. et al., OMG Document ad/97-08-08. OMG (1997d): UML Extension for Business Modeling. Version 1.1, 1 September 1997, Rational Software Corp. et al., OMG Document ad/97-08-07. OMG (1997e): UML Extension for Objectory Process for Software Engineering. Version 1.1, 1 September 1997, Rational Software Corp. et al., OMG Document ad/97-08-06. OMG (1997f): UML Notation Guide. Version 1.1, 1 September 1997, Rational Software Corp. et al., OMG Document ad/97-08-05. OMG (1997g): UML Semantics. Version 1.1, 1 September 1997, Rational Software Corp. et al., OMG Document ad/97-08-04. OMG (1997h): UML Summary. Version 1.1, 1 September 1997, Rational Software Corp. et al., OMG Document ad/97-08-03. RUMBAUGH, J., BLAHA, M., REMERLANI, W., EDDY, F., and LORENSEN, W. (1991): Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ. SCHADER, M. and KORTHAUS, A. (1998): The Unified Modeling Language – Technical Aspects and Applications, Physica-Verlag, Heidelberg. SIMS, O. (1994): Business Objects – Delivering Cooperative Objects for Client-Server. IBM McGraw-Hill series. McGraw-Hill Book Company, London. SUN (1998): Enterprise Java Beans 1.0 Specification. Sun Microsystems Inc. http://java.sun.com/products/ejb/ (May 1998). TAYLOR, D. (1995): Business Engineering with Object Technology. Wiley Computer Publishing, New York.
- 10 -
