Common classes for a CASE environment provide CASE application developers wit h a description abo u t how a n application fits i n to the environ ment, the behav iors the appl ication must support, and the messages that resu lt in those behaviors. The notion of pl ug-ancl-play in the environment is achievecl t hrough the use of com mon classes. An i mplementation that ad heres to the descrip
tion of a particular class of appl ications can be
easily switched with a nother i mplementation that adheres to the same app l ication class semantics.
Programs l ike COHESION are working toward a set of common classes for CASE environments. The set currently defined conta ins classes for many types of data and applicatio ns found in CASE envi ronments focused on the cod i ng and testing phases of the software development process. A grap hical v iew of the data portion of the hierarchy is shown in Figure 5. The h ierarchy is partial ly based on the h ierarchy fo und in t\TIS, a standard fo r tool integra tion, and uti I izes the strength of the ATIS data model.r' (Shaded boxes indicate the classes that are specific to ATIS.) Encompassing the ATIS model, the h ierarchy presents a u n iform data model for the
CASE Integration U�ing ACA Services
integration of data throughout t he CASE environ ment. The set of classes, a lthough not exhaust ive, serves as a basis on which a CASE enviro nment can be built. Extensions of the hierarchy will occur as new classes of appl ications and their associated data objects are i ntegrated i n to the environment by independent software vendors, cuswmers, and other CASE vendors.
Most data classes are subclasses of the data class
SOURCE_FILE, because the i nitial data class i mple mentation was targeted at a CASE environment consisting of ed itors, compilers, builders, and ana lyzers. Additional data classes fo r both file and nonfile objects w i l l be added when appl ications that provide and man ipul ate these objects are
DATA OBJECT ELEMENT NAMED ELEMENT FILE CONTAINER DI RECTORY FILE D I R ECTORY
Note: Shaded boxes indicate ATtS-specific classes.
EXECUTABLE FILE
Figure .5 Hierarchy of CASE Common Data Classes
Application Control
integrated i n tO the environment. A number of data cl asses represent composite objects such as tests <md activities. These data classes are used to hide how the object is physical ly stored in the enviro n ment. Classes that represent composite objects have attributes with values that are :�ctualty other objects. For example, the test data c lass typica l l y has attributes that represent the resu l t of a rest run, a n operating system script or program used to per form the test, and a benchmark aga inst which a test run is compared . Each of these attributes may have as a value a reference to the file object that contains the actua l data .
The portion of the h ierarchy that is used to spec ify appl ication classes contains only abstract appl i cation c l asses, as shown in Figure 6. These c l asses provide structure, bu t more important, they define the operations that are i n herited by any appl ica tion that is a n instance of a class. Abstract cl asses are provided for a n umber of the appl ications found in
CASE environments that deal with the coding and resting fu nctions. The h ierarchy does not conta i n a n y classes t h a t represent particular instances o f an appl icarion. Suc h appl ication c lasses exist only when app l i cations are instal led in the environment.
Consistent Integration Interface
Many CASE vendors are b u i lding produ cts fo r a n umber of d ifferent environments, incl uding elec tronic p ubl ish i ng, office automation, compu ter aided design, and compu ter-aided manufa�tu ring, in addition to CASE. Therefore, vendors m ust decide how to integrate these applications in to the various
PERFORMANCE ANALYZER
environments. Until now, most i ntegration was accompl ished by l i nking one appl ication with another, which res u l ted in tigh t ly coupled appl ica t ions. However, such appl ications tend to be u nable to operate independent ly, without the other mem ber. Also, each coupled member tends to have its own appl icatio n programming interface (APT). I n tegrati o n perh>rmed in this m anner resu lts in an appl ic:�tion that must maintain code to surport mu ltiple APis, if the appl ication is to work in a num ber of environments. Such support can increase the maintenance cost and t he time and effort required to integrate witiJ other implementations of appl ica rions ami environments. Other by-products of this approach are an i ncreased image size and a need to rerelease software when a dependent appl ication changes. The degree to which rerelease occurs varies with the platform and operating system.
ACA Services can be used to mini mize the num ber of in terfaces t hat an appl ication must maintain withou t removing fu nctional ity; a common API prov ides the interface to a l l potential hmctionality. The ACA Services API, along with a set of com mon c lasses, a l lows the same level of i nteraction between appl ications that can be accompl ished through a pr ivate API, without the negat ive siue effects previously descri bed . Through the use of comm on classes, an appl. ication can in tegrate with multiple i mplementations of another app l ication without requiring a se parate effort for each . On platforms where uynamic load i ng of l i braries or shareable images are supported, applications can use ACA Services to locate the appropriate l i brary,
CONFIGU RATION MANAGER
OBJECT FILE CONVERTER
figure G
Hiemrcb)' of
CASECommon Applicotion Classes
fi nd the proper entry point, a nd transfer control to the appropriate rout i ne. ACA Serv ices also provides a transparen t mecha n ism fo r encapsu lating appl ica t ions that have no cal lable i nterfaces. Use of this mechan ism extends the n u mber of appl ications that can be i ntegrated and rem oves the need to develop operating system-specific code to start app l ications.