Integrating System Engineering

Software Tools

Edward Y Chow Hughes Aircraft Company

ABSTRACT

System engineering projects typically involve the use of a variety of design analysis simulation and management software tools that are home-grown or commercial-off-the-shelf (COTS) Very often these applications are hosted on dissimilar computing platforms in a network environment An application deployed on one platform may not be easily ported to another platform and it usually cannot be readily accessed by software on the other platform Enhancing the inter-operation among software applications or tools will greatly increase the effectiveness of the system engineering process The middleware technology currently being developed by the computer industry promises to provide the needed software interface for integrating tools across a heterogeneous computer network This paper discusses the experience of applying the middleware technology to software tools used in system engineering

INTRODUCTION

System engineering is a cross-functional activity that involves multiple disciplines such as reliability electrical engineering and mechanical engineering Generally each

Authorrsquos Current Address Hughes Aircraft Company MS RER07P539 PO Box 92426 Los Angeles CA 90009 USA

Based on a presentation at DASC rsquo97

0885-898598 $1000 0 1998 IEEE

discipline makes use of different design analysis simulation and management software both COTS and home-grown Furthermore computing platforms of various types (eg Persoinal Computers running Windows NT (PCNT) UNIX worlkstations and Macintosh computers) are employed in a system engineering environment Typically an application deployed on one platform cannot be easily accessed by software on another platform nor is it easily portable In order to enhance the effectiveness of system engineering the ability to make use of these diverse software tools in concert (ie tool inter-operability) is a necessity Tool inter-operability also encourages the re-use of existing tools hence reduces the overall product development effort

The cross-platform tool integration technology used to achieve inter-operability should possess two practical characteristics 1) the ability to incorporate legacy software and 2) be based on widely accepted standards The first characteristic is desirable because legacy software is likely to include well-tested and validated hence valuable tools As it is not practical to re-train all engineers who may develop tools in the latest software technology tools developed by engineers may continue for some time to resemble the legacy style The ability to integrate legacy software also ensures a method of incorporating these ldquonewrdquo tools In order to achieve the inter-operability among a large set of software it is important that the integration technology is based on the most widely adopted standards This we hope will lead to widespread software suplport of this technology especially among COTS products as well as a rich collection of training and educational materials on the subject

IEEE AES Systems Magazine November I998 3

m UNIX

lsquo Legacy applications

L J

applications)

- connections being developed

Fig 1 Tool Integration Using Middleware

MIDDLEWARE

PUNT

c

CORBA objects J (applications)

OLE brokers

L

- 7 1 applications

The middleware technology currently being developed by the computer industry promises to provide the software interface with these two characteristics while enabling each piece of software to easily play the role of a ldquoserverrdquo or a ldquoclientrdquo across a heterogeneous computer network Although the middleware technology has not matured completely it holds a significant promise for system engineering In the following sections we will briefly describe the middleware employed and the preliminary results of our tool integration effort Finally we will discuss the issues related to tool integration that remain to be explored

Middleware has been described as ldquosoftware that resides in the middle between an application program and the base operating systems databases and networking functions of a computer systemrdquo [l] As such it makes all the operating system and communication details transparent to the applications developer For example it takes care of data format translation without the developerrsquos conscious effort The Object Request Broker (ORB) is a type of middleware that enables objects distributed over a network (eg client and server applications) to operate together Currently there are two widely-used standards for ORBrsquoS One is the Common Object Request Broker Architecture (CORBA) [ 2 3 ] developed by the Object Management Group (OMG) Another is the Component Object Model (COM) [45] offered by Microsoft COM was initially developed for a single platform but was recently extended to the cross-platform case as Distributed COM (DCOM) [5] The two standards CORBA and DCOM represent different approaches and their pros and cons are debated in numerous forums for example see [36] However from a userrsquos point of view a few observations are notable

1 CORBA is a standard developed by the OMG a consortium of over 500 member organizations

2 Several CORBA products (development and runtime software) are available from different vendors for a variety of platforms including UNIX and Windows 95NT systems

3 COM and DCOM are available free of charge with the Windows 95NT operating systems Several Microsoft applications such as Excel Word and Visual Basic etc already support this standard

Windows 95NT platforms 4 Currently COMDCOM are only available for the

It is clear that both CORBA and DCOM enjoy broad support For the former it is in the sense of a large number of organizations that potentially would develop CORBA products For the latter it is in the sense that there is a large installed base of Windows platforms and Microsoft already has a number of popular applications supporting its standard The fact that both UNIX workstations and Pclsquos are important elements of a system engineering environment makes the standard selection simple That is both must be accommodated Fortunately OMG has standardized on an approach to integrating CORBA with OLE automationrsquo Several members including IONA Technologies Inc and Expersoft Corporation have provided products that automate this integration For the tool integration described in this paper we have selected IONA

rsquo OLE and ActiveX may be viewed as functionalities that are based on the COM technology DCOM is the extension of COM to the distributed environment Unfortunately Microsoft has been the main source of the confusion among these terms [ 5 ] In the open literature OLE objects COM objects and ActiveX components often refer to similar entities

4 IEEE AES Systems Magazine November 1998

Technologiesrsquo Orbix [7] (for UNIX) and Orbix Desktop (for Windows 95NT with support for the CORBA-OLE integration) [SI

Before we proceed to describe our integration example it is worthwhile to discuss briefly an alternative to both CORBA and DCOM This is the Java technology that has taken the software industry by storm in the past two years It has the appeal of ldquowrite-once run anywhererdquo and it would work very well with the World Wide Web Java in conjunction with the recently released Remote Method Invocation (RMI) could be a ldquo100 pure Javardquo candidate framework for distributed computing Unfortunately RMI was not mature enough so that the Java alternative would still rely on CORBA See [9] for a discussion of the roles of CORBA and Java in distributed computing The Java alternative was not adopted here pending further advances in the technology

TOOL INTEGRATION

Analysis and requirements management are two important tasks of system engineering In this study we have chosen to integrate tools used for these tasks Specifically we are interested in connecting analysis applications that are developed and deployed for UNIX and PC platforms Furthermore we would like to link analysis to a requirements management system eg we would like to automate the capture of requirement parameters generated by analysis applications into the requirements database The applications involved are home-grown analysis tools for the UNIX workstation Microsoft Excel for the PC and DOORS2 [lo] a requirements management application developed by Quality Systems and Software Inc (QSS) The UNIX tools are of the legacy variety Excel is only COM compliant and DOORS is advertised to support OLE automation IONA Technologiesrsquo Orbix product is used to provide the connection across platforms (via CORBA) and the bridge between CORBA and COM The tool integration project is depicted in Figure 1 on previous page The heavy lines denote the connections being developed A CORBA wrapper can be viewed as a software layer that provides a CORBA compliant interface to a legacy application An OLE broker is a program that in effect translates an interface between the CORBA and COM standards (OLE applications denote applications that support OLE automation) Both the wrappers and the brokers can be constructed using the Orbix development software (in conjunction with a C+ + compiler on the UNIX platform or Microsoft Visual C+ + and Visual Basic on the PC) in a straightforward manner

CORBA wrappers and OLE brokers were developed for home-grown legacy UNIX applications Microsoft Excel and other PC programs They proved to

DOORS stands for Dynamic Object Oriented Requirements System

be effective in providing the connection between the UNIX tools and Excel across the network With these wrappers and brokers UNIX tools can easily invoke an Excel model pass it the required inputs and receive the analysis results In the reverse direction PC programs can call legacy UNIX applications across the network No software porting was invlolved The only code development required was for the wrappers and brokers which are much simpler than a code porting effort

effort First the relative ease in connecting applications across dissimilar platforrns will facilitate software re-use Second tool inter-operability is feasible in a heterogeneous environment one that consists of dissimilar platforms and a range of diverse software sophistication (eg from legacy to modern programming styles) This has an important practical consequence In carrying out their tasks engineers often develop software tools to aid their design and analysis These tools are typically developed using the available resources computer systems and software that are most familiar to the engineers The use of middleware for tool integration eliminates the urgency in training engineers in a specific software technology which is likelly to be unfamiliar to them because their expertise lies in mechanical engineering and electrical engineering and not in software engineering As a result productivity of engineers can be maintained while the added benefits of intier-operable tools are realized In many cases these benefits can out-weigh the relative inefficiency of this tool clonnection approach when compared to ldquotightrdquo integration An example of a tighter tool integration in our case would be the porting of the Excel models to C+ + code for the UNIX platform the network communication is eliminated and the C+ + code can be optimized to execute more rapidly than the Excel models

applications and Excel the integration with the released version (31) of DOORS was less encouraging The most serious difficulty stems from the lack of support of parameter passing with DOORS acting as an OLE automation server Due to this limitation it is not possible to automate the capture of analysis results into DOORSrsquo database or the extraction of requirements parameters from the database via the COM standard However the beta release of the new version (40) provides a string property that can be accessed by a client application With this string other data types ie integer and real can be effectively passed between DOORS and its clients But this approach is rather inefficient since the data needs to be encoded and decoded during every exchange Our experience brings out a very important point - inter-operability among COTS applications relies heavily on their support of common connection standards (ie CORBA or COMDCOM) and the effectiveness of the inter-operation depends on the functionality provided through the connection standard

This result is significant for our tool integration

While we had success in connecting our legacy

IEEEAES Systems Magazine November I998 5

DISCUSSION

Although our effort in system engineering tool integration is preliminary the experience we gained is very positive It is evident that the use of ORBrsquos holds significant promise for achieving inter-operability among home-grown and COTS applications However many issues remain to be examined and resolved before tool inter-operability becomes a widespread reality The issues can be grouped into two categories those relevant to the development of ORBrsquos and COTS applications and those related to the deployment of this software in the engineering community Some examples are discussed briefly below

Development Issues In addition to the basic ORB functionality the

OMG also defined numerous services to be made available with the ORB [23] eg the naming and security services A naming service allows an object connected to the ORB to locate other available objects (applications or tools) This is especially useful when the number of objects that can be connected are distributed over a large network The security service is also important particularly in a large organization where object access control and data integrity management can be quite complex Not all of these services are implemented in currently available CORBA products It is important that (CORBA) ORB vendors continue to commit to providing these services in a timely manner At the same time it is also crucial for COTS application developers to support the ORB standards (CORBA or COMDCOM) and provide access to their Application Programming Interfaces (MIrsquoS) through these ORB standards

Deployment Issues A successful deployment of the middleware

technology for tool integration requires careful planning Example issues to be considered include the type of ORB services to be implemented load distribution object configuration management and licensing cost Among the services specified to be provided by the ORBrsquos it is likely that only a properly chosen subset will deliver the most cost effective ORB for each situation As objects (tools) become available they raise the issue of load balancing among compatible platforms A simple aspect of the question here is Should an object be hosted on the developerrsquos platform or should it be hosted on a special ldquoserverrdquo platform The former alternative tends to distribute the computing load whereas the latter tends to concentrate it A specific solution possibly a combination of the above possibilities designed to deliver a certain cost-performance compromise is likely required for each engineering environment As objects are developed and updated a configuration management policy and accompanying method is clearly required

Lastly the cost of deploying the technology also deserves careful consideration The most obvious cost component is licensing In a system engineering community it is possible for many engineers to be tool developers some of the time That is in the natural course of solving problems tools are developed There are few dedicated tool-smiths Currently CORBA development license costs are typically on the order of thousands of dollars At this price it is cost prohibitive to assign each engineer a license A practical compromise based on an efficient procedure of sharing licenses or perhaps a modification of the licensing fee structure is needed

applying middleware technology to integrate software tools used for system engineering Several issues related to the application of this technology are also discussed Many more issues and challenges are likely to be uncovered as we continue to deploy this technology Cooperation among ORB vendors COTS application developers and the end users (engineering community) is necessary to overcome these challenges in reaching practical and affordable solutions

REFERENCES

In summary this paper reports our experience in

[l] Doug Goddard May 1996

Data Based Advisor How Middleware Can Help Your Enterprise

[2] CORBA 20 IIOP Specifcation July 1996 The Object Management Group (OMG)

available online at httpwwwomgorgcorbacorbaiiophtm [3] Robert Orfali Dan Harkey and Jeri Edwards 1996

The Essential Distributed Objects Survival Guide Wiley New York

[4] The Component Object Model Specification Draft Version 09

available online at httpwwvmicrosoftcom oledevolecomtitle htm

Understanding ActiveXand OLE

Microsoft Corporation October 24 1995

[5] David Chappell 1996

Microsoft Press

[6] Mark Roy and Alan Ewald October 1996 Choosing between CORBA and DCOM

Distributed Objects

IONA Technologies Inc [7] The Orbin Architecture November 1996

available online at httpwwwionacomProducts OrbixArchitectureindex html

[8] Orbinfor Wndows IONA Technologies Inc

available online at httplwwwionacomProducts OrbixWindowsWhitePaper html

[9] Kurt Wallnau Nelson Weiderman and Linda Northrop June 1997

Distributed Object Technology with CORBA and Java Key Concepts and Implications

Software Engineering Institute Technical Report CMUSEI-97-TR-004 Carnegie Mellon University

[lo] Introduction to DOORS Quality Systems and Software Inc available online at httpwwwqssinccomDOORSoverviewhtml

6 IEEE AES Systems Magazine November 1998

m UNIX

lsquo Legacy applications

L J

applications)

- connections being developed

Fig 1 Tool Integration Using Middleware

MIDDLEWARE

PUNT

c

CORBA objects J (applications)

OLE brokers

L

- 7 1 applications

The middleware technology currently being developed by the computer industry promises to provide the software interface with these two characteristics while enabling each piece of software to easily play the role of a ldquoserverrdquo or a ldquoclientrdquo across a heterogeneous computer network Although the middleware technology has not matured completely it holds a significant promise for system engineering In the following sections we will briefly describe the middleware employed and the preliminary results of our tool integration effort Finally we will discuss the issues related to tool integration that remain to be explored

Middleware has been described as ldquosoftware that resides in the middle between an application program and the base operating systems databases and networking functions of a computer systemrdquo [l] As such it makes all the operating system and communication details transparent to the applications developer For example it takes care of data format translation without the developerrsquos conscious effort The Object Request Broker (ORB) is a type of middleware that enables objects distributed over a network (eg client and server applications) to operate together Currently there are two widely-used standards for ORBrsquoS One is the Common Object Request Broker Architecture (CORBA) [ 2 3 ] developed by the Object Management Group (OMG) Another is the Component Object Model (COM) [45] offered by Microsoft COM was initially developed for a single platform but was recently extended to the cross-platform case as Distributed COM (DCOM) [5] The two standards CORBA and DCOM represent different approaches and their pros and cons are debated in numerous forums for example see [36] However from a userrsquos point of view a few observations are notable

1 CORBA is a standard developed by the OMG a consortium of over 500 member organizations

2 Several CORBA products (development and runtime software) are available from different vendors for a variety of platforms including UNIX and Windows 95NT systems

3 COM and DCOM are available free of charge with the Windows 95NT operating systems Several Microsoft applications such as Excel Word and Visual Basic etc already support this standard

Windows 95NT platforms 4 Currently COMDCOM are only available for the

It is clear that both CORBA and DCOM enjoy broad support For the former it is in the sense of a large number of organizations that potentially would develop CORBA products For the latter it is in the sense that there is a large installed base of Windows platforms and Microsoft already has a number of popular applications supporting its standard The fact that both UNIX workstations and Pclsquos are important elements of a system engineering environment makes the standard selection simple That is both must be accommodated Fortunately OMG has standardized on an approach to integrating CORBA with OLE automationrsquo Several members including IONA Technologies Inc and Expersoft Corporation have provided products that automate this integration For the tool integration described in this paper we have selected IONA

rsquo OLE and ActiveX may be viewed as functionalities that are based on the COM technology DCOM is the extension of COM to the distributed environment Unfortunately Microsoft has been the main source of the confusion among these terms [ 5 ] In the open literature OLE objects COM objects and ActiveX components often refer to similar entities

4 IEEE AES Systems Magazine November 1998

Technologiesrsquo Orbix [7] (for UNIX) and Orbix Desktop (for Windows 95NT with support for the CORBA-OLE integration) [SI

Before we proceed to describe our integration example it is worthwhile to discuss briefly an alternative to both CORBA and DCOM This is the Java technology that has taken the software industry by storm in the past two years It has the appeal of ldquowrite-once run anywhererdquo and it would work very well with the World Wide Web Java in conjunction with the recently released Remote Method Invocation (RMI) could be a ldquo100 pure Javardquo candidate framework for distributed computing Unfortunately RMI was not mature enough so that the Java alternative would still rely on CORBA See [9] for a discussion of the roles of CORBA and Java in distributed computing The Java alternative was not adopted here pending further advances in the technology

TOOL INTEGRATION

Analysis and requirements management are two important tasks of system engineering In this study we have chosen to integrate tools used for these tasks Specifically we are interested in connecting analysis applications that are developed and deployed for UNIX and PC platforms Furthermore we would like to link analysis to a requirements management system eg we would like to automate the capture of requirement parameters generated by analysis applications into the requirements database The applications involved are home-grown analysis tools for the UNIX workstation Microsoft Excel for the PC and DOORS2 [lo] a requirements management application developed by Quality Systems and Software Inc (QSS) The UNIX tools are of the legacy variety Excel is only COM compliant and DOORS is advertised to support OLE automation IONA Technologiesrsquo Orbix product is used to provide the connection across platforms (via CORBA) and the bridge between CORBA and COM The tool integration project is depicted in Figure 1 on previous page The heavy lines denote the connections being developed A CORBA wrapper can be viewed as a software layer that provides a CORBA compliant interface to a legacy application An OLE broker is a program that in effect translates an interface between the CORBA and COM standards (OLE applications denote applications that support OLE automation) Both the wrappers and the brokers can be constructed using the Orbix development software (in conjunction with a C+ + compiler on the UNIX platform or Microsoft Visual C+ + and Visual Basic on the PC) in a straightforward manner

CORBA wrappers and OLE brokers were developed for home-grown legacy UNIX applications Microsoft Excel and other PC programs They proved to

DOORS stands for Dynamic Object Oriented Requirements System

be effective in providing the connection between the UNIX tools and Excel across the network With these wrappers and brokers UNIX tools can easily invoke an Excel model pass it the required inputs and receive the analysis results In the reverse direction PC programs can call legacy UNIX applications across the network No software porting was invlolved The only code development required was for the wrappers and brokers which are much simpler than a code porting effort

effort First the relative ease in connecting applications across dissimilar platforrns will facilitate software re-use Second tool inter-operability is feasible in a heterogeneous environment one that consists of dissimilar platforms and a range of diverse software sophistication (eg from legacy to modern programming styles) This has an important practical consequence In carrying out their tasks engineers often develop software tools to aid their design and analysis These tools are typically developed using the available resources computer systems and software that are most familiar to the engineers The use of middleware for tool integration eliminates the urgency in training engineers in a specific software technology which is likelly to be unfamiliar to them because their expertise lies in mechanical engineering and electrical engineering and not in software engineering As a result productivity of engineers can be maintained while the added benefits of intier-operable tools are realized In many cases these benefits can out-weigh the relative inefficiency of this tool clonnection approach when compared to ldquotightrdquo integration An example of a tighter tool integration in our case would be the porting of the Excel models to C+ + code for the UNIX platform the network communication is eliminated and the C+ + code can be optimized to execute more rapidly than the Excel models

applications and Excel the integration with the released version (31) of DOORS was less encouraging The most serious difficulty stems from the lack of support of parameter passing with DOORS acting as an OLE automation server Due to this limitation it is not possible to automate the capture of analysis results into DOORSrsquo database or the extraction of requirements parameters from the database via the COM standard However the beta release of the new version (40) provides a string property that can be accessed by a client application With this string other data types ie integer and real can be effectively passed between DOORS and its clients But this approach is rather inefficient since the data needs to be encoded and decoded during every exchange Our experience brings out a very important point - inter-operability among COTS applications relies heavily on their support of common connection standards (ie CORBA or COMDCOM) and the effectiveness of the inter-operation depends on the functionality provided through the connection standard

This result is significant for our tool integration

While we had success in connecting our legacy

IEEEAES Systems Magazine November I998 5

DISCUSSION

Although our effort in system engineering tool integration is preliminary the experience we gained is very positive It is evident that the use of ORBrsquos holds significant promise for achieving inter-operability among home-grown and COTS applications However many issues remain to be examined and resolved before tool inter-operability becomes a widespread reality The issues can be grouped into two categories those relevant to the development of ORBrsquos and COTS applications and those related to the deployment of this software in the engineering community Some examples are discussed briefly below

Development Issues In addition to the basic ORB functionality the

OMG also defined numerous services to be made available with the ORB [23] eg the naming and security services A naming service allows an object connected to the ORB to locate other available objects (applications or tools) This is especially useful when the number of objects that can be connected are distributed over a large network The security service is also important particularly in a large organization where object access control and data integrity management can be quite complex Not all of these services are implemented in currently available CORBA products It is important that (CORBA) ORB vendors continue to commit to providing these services in a timely manner At the same time it is also crucial for COTS application developers to support the ORB standards (CORBA or COMDCOM) and provide access to their Application Programming Interfaces (MIrsquoS) through these ORB standards

Deployment Issues A successful deployment of the middleware

technology for tool integration requires careful planning Example issues to be considered include the type of ORB services to be implemented load distribution object configuration management and licensing cost Among the services specified to be provided by the ORBrsquos it is likely that only a properly chosen subset will deliver the most cost effective ORB for each situation As objects (tools) become available they raise the issue of load balancing among compatible platforms A simple aspect of the question here is Should an object be hosted on the developerrsquos platform or should it be hosted on a special ldquoserverrdquo platform The former alternative tends to distribute the computing load whereas the latter tends to concentrate it A specific solution possibly a combination of the above possibilities designed to deliver a certain cost-performance compromise is likely required for each engineering environment As objects are developed and updated a configuration management policy and accompanying method is clearly required

Lastly the cost of deploying the technology also deserves careful consideration The most obvious cost component is licensing In a system engineering community it is possible for many engineers to be tool developers some of the time That is in the natural course of solving problems tools are developed There are few dedicated tool-smiths Currently CORBA development license costs are typically on the order of thousands of dollars At this price it is cost prohibitive to assign each engineer a license A practical compromise based on an efficient procedure of sharing licenses or perhaps a modification of the licensing fee structure is needed

applying middleware technology to integrate software tools used for system engineering Several issues related to the application of this technology are also discussed Many more issues and challenges are likely to be uncovered as we continue to deploy this technology Cooperation among ORB vendors COTS application developers and the end users (engineering community) is necessary to overcome these challenges in reaching practical and affordable solutions

REFERENCES

In summary this paper reports our experience in

[l] Doug Goddard May 1996

Data Based Advisor How Middleware Can Help Your Enterprise

[2] CORBA 20 IIOP Specifcation July 1996 The Object Management Group (OMG)

available online at httpwwwomgorgcorbacorbaiiophtm [3] Robert Orfali Dan Harkey and Jeri Edwards 1996

The Essential Distributed Objects Survival Guide Wiley New York

[4] The Component Object Model Specification Draft Version 09

available online at httpwwvmicrosoftcom oledevolecomtitle htm

Understanding ActiveXand OLE

Microsoft Corporation October 24 1995

[5] David Chappell 1996

Microsoft Press

[6] Mark Roy and Alan Ewald October 1996 Choosing between CORBA and DCOM

Distributed Objects

IONA Technologies Inc [7] The Orbin Architecture November 1996

available online at httpwwwionacomProducts OrbixArchitectureindex html

[8] Orbinfor Wndows IONA Technologies Inc

available online at httplwwwionacomProducts OrbixWindowsWhitePaper html

[9] Kurt Wallnau Nelson Weiderman and Linda Northrop June 1997

Distributed Object Technology with CORBA and Java Key Concepts and Implications

Software Engineering Institute Technical Report CMUSEI-97-TR-004 Carnegie Mellon University

[lo] Introduction to DOORS Quality Systems and Software Inc available online at httpwwwqssinccomDOORSoverviewhtml

6 IEEE AES Systems Magazine November 1998

Technologiesrsquo Orbix [7] (for UNIX) and Orbix Desktop (for Windows 95NT with support for the CORBA-OLE integration) [SI

Before we proceed to describe our integration example it is worthwhile to discuss briefly an alternative to both CORBA and DCOM This is the Java technology that has taken the software industry by storm in the past two years It has the appeal of ldquowrite-once run anywhererdquo and it would work very well with the World Wide Web Java in conjunction with the recently released Remote Method Invocation (RMI) could be a ldquo100 pure Javardquo candidate framework for distributed computing Unfortunately RMI was not mature enough so that the Java alternative would still rely on CORBA See [9] for a discussion of the roles of CORBA and Java in distributed computing The Java alternative was not adopted here pending further advances in the technology

TOOL INTEGRATION

Analysis and requirements management are two important tasks of system engineering In this study we have chosen to integrate tools used for these tasks Specifically we are interested in connecting analysis applications that are developed and deployed for UNIX and PC platforms Furthermore we would like to link analysis to a requirements management system eg we would like to automate the capture of requirement parameters generated by analysis applications into the requirements database The applications involved are home-grown analysis tools for the UNIX workstation Microsoft Excel for the PC and DOORS2 [lo] a requirements management application developed by Quality Systems and Software Inc (QSS) The UNIX tools are of the legacy variety Excel is only COM compliant and DOORS is advertised to support OLE automation IONA Technologiesrsquo Orbix product is used to provide the connection across platforms (via CORBA) and the bridge between CORBA and COM The tool integration project is depicted in Figure 1 on previous page The heavy lines denote the connections being developed A CORBA wrapper can be viewed as a software layer that provides a CORBA compliant interface to a legacy application An OLE broker is a program that in effect translates an interface between the CORBA and COM standards (OLE applications denote applications that support OLE automation) Both the wrappers and the brokers can be constructed using the Orbix development software (in conjunction with a C+ + compiler on the UNIX platform or Microsoft Visual C+ + and Visual Basic on the PC) in a straightforward manner

CORBA wrappers and OLE brokers were developed for home-grown legacy UNIX applications Microsoft Excel and other PC programs They proved to

DOORS stands for Dynamic Object Oriented Requirements System

be effective in providing the connection between the UNIX tools and Excel across the network With these wrappers and brokers UNIX tools can easily invoke an Excel model pass it the required inputs and receive the analysis results In the reverse direction PC programs can call legacy UNIX applications across the network No software porting was invlolved The only code development required was for the wrappers and brokers which are much simpler than a code porting effort

effort First the relative ease in connecting applications across dissimilar platforrns will facilitate software re-use Second tool inter-operability is feasible in a heterogeneous environment one that consists of dissimilar platforms and a range of diverse software sophistication (eg from legacy to modern programming styles) This has an important practical consequence In carrying out their tasks engineers often develop software tools to aid their design and analysis These tools are typically developed using the available resources computer systems and software that are most familiar to the engineers The use of middleware for tool integration eliminates the urgency in training engineers in a specific software technology which is likelly to be unfamiliar to them because their expertise lies in mechanical engineering and electrical engineering and not in software engineering As a result productivity of engineers can be maintained while the added benefits of intier-operable tools are realized In many cases these benefits can out-weigh the relative inefficiency of this tool clonnection approach when compared to ldquotightrdquo integration An example of a tighter tool integration in our case would be the porting of the Excel models to C+ + code for the UNIX platform the network communication is eliminated and the C+ + code can be optimized to execute more rapidly than the Excel models

applications and Excel the integration with the released version (31) of DOORS was less encouraging The most serious difficulty stems from the lack of support of parameter passing with DOORS acting as an OLE automation server Due to this limitation it is not possible to automate the capture of analysis results into DOORSrsquo database or the extraction of requirements parameters from the database via the COM standard However the beta release of the new version (40) provides a string property that can be accessed by a client application With this string other data types ie integer and real can be effectively passed between DOORS and its clients But this approach is rather inefficient since the data needs to be encoded and decoded during every exchange Our experience brings out a very important point - inter-operability among COTS applications relies heavily on their support of common connection standards (ie CORBA or COMDCOM) and the effectiveness of the inter-operation depends on the functionality provided through the connection standard

This result is significant for our tool integration

While we had success in connecting our legacy

IEEEAES Systems Magazine November I998 5

DISCUSSION

Although our effort in system engineering tool integration is preliminary the experience we gained is very positive It is evident that the use of ORBrsquos holds significant promise for achieving inter-operability among home-grown and COTS applications However many issues remain to be examined and resolved before tool inter-operability becomes a widespread reality The issues can be grouped into two categories those relevant to the development of ORBrsquos and COTS applications and those related to the deployment of this software in the engineering community Some examples are discussed briefly below

Development Issues In addition to the basic ORB functionality the

OMG also defined numerous services to be made available with the ORB [23] eg the naming and security services A naming service allows an object connected to the ORB to locate other available objects (applications or tools) This is especially useful when the number of objects that can be connected are distributed over a large network The security service is also important particularly in a large organization where object access control and data integrity management can be quite complex Not all of these services are implemented in currently available CORBA products It is important that (CORBA) ORB vendors continue to commit to providing these services in a timely manner At the same time it is also crucial for COTS application developers to support the ORB standards (CORBA or COMDCOM) and provide access to their Application Programming Interfaces (MIrsquoS) through these ORB standards

Deployment Issues A successful deployment of the middleware

technology for tool integration requires careful planning Example issues to be considered include the type of ORB services to be implemented load distribution object configuration management and licensing cost Among the services specified to be provided by the ORBrsquos it is likely that only a properly chosen subset will deliver the most cost effective ORB for each situation As objects (tools) become available they raise the issue of load balancing among compatible platforms A simple aspect of the question here is Should an object be hosted on the developerrsquos platform or should it be hosted on a special ldquoserverrdquo platform The former alternative tends to distribute the computing load whereas the latter tends to concentrate it A specific solution possibly a combination of the above possibilities designed to deliver a certain cost-performance compromise is likely required for each engineering environment As objects are developed and updated a configuration management policy and accompanying method is clearly required

Lastly the cost of deploying the technology also deserves careful consideration The most obvious cost component is licensing In a system engineering community it is possible for many engineers to be tool developers some of the time That is in the natural course of solving problems tools are developed There are few dedicated tool-smiths Currently CORBA development license costs are typically on the order of thousands of dollars At this price it is cost prohibitive to assign each engineer a license A practical compromise based on an efficient procedure of sharing licenses or perhaps a modification of the licensing fee structure is needed

applying middleware technology to integrate software tools used for system engineering Several issues related to the application of this technology are also discussed Many more issues and challenges are likely to be uncovered as we continue to deploy this technology Cooperation among ORB vendors COTS application developers and the end users (engineering community) is necessary to overcome these challenges in reaching practical and affordable solutions

REFERENCES

In summary this paper reports our experience in

[l] Doug Goddard May 1996

Data Based Advisor How Middleware Can Help Your Enterprise

[2] CORBA 20 IIOP Specifcation July 1996 The Object Management Group (OMG)

available online at httpwwwomgorgcorbacorbaiiophtm [3] Robert Orfali Dan Harkey and Jeri Edwards 1996

The Essential Distributed Objects Survival Guide Wiley New York

[4] The Component Object Model Specification Draft Version 09

available online at httpwwvmicrosoftcom oledevolecomtitle htm

Understanding ActiveXand OLE

Microsoft Corporation October 24 1995

[5] David Chappell 1996

Microsoft Press

[6] Mark Roy and Alan Ewald October 1996 Choosing between CORBA and DCOM

Distributed Objects

IONA Technologies Inc [7] The Orbin Architecture November 1996

available online at httpwwwionacomProducts OrbixArchitectureindex html

[8] Orbinfor Wndows IONA Technologies Inc

available online at httplwwwionacomProducts OrbixWindowsWhitePaper html

[9] Kurt Wallnau Nelson Weiderman and Linda Northrop June 1997

Distributed Object Technology with CORBA and Java Key Concepts and Implications

Software Engineering Institute Technical Report CMUSEI-97-TR-004 Carnegie Mellon University

[lo] Introduction to DOORS Quality Systems and Software Inc available online at httpwwwqssinccomDOORSoverviewhtml

6 IEEE AES Systems Magazine November 1998

DISCUSSION

Although our effort in system engineering tool integration is preliminary the experience we gained is very positive It is evident that the use of ORBrsquos holds significant promise for achieving inter-operability among home-grown and COTS applications However many issues remain to be examined and resolved before tool inter-operability becomes a widespread reality The issues can be grouped into two categories those relevant to the development of ORBrsquos and COTS applications and those related to the deployment of this software in the engineering community Some examples are discussed briefly below

Development Issues In addition to the basic ORB functionality the

OMG also defined numerous services to be made available with the ORB [23] eg the naming and security services A naming service allows an object connected to the ORB to locate other available objects (applications or tools) This is especially useful when the number of objects that can be connected are distributed over a large network The security service is also important particularly in a large organization where object access control and data integrity management can be quite complex Not all of these services are implemented in currently available CORBA products It is important that (CORBA) ORB vendors continue to commit to providing these services in a timely manner At the same time it is also crucial for COTS application developers to support the ORB standards (CORBA or COMDCOM) and provide access to their Application Programming Interfaces (MIrsquoS) through these ORB standards

Deployment Issues A successful deployment of the middleware

technology for tool integration requires careful planning Example issues to be considered include the type of ORB services to be implemented load distribution object configuration management and licensing cost Among the services specified to be provided by the ORBrsquos it is likely that only a properly chosen subset will deliver the most cost effective ORB for each situation As objects (tools) become available they raise the issue of load balancing among compatible platforms A simple aspect of the question here is Should an object be hosted on the developerrsquos platform or should it be hosted on a special ldquoserverrdquo platform The former alternative tends to distribute the computing load whereas the latter tends to concentrate it A specific solution possibly a combination of the above possibilities designed to deliver a certain cost-performance compromise is likely required for each engineering environment As objects are developed and updated a configuration management policy and accompanying method is clearly required

Lastly the cost of deploying the technology also deserves careful consideration The most obvious cost component is licensing In a system engineering community it is possible for many engineers to be tool developers some of the time That is in the natural course of solving problems tools are developed There are few dedicated tool-smiths Currently CORBA development license costs are typically on the order of thousands of dollars At this price it is cost prohibitive to assign each engineer a license A practical compromise based on an efficient procedure of sharing licenses or perhaps a modification of the licensing fee structure is needed

applying middleware technology to integrate software tools used for system engineering Several issues related to the application of this technology are also discussed Many more issues and challenges are likely to be uncovered as we continue to deploy this technology Cooperation among ORB vendors COTS application developers and the end users (engineering community) is necessary to overcome these challenges in reaching practical and affordable solutions

REFERENCES

In summary this paper reports our experience in

[l] Doug Goddard May 1996

Data Based Advisor How Middleware Can Help Your Enterprise

[2] CORBA 20 IIOP Specifcation July 1996 The Object Management Group (OMG)

available online at httpwwwomgorgcorbacorbaiiophtm [3] Robert Orfali Dan Harkey and Jeri Edwards 1996

The Essential Distributed Objects Survival Guide Wiley New York

[4] The Component Object Model Specification Draft Version 09

available online at httpwwvmicrosoftcom oledevolecomtitle htm

Understanding ActiveXand OLE

Microsoft Corporation October 24 1995

[5] David Chappell 1996

Microsoft Press

[6] Mark Roy and Alan Ewald October 1996 Choosing between CORBA and DCOM

Distributed Objects

IONA Technologies Inc [7] The Orbin Architecture November 1996

available online at httpwwwionacomProducts OrbixArchitectureindex html

[8] Orbinfor Wndows IONA Technologies Inc

available online at httplwwwionacomProducts OrbixWindowsWhitePaper html

[9] Kurt Wallnau Nelson Weiderman and Linda Northrop June 1997

Distributed Object Technology with CORBA and Java Key Concepts and Implications

Software Engineering Institute Technical Report CMUSEI-97-TR-004 Carnegie Mellon University

[lo] Introduction to DOORS Quality Systems and Software Inc available online at httpwwwqssinccomDOORSoverviewhtml

6 IEEE AES Systems Magazine November 1998