International Journal of Technology Management 20, 3/4 (2000)

New Revolutionary Paradigm of

Software Development for Mainstream Business Operations

June S. Park

Department of Management Sciences, The University of Iowa, Iowa City, IA 52242-1000

Abstract

This paper discusses current issues and future evolution of the software engineering

methods that are useful to create and maintain operations support systems (OSSs) in

business firms. In particular, two related methods—model-based development (MBD) and

component-based development (CBD) methods—are discussed in details. CBD is widely

regarded as revolutionizing the software industry. The purpose of this paper is to enhance

correct understanding of the advantages of CBD over existing methods when it is applied

to developing mainstream business applications. We introduce a market-leading CASE

tool to illustrate the concepts underlying MBD and CBD.

1. Introduction

As market, technology and competition environments continually change,

businesses often need fundamental transformations (or reengineering) of their operations to

stay ahead of its competitors for the long term. Such business transformations usually

require creation, adaptation and enhancement of information systems.

1
 However, building information systems from scratch has been too slow, expensive

and risky. Many companies purchased enterprise application packages to avoid the delay

and risk associated with the custom-build approach. Those packages, however, often do

not meet specific needs of individual companies, especially in areas where the company

seeks to gain competitive advantage. Companies must find ways to take advantages of

both off-the-shelf packaged solutions and in-house (or outsourced) custom development.

The shift towards object-oriented programming (using C++, Smalltalk and Java)

has been advocated as a solution to resolve the problems inherent in the traditional

custom-build approach. However, object-oriented programming has not been widely

adopted by businesses, especially in building enterprise-level OSSs.

In this paper we discuss currently available as well as emerging methodologies

with which businesses can significantly improve the development cycle time, cost and

quality of mission-critical OSSs. We discuss the architecture of OSS in the next section,

and the changing trend of information technologies affecting OSSs in Section 3. In

Section 4 we examine critical issues facing businesses today with respect to developing

and maintaining OSSs. We discuss the model-based and component-based development

methods in Sections 5 through 8, and show how these methods can solve the current

problems. Examples of MBD and CBD are shown in Sections 6 and 8, respectively, using

the integrated CASE tool called Cool:Gen. Section 9 contains some concluding remarks.

2. OSS Architecture

Corporate information systems (IS) can be classified into executive support

systems, decision support systems and operations support systems in line with the concept

2
of management hierarchy [1]. The OSS processes mission-critical business operations

according to pre-defined business rules. In so doing it typically read, create, update and

delete individual records in corporate databases. Examples include sales order processing,

inventory management, production scheduling, bank transaction processing, airline

reservations, etc.

Figure 1 shows a typical three-layer architecture of OSS [17]. The three layers are

user interface, business rules, and database layers. OSSs are generally big and complex, so

it is hard to imagine to develop the system without an engineering approach where the

requirement analysis and the system design precede the system construction. The

specifications of requirements and design are called conceptual and logical models,

respectively. The output of construction such as windows, source code and database tables

are called physical objects.

Conceptual Models Logical Models Physical Objects

User Interface User Tasks, Work Forms, Form Flow Windows, Dialog Boxes,
Flow Screens, 3GL Code

Business Rules Business Functions, Processes, Process SQL DML, 3GL Code
Rules Flow

Database Information Entities, SQL DDL, Tables,

Subjects Relationships Indexes

Figure 1. Architecture of Operations Support Systems

3
 3. OSS Infrastructure

While IS development capabilities of business firms did not show a satisfactory

progress overall, the underlying technical infrastructure has undergone dramatic changes

Network-
Centric
Computing

Client/Server Computing

Online Computing

Batch Computing

1950 1975 1990 2000

Figure 2. Evolution of Information Technology Since 1950s

over the past two decades as shown in Figure 2.

With the advance in technologies for PCs, LANs, network servers, network

operating systems, relational databases and communication middleware during 1980s, the

client/server computing became a technically and economically viable option for OSSs

except for very large-scale transaction processing systems (with a workload of thousands

of transactions per second). Furthermore, as companies empower self-managed

multifunctional teams to oversee each reengineered business processes, the client/server

architecture has become the choice of computing architecture for workgroup OSSs. The

migration of an OSS from a mainframe to a network of PCs and servers, however, requires

a major rewriting of the software. The complexity, risk and cost of this rewriting have

4
been the main reason for many companies to buy client/server-targeted application

packages.

With the explosive growth of the Internet use by the public and businesses since

mid 1990s, many companies have begun to exploit the benefit of intranet, electronic

commerce and network-centric computing. New business-to-business and business-to-

consumer electronic commerce systems and thin-client based, network-centric computing

systems require far enhanced interoperability among software modules written in different

languages and running on different platforms. The emergent, network-centric computing

architecture has very thin clients, with the majority of business rules and the database

implemented server-side and any client-side behavior downloaded on demand. The thin

client model is also enabling experimentation with network PCs (NPCs), diskless machine

that boot from and load all software from the network.

In application terms, network-centric computing has contributed to the delivery of

applications further from the core applications required to run the heart of a business (like

accounting and financial control) to those which interact directly with people outside the

business boundaries (like customer loyalty programs and the supply chain management).

The rapid development of intranet, extranet and electronic commerce is fueling the

network-centric computing model which is based on distributed components.

For example, NationsBank is opening its major database to a thin-client interface

through server-side applications made of Java components. The bank hopes to provide

browser-based access to thousands of customers, in addition to ten thousand internal users

already on its intranet.

5
 The reality of OSSs in many large corporations today, however, is the coexistence

of mainframe-based batch and online transaction processing systems, client/server OSSs

with Window- or Web-based clients, and a growing number of electronic commerce and

network-centric computing systems exploiting the global Internet.

4. Current Problems in OSS Development

A case in point: Oxford Health Plan, a managed-care pioneer, recently developed a

new information system, but the system suffered from problems, which left the company

unable to send out monthly bills to thousands of customer accounts and rendered it

incapable of tracking payments to hundreds of doctors and hospitals. In less than a year,

uncollected payments reached $400 million, while the sum the company owed care givers

exceeded $650 million [18]. The CEO resigned and the company was taken over by a

private investment company [4].

Due to such risk of the custom-build approach, many companies turned to buying

business software packages ready to install. According to a survey by Sentry Group [26],

the portion of in-house built information systems decreased from 71% to 43% during the

1991-95 period. On the other hand, sales of R/3, an enterprise application package

developed by Systeme Anwendung Produkte AG (SAP), increased from $500 million in

1992 to $1.5 billion in 1995. The ‘best practice’ operations built into the logic of

enterprise application packages (a.k.a. Enterprise Resource Planning packages), however,

often do not meet specific needs of individual companies, especially in areas where a

company seeks to gain competitive advantage. As a result, installing an ERP package

6
involves an army of consultants to help customization, which can cost three to five times

the software price tag [3]. Still worse, customized features are often not supported by the

package vendor and not incorporated into future versions of the package.

Companies must find ways to take advantages of both off-the-shelf packaged

solutions (‘buy’ options) and in-house custom development (‘build’ options). Off-the-

shelf packages can lower the software cost tremendously for individual companies if the

package can meet the requirements of a large number of companies. It is this cost

effectiveness that motivated the U.S. federal government’s recent shift in its software

acquisition policy toward the greater use of existing commercial off-the-shelf (COTS)

products [5]. Therefore, the question boils down to how we make off-the-shelf packages:

 reusable across many companies – reusability

 easy to customize – maintainability

 easy to assemble together even if they are from different vendors – interoperability

The shift towards object-oriented programming (using C++, Smalltalk and Java)

has been advocated as a solution to resolve the problems inherent in the traditional

custom-build approach. The object-oriented (OO) programming can reduce the

development cycle time and budget, and improve the quality of software by reusing pre-

built and pre-tested software objects available in class libraries. However, OO

programming has not been widely adopted by businesses, especially in building enterprise

OSSs. The contribution of OO programming to OSSs has been by and large limited to the

development of graphical user interface (GUI). Major reasons for the lack of wide

deployment seem to be the following:

7
 lack of interoperability among OO programs written in different languages, and

between OO programs and legacy programs (mostly written in COBOL)

 difficulty of managing transactions on relational and legacy databases with OO

languages

 massive number of objects required to build a typical enterprise application, and

difficulty of inventorying, tracking and searching objects for reuse under the large

volume of objects

 immaturity of OO analysis and design methodologies and tools that can facilitate the

decomposition of complex business services and rules into a required set of classes,

and the management of complex interrelationships among classes.

Companies today must achieve the following objectives when developing OSSs for

strategic competitiveness [10]:

 ensure that information systems are developed in conformance with business strategies

– strategy-compatibility

 create new applications and update existing applications quickly enough to effectively

support the continual creation and reengineering of business operations – developers’

productivity increase (by increasing reusability and maintainability of OSS)

 easily adapt existing applications to changes in the underlying technical infrastructure

in order to exploit more economical and powerful new technologies – portability

 easily integrate workgroup applications with business rules and databases maintained

by enterprise OSSs – scalability

8
 forge links between packaged software, new applications built in-house, and legacy

systems – interoperability.

5. Model-Based Development of OSS

In this section we show how MBD can help businesses meet most of the above

objectives. We define the model-based development (MBD) to mean that developers

create conceptual and logical models, and then a computer-aided software engineering

(CASE) tool automatically constructs physical objects (see Figure 1).

In 1988, a special report in Business Week [7] argued that CASE was the only

solution to the software crisis in businesses. The greatest benefit of CASE tools today lies

in their capability of automatically generating computer program codes. Over the last

decade the code generation technology has been greatly advanced. Using a CASE tool like

Sterling’s Cool:Gen [20], one can generate thousands of lines of C or COBOL code per

second based on the analysis and design models. Moreover, the generated codes are free

of syntactic errors, although logical errors may exist due to misspecified models.

Equally beneficial is that using a CASE, one can reuse models to generate

executables for different applications and for different target environments (i.e., different

combinations of programming language, operating system, database system and

communication system). Target environments supported by various CASEs include

mainframe batch processing, on-line host/terminal systems, stand-alone desktop,

client/server systems with fat or thin clients, and network-centric computing systems (see

Figure 2).

9
 Using the code generation capability of a CASE, businesses can greatly improve

developers’ productivity as well as the quality, reusability, portability and bi-directional

scalability (e.g., easy migration of applications from desktop to client/server, or

host/terminal to client/server environment) of OSSs.

All the artifacts created in the OSS development process (such as models, source

codes, executables, etc.) are stored in the CASE repository. Models in the repository

developed for enterprise OSSs can serve as the basis for developing workgroup OSSs.

Workgroup applications already built using visual programming tools (such as Visual

Basic, PowerBuilder, Delphi, etc.) can be integrated with CASE-generated enterprise

applications using the object embedding and linking (OLE) technology. Hence improved

scalability, allowing an easy growth of small applications into more serious applications.

Integrated CASE tools (I-CASEs), which support the entire life cycle of OSS

development from planning to construction, include Sterling’s Cool:Gen, Oracle’s

Designer/2000 and SEER’s SEER*HPS and SEER/7000. There are other types of

application development tools (ADTs)—such as host-targeted 4GLs, client/server-targeted

4GLs, package-oriented 4GLs, analysis tools (a.k.a. upper CASE), visual programming

tools and Web development tools—that can improve the development productivity and

software quality for OSSs (see [8] for a survey of commercial tools in different categories).

Recent trends in the ADT industry include vertical integration; that is, vendors try

to provide the support for the full life-cycle from planning/analysis to code generation by

expanding their product capability, or by making their tools interoperable with other tools

in the upstream or downstream, or by making a strategic partnership with other vendors.

The Object Management Group’s (OMG) recent adoption of Unified Modeling Language

10
(UML) [23] as the standard object-oriented analysis/design method will help accelerate the

interoperability among development tools.

As a result of vertical integration efforts and increased interoperability among the

development tools, the boundary between workgroup-level tools and enterprise-level tools,

and that between host/terminal, client/server and network-centric tools are becoming

blurred. For example, Microsoft recently partnered with Rational to develop ‘Rose for

Visual Basic’, a UML-based CASE tool for developing business applications using Visual

Basic. Rose for Visual Basic represents one of Microsoft’s recent efforts to extend its

ADTs into the enterprise-level OSS market.

6. Example: Model-Based Development of OSS using Cool:Gen

For illustration of the model-based OSS development process, tasks involved in

building an OSS using Cool:Gen are shown in Figure 3 [11]. The tasks can be divided into

human-performed and CASE-performed (automated) tasks. In the figure, the former is

shown in white boxes and the latter in gray boxes. The tasks can be further classified

according to the OSS architecture matrix shown in Figure 1 as follows:

 Human-performed tasks

Developers may perform information strategy planning (ISP) [14] first. They should

conduct user requirement analysis and design modeling [15, 16] including:

 User interface modeling

 Forms: design of the layout of windows and dialog boxes (or block-mode screens

if dumb terminals are used) [Window Design Diagram]

11
  Form flow: specification of the flow of control among windows and dialog boxes

that should reflect the user’s work flow [Dialog Flow Diagram, Navigation

Diagram]

 Operations logic modeling

 Processes: decomposition of business functions into ‘elementary processes’ each

of which has defined input, output, database access/maintenance activities, and the

processing logic [Activity Hierarchy Diagram]; specification of the algorithms of

elementary processes, client and server procedures using a ‘model-based’ fourth-

generation programming language (4GL) [Action Diagram]

 Process flow: specification of the flow of control among elementary processes, and

client and server procedures [Navigation Diagram]

Define Logical Data Model Transform Logical Model into Physical Model Produce DDL
Data Structure List Data Store List
Data Model
Diagram Environment
Data Definition
Data Model
Browser
Define Data Code
Data Model Maintenance Logic Generation
List
Action Diagram

Define Business
Activities Produce Executable Code
Define Client & Server with Embedded SQL
Procedural Logic
Logic Activity Hierarchy Environment Code
Diagram Definition Generation
Action Diagram

The
Application
Produce User Help
Design User Interface Produce Executable Code
Navigation Window Design Environment Code
Presentation Diagram Definition Generation
Diagram
Establish Comms
Environment
Client Manager

Communications
12
Figure 3. Tasks involved in developing an OSS using CASE tool Cool:Gen
 Database modeling

 Data model: decomposition of information subjects into entity types [Subject Area

Diagram]; modeling of data semantics in terms of entity types and relationship

types [Data Model Diagram (a.k.a. Entity/Relationship Diagram)]

 CASE-performed tasks

Given the user-specified target environment parameters including programming language,

client operating system (OS), server OS, database management system (DBMS), and

communication protocols, the CASE tool performs:

 Mapping of the data model to the database schema (table definitions and integrity

constraints) and the storage schema (indexes and storage allocation); generation of

SQL data definition language (DDL) script; creation of the database using the DDL

script

 Code generation for user interface and client procedures

 Code generation for server procedures.

 Code generation for elementary processes with embedded SQL (i.e., embedded data

manipulation language (DML) scripts)

 Packaging of related procedures into a load module

 Pre-compilation of SQL scripts, and compilation of source codes

 Linking (including external modules, if any), provision of interactive debugging

facility, generation of executables, and provision of communication run-time

13
 OSS developers can perform ISP and develop user interface, logic and data models

using various graphical notation and diagramming methodologies (which are listed above

in brackets). The ISP can be performed using the same notation and methodologies that

are used in user requirement modeling, thus enabling a smooth transition from the strategy

plan to the requirement specification, and helping ensure that the OSS is developed

according to the strategic direction.

Procedural algorithms for elementary processes, and client and server procedures

are specified using a proprietary 4GL. The 4GL program (which is called action diagram

although it is in textual language and not graphical) can use only those objects defined in

analysis and design models as operands in the program statements. Thus, all algorithms

are specified at the logical level. The action diagram can be written using only the syntax-

directed editor provided by the CASE tool. The editor is intelligent enough to understand

the user-developed analysis and design models, and provides a limited set of context-

sensitive options for programming constructs and operands, as the developer builds each

statement into the algorithms.

External program modules developed outside the Cool:Gen environment, even if

they are written in a different 3GL from the language chosen for the Cool:Gen-generated

application, can be linked into the Cool:Gen-generated load modules. Also, OLE-

compatible GUI objects developed outside the Cool:Gen environment can be placed in

Cool:Gen-generated windows and dialog boxes.

If a change is required of the OSS later, developers can modify only the models

(including action diagrams) and regenerate the application using the code generation

facility. If the underlying technical infrastructure is changed, developers can regenerate

14
the application with changed target-environment parameters without having to change the

models.

7. Component-Based Development of OSS

With the CBD approach, software is constructed more like manufactured objects,

where assemblies of increasing complexity are built with collections of reusable, pre-tested

and well documented components. As discussed in the previous three sections 4 to 6,

MBD can cure chronic symptoms of the conventional custom-build approach by

remarkably improving development productivity, software quality, reusability,

maintainability, strategy-compatibility, portability and scalability. However, as mentioned

in Section 3, emerging network-centric computing systems require far enhanced

interoperability among software modules written in different languages and running on

different platforms. Also, forging links between packaged software, new applications built

in-house, and legacy systems through enhanced interoperability is one of the most

demanding needs of OSS developers today as mentioned in Section 4. The component

technology addresses these needs for improving interoperability. As will be shown in this

section, MBD and CBD are not competing, but complementary methodologies—MBD is

essential for building large-scale business components.

A software component is an encapsulated software object which offers services

through interfaces. Components interoperate with each other through interfaces. A legacy

application can be componentized using an interface wrapper. New interfaces can be

added to an existing component specification to extend the functionality of the component.

15
A component may provide multiple interfaces and an interface can be implemented by

multiple components.

The component technology separates the specification (i.e., the interface definition)

from the implementation. By this separation, the implementation of a component can be

written in a different programming language or executed on a different platform from the

language and platform used by the client program. Therefore, designers gain the freedom

of changing the implementation technology for a component without affecting the rest of

the system.

To summarize, components have these characteristics:

 Interface-based – A component is specified as a package of interfaces. The component

implementation is separated from its specification.

 Object-oriented – A component is packaged with both data and services, and has

public and private parts (encapsulation). The same interface may be supported by

different components (polymorphism). Components allow reuse by composition

(similar to, but better than reuse by inheritance).

 Distribution-transparent – Components on different machines (with the same or

different operating systems) can interoperate.

 Language-independent – Components written in different languages can interoperate.

It is the interface-based interoperability that is currently driving CBD. With that

plus language independence and distribution transparency, components can overcome the

limitations of object-oriented classes discussed in Section 4.

16
 Most component technologies such as COM, Corba and Java Beans have evolved from

OO programming. However, it is entirely possible to implement components in non-

OO languages such as Cobol and C. OO and non-OO components can all interoperate.

 The language independence of components also provides an effective way to exploit

worthwhile chunks of functionality from legacy applications.

 Ease of access and maintenance of databases, secure and fast transaction processing are

achievable using CASE-generated, white-box components (to be discussed below).

Other component technologies such as COM are evolving to provide the transaction

processing performance required by mission critical OSSs.

 Extending the functionality of a component can be achieved by assembling new sub-

components based on their interfaces. This interface-based ‘design by composition’

avoids the complexity of ‘design by inheritance’ in OO approach.

In fact, one of the immediate benefits of component technology to businesses is

that it can leverage the Windows API using Visual Basic on the client side and still enjoy

cross-platform portability of server applications using Java on the server side. For instance,

Microsoft Interface Definition Language (MIDL) can be used to componentize both Visual

Basic clients and Java objects [9]. Objects are easy to implement, but difficult to use due

to inheritance. Inheritance could also be inefficient at run time. Components are difficult

to implement (at least for now), but easy to use. They are independently deliverable, and

all that clients need to know is their interfaces.

Although it is the ‘interface-based interoperability’ that renders the component

more attractive than the conventional OO technology, unfortunately there are no

17
international bodies formalizing standards for component interfaces. At present there are

several de facto standards such as Sterling’s (originally Texas Instruments’) CBD [19]

(which is called TI/CBD in this paper to distinguish it from the general term CBD),

Microsoft’s Component Object Model (COM) and Distributed COM (DCOM) [22],

OMG’s Common Object Request Broker Architecture (CORBA), Sun’s Java Beans, and

IBM’s System Object Model (SOM) and Distributed SOM (DSOM).

There are pairs of de facto component standards that have been made compatible

with each other. For example, COM-based ActiveX can be placed in SOM-based

OpenDoc documents; a COM proxy can be easily constructed using Cool:Gen to allow

any COM-based client to access TI/CBD-based server components; various efforts are

under way to build a standard bridge between COM and CORBA. COM and TI/CBD

currently enjoy the largest share in fine-grained and large-grained component markets,

respectively.

Components vary widely in size, scope and complexity: e.g., GUI controls, inter-

application communication protocols, security and authentication services, specific

business services, and complete business applications.

Fine-grained components with a small scope of services, such as a GUI control

component and an Internet connectivity component, typically have reusability across a

wide range of applications. They, however, are closer to the code and operate at a lower

level of abstraction, so they do not enhance developer productivity as remarkably as large-

grained components.

Unlike typical class libraries, components allow distributing reusable code in an

executable form—source is not required. Fine-grained components are mostly black-box

18
components in source or executable formats without logical models. They are difficult for

consumers to customize. For client-side components such as GUI controls, the absence of

models is not a serious problem.

Large-grained components such as a telecommunication billing component and a

material management component can dramatically improve the development productivity.

However, because of their size and specificity, their potential for reuse is low, which is

reminiscent of the shortcomings of ERP packages. For server-side, large-grained

components that provide key business functions, customers may well want white-box

models, or at least source codes, so that they can customize them.

Components that are delivered including logical models are called white-box

components. Large-grained, white-box components can be built using a CASE tool.

Consumers can modify the models using the same CASE tool and regenerate the

component using the CASE code generation facility, if the component needs customization

or implementation in a different target environment. White-box business components,

therefore, can find reuse across many companies and can be flexibly adapted to continually

reengineered business operations (see Figure 4).

The real power of CBD comes from large-scale integration using hierarchies of

components—components composed of other components [2]. The hierarchy allows

developers to think about problems at appropriate levels of abstraction. Creating correct,

reusable component hierarchies requires designing correct architecture. CASE tools

focused on CBD can be an effective means to that end. Even with components, there is no

substitute for the model-based software engineering process, especially when one develops

an enterprise OSS.

19
 ADT vendors traditionally considered to be players in the workgroup space (such

as IBM, Microsoft and Oracle) are trying to leverage a component-based approach that

will compete with enterprise-level ADT vendors like Sterling and Forte. For example,

Microsoft and Rational are strategically aligned to combine Rational’s analysis and design

expertise into future versions of Microsoft’s enterprise development tools, producing life

cycle tools that will seamlessly integrate with Visual Basic, Visual C++ and Visual J++

based on COM technology. Rational’s CASE tool, Rose, on the other hand, is being

enhanced to support large-scale CBD projects by providing the UML-based component

modeling facility, an inventory of pre-built component models and templates, and the

facility for implementing ActiveX/COM, Java Beans and CORBA.

Even the package vendors began to unbundle their products into components to

permit greater reusability and customization, thereby better competing in the coming new

Large Grained, Black

Box Components
(e.g., Business
Large Grained, White
Application Packages)
Box Components
(e.g., Model-Based
Developer Productivity

Business Components)

Fine Grained, Black

Box Components
(e.g., GUI Controls)

Reusability

Figure 4. Trade-off between Productivity and Reusability

20
generation of software industry. For example, SAP’s R/3 4.0 includes SAP components

written in ABAP which are interoperable with COM components [24].

In CBD, the identification of components to be integrated into a new application

and the proper management of their interconnections become a central concern.

Component repositories provide sophisticated methods for storing, browsing and

examining components. They can not only visualize a component’s specification, but can

support for version control, dependency tracking, impact analysis and other necessary

functionality required for large-scale systems composition. Microsoft Repository is likely

to be the first de facto standard for integrating components from different vendors. The

UML-based information model is used in MS Repository to describe components in a

standard format. The UML information model includes class models, component models,

deployment models, etc. For example, Sterling’s TI/CBD supports UML-compliant

component specifications. The specification of a Cool:Gen component on Windows NT

can be published to the MS Repository by a simple drag and drop [19].

Visual component management tools are being developed by many ADT vendors

(including Borland, Microsoft, Select, Sterling, SuperNova, Sybase, WebLogic, etc.).

These tools may provide the design- and run-time utilities developers need to locate, query,

consume, monitor and load-balance thousands of components that make up an application.

For example, Select Software Tools’ Select Component Manager provides management of

multiple repositories such as Microsoft, Softlab and Unisys repositories [25].

Research projects such as Process Handbook project at MIT Center for

Coordination Science, Multigraph Architecture (MGA) project at Vanderbilt University

Electrical and Computer Engineering Department, Architecture Design Environment

21
(ADE) project at Andersen Consulting Center for Strategic Technology Research, and

CHAIMS (Compiling High-Level Access Interfaces for Multi-site Software) project at

Stanford University Computer Science Department are a few examples of the effort to

facilitate the software composition process using components.

8. Example: Component-Based Development of OSS Using Cool:Gen

In this section, we show how large-grained, white-box components can be built and

published using the TI/CBD approach. Large-grained business components are identified

during the information strategy planning or the requirement analysis phase using such

methods as parallel decomposition [15] and clustering analysis [14].

The parallel decomposition performs the decomposition of business functions and

the decomposition of information subjects in parallel so that the mapping between the

functions/processes and subject areas/entity types are clearly established. At the bottom

level of the decomposition one can find, for each elementary process, which entity types it

interacts with and what actions (among create, delete, update and read) it performs on each

entity type. At a higher level one can see which entity clusters or subject areas are

required by each business function.

The clustering analysis applies the bond energy algorithm (BEA) [6] to the

elementary process vs. entity type matrix. Cells in this matrix contain an affinity measure

between each pair of elementary process and entity type. The BEA produces clusters of

closely related elementary processes and entity types along the diagonal of the matrix.

Each cluster found is considered a candidate for an encapsulated business object, i.e., a

business component. A business component consequently packages both the selected

22
business functions and their required data, delivering an independent and coherent set of

business services.

A TI/CBD component is an independently deliverable package of reusable business

services. The component has three facets [12,13]:

 Interface Specification – describes what the component does and how a client can use

it. It includes a type model and a list of public operations. The type model is given by

the data model corresponding to a subject area. The public operations are declared by

the set of names, parameters, pre- and post-conditions of action diagrams. As such,

the interface specification is defined strictly in analysis terms (see Figure 3).

 Implementation Design – describes the internal design of the component. It includes

action diagrams, database schema, user interface design models, etc. (see Figure 3).

The implementation design may be optionally included in the component delivery. If it

is, that makes the component a white-box component; viz., the executable can be

regenerated for different platforms and easily modified as the need arises by changing

the analysis and design models.

 Executable – includes a library of binary object modules and the database DDL for a

specific target environment (see Figure 3). The executable may be provided instead of

the implementation design in the component delivery, in which case the consumer

receives a block-box component. Having witnessed the success of companies like SAP

in selling packaged server applications as configurable binaries, it is not unreasonable

to expect that server-side components might be marketed as black-box components.

For components developed internally, the ability to distribute them without source

23
 might actually be an advantage—it ensures that the business rules enforced by the

component cannot be altered.

8. Conclusion

As discussed in this paper, the CBD trend is driven not only by the need for

building applications quicker by reusing prefabricated software objects, but also by the

increasing importance of network-centric distributed computing enabled by Internet, Web,

Java and ActiveX. The component technology is fast evolving to support the automatic

code download to clients and to provide scalable, robust server functions enabling secure

and recoverable transaction processing, all based on the Object Request Brokers (ORB)

run-time architecture.

However, the component technology is still in its infant. COM/DCOM, being the

most widely deployed component technology at present, is still far from perfect in its

details. For example, language MIDL it uses for defining interfaces of components is yet

confusing and difficult to use. Fine-grained components require system software supports

in order to deliver complete business services, but the necessary supports are not yet

mature.

Fine-grained components need run-time support of inter-component

communication across the network (including LAN, WAN and Internet), dynamic

invocation, network security, transaction monitoring, message queuing, concurrency

control, transaction recovery, load balancing, etc. Microsoft Transaction Server (a.k.a.

Viper) for NT is evolving to meet these requirements, but its performance in handling

heavy transaction loads has not been proven.

24
 Model-based, large-grained white-box components provide better performance for

high-end transaction processing systems at present. Therefore, integrated CASE vendors

who have incorporated CBD methods in their application development process are

currently better poised to lead the CBD drive for enterprise OSSs.

We can, however, integrate fine-grained components with large-grained business

components to take advantages of both. The productivity gain from using the MBD

approach in building large-grained components and the wide reusability of fine-grained

components in the user interface and technical infrastructure areas can be combined to

maximize the benefit of CBD approach. As shown in Figure 5, MBD can contribute to

developing and customizing packages, templates and components as well as

componentizing legacy systems. The CBD can be used to glue together legacy systems,

custom-built applications, purchased packages, templates and components, and in-house

built components as shown in Figure 5.

When all the necessary support technologies are advanced enough so as to build

large-scale enterprise OSSs by assembling fine-grained components, the component

technology will allow us to think of a pool of information handling components that

provide services to retrieve and manipulate data and which can be quickly selected and

arranged to match the work flow of a particular business process, instead of regarding each

business problem as requiring a unique application solution. We will be able to package a

bunch of object or non-object code into a component, and move this component to

different processes and machines at our whim. As shown in Figure 6, components at user

interface, business logic and database access/maintenance layers will exist independently

of each other and of consuming applications, and dynamically reassembled to support

25
frequently created and reengineered business processes. Components at each layer can be

reused across different applications and their implementations (including programming

language, operating system, hardware platform, etc.) can be flexibly changed to exploit

emerging better technologies without affecting other components or applications. Even the

DBMS and transaction processing management systems (TPMS) are likely to be

unbundled and componentized to better support applications composed of distributed

components and implemented on the network-centric computing architecture.

An increasingly large number of interoperable components will be made available

on the open market to developers. According to Gartner Group [21], by 2001, at least 60%

of all new applications development will be based on assemblies of components, and

models, templates and component sales will grow to in excess of $2 billion in software and

$5 billion in related services.

26
 Business Business
Requirements Solution

Application
Development
<MBD> Play
Packages Applications
Buy
<MBD>
Customize Plug
<MBD> Component
Templates Development
<MBD> Mine <MBD>

Reusable Components
Buy
Components
<MBD> Reverse
Engineering
<MBD>
Legacy
Interfaces
Systems Wrap
<MBD> Deployment
Sources Acquisition Processes Deliverables Processes

Figure 5. CBD-Based Plug & Play Architecture of OSS

27
User Interface Layer
Appreciation
Letter
Order Entry
Customer Account
Maintenance Inquiry

Business Rule Layer

Customer Accounts
Credit Maintenance Receivable
Authorization
Billing
Order
Scheduling

Database Layer
Create Create Update Read Create
Order Customer Customer Product Bill

Read
Customer DBMS Components and Read Bill
Stored Database

Figure 6. Architecture of Pure Component-Based OSS

28
Reference

[1] R. N. Anthony, Planning and Control Systems: A Framework for Analysis, Harvard

University Press, Cambridge, Mass., 1965.

[2] D. Chappell, “The Next Wave—Component Software Enters the Mainstream,”

Rational Software, 1997 (http://www.rational.com/support/techpapers/nextwave/)

[3] G. Edmonson, S. Baker and A. Cortese, “Silicon Valley on the Rhine,” Business

Week, Nov. 3, 1997, 162-166.

[4] S. Jackson, “Not Everything Oxford Did Needs Repair,” Business Week, March 9,

1998, 38.

[5] P.A. Oberndorf, “Facilitating Component-Based Software Engineering: COTS and

Open Systems,” In Proc. 5 th Int’l Symposium on Assessment of Software Tools

(Pittsburgh, June 2-5, 1997), IEEE Computer Society, 143-148.

[6] W.T. McCormick, Jr., P.J. Schweitzer and T.W. White, “Problem Decomposition and

Data Reorganization by a Clustering Technique,” Operations Research 20, 1972,

993-1009.

[7] O. Port, J.W. Verity, A.R. Field, S.M. Gelford and K.H. Hammonds, “The Software

Trap: Automate or Else,” Business Week, May 9, 1988, 142-154.

[8] Price Waterhouse, Technology Forecast: 1997, 1997

[9] R. Sessions, COM and DCOM: Microsoft’s Vision for Distributed Objects, John

Wiley & Sons, 1998.

[10] K. Short, “Component Based Development and Object Modeling”, Sterling Software,

Feb. 1997 (availalabe at http://www.cool.sterling.com/cbd/whitepaper/coverpg.htm)

[11] Sterling Software, LiteTrak Student Guide: Book 1, 1997.

29
[12] Texas Instruments, The CBDS96 Standards, 1996

[13] _____, Component-Based Development Fundamentals, 1996

[14] _____, Composer: Planning, 1995.

[15] _____, Composer: Analysis, 1995.

[16] _____, Composer: Design, 1995.

[17] D. Vaskevitch, Client/Server Strategies, IDG Books Worldwide, Foster City, Calif.,

1995.

[18] R. Winslow and G. Anders, “How New Technology Was Oxford’s Nemesis,” The

Wall Street Journal, Dec. 11, 1997.

[19] http://www.cool.sterling.com/cbd/

[20] http://www.cool.sterling.com/products/gen/

[21] http://gartner11.gartnerweb.com/public/static/home/home.html

[22] http://www.microsoft.com/cominfo/

[23] http://www.rational.com/uml/

[24] http://www.sap.com/bfw/

[25] http://www.selectst.com/component/nrg.htm

[26] http://www.sentrytech.com/smartjmp.htm

30