4 u ; | Se. | PC WEEKNAPPLICATION DEVELOPMENT [ Puse 48 JANUARY 30, 1969 Mik, A Distributed Architecture Helps Integrate CASE Tools This, the fourth of a six- computer-aided a CASE) technolo- gy, eramines the architecture of -an I-CASE tool. € As discussed in last week's col- umn, ECASE tools can support b /— the full life-cycle process of a computer system, from planning, analysis and design to code ,,.; generation and maintenance. '' | '; 'The architecture of I-CASE tools typi- -' cally consists of PC-based, frontrend frame-based, back-end code and data-' base generators. The front-end ia workstations are used for planning, ''' ' analysis and design functions. The back- generation, documentation generation, database generation and project-man: agement aids. pečat Analysts using front-end CASE tools ' must be able to get a fast response fro: their own workstation, and, to provide local completeness and consistency ' checking, there should be an encyclope- dia and knowledge coordinator in that. workstation. era teli ' 'Coordinating the computerized know edge base across a large development o: substantial computing power and is lik: ly to be done on the machine that con: trols the central encyclopedia. A distri uted architecture is thus desirable.! " — the architecture of a typical multitiered cal area networks, departmental mini computers and corporate mainframes. Each PC workstation contains a local encyclopedia and knowledge coordina- the information provided by different -tools used by the developer. The depart- knowledge coordinator that in turn en: sures consistency among ' different developers. set of objects, duplicating them into his or her own encyclopedia. From that point, the developer can work with the duplicate set and create new informa: tion that's coordinated in the work- oped by individual analysta. J end system supports automatic code ,'': information-engineering effort reguires "" ib-' 'The accompanying illustration shows ib system consisting of PCs organized in lo:' tor, thereby ensuring consistency among "' mental minicomputer or mainframe con- ' tains a central encyclopedia with a ''' the work of: From the central encyclopedia, the de- veloper can check out a hyperview, or a |! An eneyclopedia at the minicomputer level can be used to accumulate and an- alyze design specifications for an entire project. Design information that is to be shared across an entire organization, such as enterprise models, data models and process models, can be stored in a corporate eneyclopedia at the main: frame level. ee Building and integrating the informa- tion systems needed in an enterprise are achieved by synthesizing the models and designs of many people throughout the enterprise. | ' 'ilj' uka CASE tools with a central encyclope- dia make this possible. The amount and complexity of information in an enter- - prise is so great that synthesis is almost already in the encyclopedia. The designer thus extracts informa- tion from the central encyclopedia into his local encyclopedia, works on it in the local environment and then inte- grates it with the knowledge in the cen- tral encyclopedia. When the design is coordinated and approved, it will reside in the central encyclopedia and may affect the work of other designers. There may be many local eneyclopedias all being used in conjunetion with the central eneyclo- pedia. The central encyclopedia contains many hyperviews that may overlap. In other words, they use many common ob- jects and employ data derived from a Distributed Architecture workstations tightly coupled to main: External LAN External Information Sources ee moji nu |. Cooi tist 1 | pv ji Ma be ASI dy ped ira the developer then checks it back designs in rpject: into the central where it is. et S dieti Li ek se ted with central information. When the individual starts to create a That's how consistency is achieved design, he or she will extract whatever across a large project or multiple , information in the central encyclopedia project lani t |, relates to the design. For example, some- ' 'The figure shows the different levels that's already shown in a igh ! of ency' that, can be supported '' represeni in a multitiered architecture. Local ency- | a data Glopedias at the PC level are used to "on the | store and analyze specifications devel. /' for review, it can be a nag. me Na az bavi 7 ' impossible unless computerized, too (used, |" ls nike ia pomi " Normally, any individual or design | team is unfamiliar with the entire set o£ : systems. Ra Corpotate Ericyelopedia ing the computerized knowledge base across a large development or information-engineering | ed]ort is best done with a distributed architecture. 7 : ui common data model. 'The objective is to achieve as much internal consistency as possible in the knowledge stored in the encyelopedia. In a large organization, complete consisten- ey is unlikely to be achieved, early in tne evolution of CASE built The methodology and CASE tools need to be designed to enable an enter- |, prise to work toward consistency, but also to operate with different versions multiple versions of designs to be stored and archived. The graphics representa- tions on the screen should be able to show all inconsistencies between two hyperviews or between versions of the same hyperview. This can be done with highlighting, reverse video or color. Different designs are often worked on simultaneously by independent; teams. Because of this independent develop- ment, hyperviews may contain conflict- ing information. They may contain in- compatible deseriptions of the same objects. A goal of development with CASE systems should be to remove such in- compatibility. Incompatibility is mini- mized by using the descriptions of data and other objects that are already in the central encyclopedia, whenever possible. Sometimes a design cannot be : changed, however; at least, not guickly. Often, a design is frozen while the pro- gramming of that system is done. The objects are software modules or pack- ages that cannot be modified. The ency- clopedia should have knowledge about what can and cannot be modified. Often a bridge is needed between subsystems that are incompatible. Good design has uncomplicated interfaces. 'The bridge ought to be no more than the conversion of data that; passes from one J subsystem to another. The encyclopedia should make clear the different inecom- patible versions of data, and the dia- grams should show the data conversions necessary to build bridges between sepa- rate systems or different hyperviews. Coordinating Development A data administrator has the task of coordinating the logical representations of the corporation's data. An extension of this task is the general coordination of what is in the encyclopedia. I will re- fer to the person responsible for this task as the development coordinator. | Like the data administrator, the devel- opment coordinator needs computerized tools to help him analyze and coordinate the knowledge. He or she will examine many perspectives, helping to synthesize them into as consistent a whole as pos- sible. He may be regarded as the custo- dian of the central encyclopedia. The development coordinator ought to report at a suitably high level, typically to the vice president of information ser- vices. He has a dotted-line link to the in- formation center, development center and the project managers, and is respon- sible for ensuring that they use the en- ) cyclopedia and link into the data model, and that the best possible coordination of systems is achieved. | Next's week's column will discuss the functional characteristics you should look for in a CASE tool. H The James Martin Productivity Series, an information service updated guar- terly, is available through High Pro- ductivity Software Inc., of Marble- head, Mass. 1-800-242-1240. For infor- mation on seminars, please contact (in the United States and Canada) Tech- nology Transfer Institute, 741 10th St. Santa Monica, Calif. 90402 (213) 394- 8305. In Europe, contact Savant, 2 u rnforth, Lancs, LA5 9BX United Kingdom (0524) 734 505.