Combining off-the-shelf software components that are offered by different vendors to individual customer’s business application systems is a goal that is followed up for a lengthy time. By achieving this goal, advantages of individually-programmed software that is combined with standardized, off-the-shelf software could come together. In this context, we are speaking about compositional reuse techniques. Compositional reuse represents special kinds of reuse techniques as generative techniques or code and design scavenging (Sametinger, 1997, pp. 25-28). The emphasis on compositional reuse stems from our guiding model, which is the compositional, plug-and-play-like reuse of black box components that are traded on a component market. In general, a guiding model is an ideal future state that might not be reached completely.
Corresponding with our guiding model, a company that (e.g., needs new software for stock keeping), could buy a suitable software component on the component market and further integrate it into its business application system with little effort. Brown and Wallnau (1996, pp. 11-14) explain the steps that are generally necessary to do so (e.g., technical and semantic adaptation or composition). Expected improvements, which should come along with using software components, concern cost efficiency, quality, productivity, market penetration, market share, performance, interoperability, reliability, or software complexity, cf., e.g., Orfali, Harkey, and Edwards (1996 S. pp. 29-32).
According to Fellner and Turowski (2000, pp. 3-4), the term component is defined as follows: A component consists of different (software-) artifacts. It is reusable, self- contained, and marketable; provides services through well-defined interfaces; hides its implementation, and can be deployed in configurations unknown at the time of develop- ment. A business component is a component that implements a certain set of services out of a given business domain. Refer to Szyperski (1998, pp. 164-168) and Fellner and Turowski (2000) for an in-depth discussion of various other component approaches given in literature.
To use business components according to our guiding model, it is necessary to standardize them as detailed in a discussion on standardizing business components (cf., Turowski, 2000). Furthermore, we must describe the component’s interface and behavior in a consistent and unequivocal way. In short, we have to specify them. Specification
50 Conrad & Turowski
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Figure 1: Software contract levels
Interface level Behavioral level Coordination level Quality-of-service level Terminology level Task level Marketing level
becomes more and more important with respect the to third party composition of business components, as the specification might be the only support available for a composer who combines business components from different vendors for an application system.
Software contracts offer a good solution to meet the special requirements of specifying business components. Software contracts go back to Meyer, who introduced contracts as a concept in the Eiffel programming language. He called it programming by contract (Meyer, 1988) and later extended it to the concept of design by contract (Meyer, 1992). Furthermore, similar concepts are described in Wilkerson and Wirfs-Brock (1989) or Johnson and Wirfs-Brock (1990).
Software contracts are obligations to which a service donator (e.g., a business component) and a service client agree. The service donator guarantees:
•
A service it offers (e.g., calculate balance or determine demand).•
Certain conditions, which have to be met by the service client (e.g., the provision of data necessary to process the service).•
Guaranteed quality performance (e.g., with a predetermined storage demand or with an agreed upon response time).•
The service has certain external characteristics (e.g., the specified interface). Beugnard, Jézéquel, Plouzeau, and Watkins (1999, pp. 38-40) describes a general model for software contracts for components with four tiers. The authors distinguish between syntactic, behavioral, synchronization, and quality-of-service levels. Business components need to be specified on each level.Specification of Business Components Using Temporal OCL 51
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written Figure 1 shows contract levels according to Turowski (2002). By (logically) subdi- viding the synchronization level into inter- and intra-component coordination levels, as an extension to Beugnard et al. (1999), this approach allows for an additional specification of a synchronization demand that exists between different business components. Furthermore, the terminology, task, and marketing level allows for the specification of business related issues.
Basic agreements are concluded at the interface (or syntactic) level. Typical parts of these agreements concern the names of services (offered by a business component); names of public-accessible attributes, variables, or constant values; specialized data types (in common and based upon standardized data types); signatures of services; and declaration of error messages or exception signals. To accomplish this, we use (e.g., programming languages or Interface Definition Languages (IDL)) like the IDL that was proposed by the Object Management Group (OMG) (OMG, 2002 S. 3.1-3.74). The resulting agreement guarantees that service client and service donator can communicate with each other. However, emphasis is placed on enabling communication technically. Semantic aspects remain unconsidered.
Agreements at the behavioral level serve as a closer description of a business component’s behavior. These agreements enhance the basic agreements of the interface level, which mainly describe the syntax of an interface. Agreements at the interface level do not describe how a given business component acts in general or in borderline cases. As an example, we could define an invariant condition for a business component “stock keeping” at behavioral level, which would say that the reordering quantity for each (stock) account has to be higher than the minimum inventory level. Known approaches to specify behavior are based on approaches to algebraic specification of abstract data types, cf., e.g., Ehrig and Mahr (1985). To describe behavior, the specifi- cation of an abstract data type is extended by conditions. These conditions describe the abstract data type’s behavior in general (as invariant conditions) or at specific times (pre-conditions or post-conditions). In general, conditions are formulated as equations and as the axioms that they become part of through the specification of an abstract data type (Ehrig & Mahr, 1985). The Object Constraint Language (OCL) (OMG, 2001, pp. 6.1- 6.50) is an example of a widespread notation that specifies facts at the behavioral level. It complements the Unified Modeling Language (UML) (OMG, 2001).
Agreements at the intra-component coordination (synchronization) level regulate the sequence in which services of a specific business component may be invoked, as well as regulate the synchronization demand between its services. Here, e.g., we may specify that a minimum inventory level has to be set before it is allowed to book on a (stock) account for the first time, or we may specify that it is not allowed to carry through on more than one bookkeeping entry at the same time, for the same account.
At the inter-component coordination level are agreements that regulate the se- quence in which services of different business components may be invoked. Here, e.g., we may define that a certain service, which belongs to a business component shipping, and which refers to a certain order, may only be processed after a service belonging to a business component, sales. Also, that it refers to the same order and has been processed at any time before. It should be noted that the differentiation between an intra- and inter-component coordination level depends on the identification of business components rather than their granularity. The granularity of a business component depends on the number of services it offers.
52 Conrad & Turowski
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Various approaches exist to specify business components at the coordination level. These approaches are based, e.g., on using process algebras, process calculi (cf., e.g., Hennessy, 1988), or temporal logics cf., e.g., Alagar and Periyasamy (1998, pp. 79-131). In addition, (semi-formal) graphical notations are used. These notations are mostly graphical notations used in the context of business process modeling. Besides extended event-driven process chains (eEPC) (Keller, Nüttgens, & Scheer, 1992, pp. 32-35) and approaches that use eEPC as a basis, e.g. (Rittgen, 1999), Petri net based notations are in use, e.g., Jaeschke, Oberweis, and Stucky (1994). In particular, object-oriented software development methods like Rumbaugh, Blaha, Premerlani, Eddy, and Lorensen (1991), Coleman (1993), or Booch (1994) provide such modeling means.
Non-functional characteristics of business components are described as an exten- sion of functional characteristics. Non-functional characteristics are specified at the quality-of-service level. An Example of these characteristics is the distribution of the response time of a service or its availability. For further non-functional requirements and their definition cf., e.g., (Jalote, 1997, pp. 73-158).
In all levels mentioned thus far, the specification of business components uses technical terms, which have a domain-specific functional meaning (semantic), e.g., stock, inventory level, or account. Often these terms do not have unequivocal meanings or definitions and hence, have to be specified to guarantee their unequivocal use. The terminology level serves as a central registry for all of these terms and keeps all terms that are useful for the specification and their definitions in a dictionary. In order to achieve a high quality of specification, norm language reconstruction is used to specify the respective issues (Ortner, 1997). The same technique is used to specify issues at the task level. In the task level, we explain what business tasks are supported or automatically done through services offered by a business component.
At the marketing level, features of the business component that are important from a business-organizational point of view are specified using tables (e.g., legal or contract terms, version, coarse business domain, or vendor contact persons).