An Object-Oriented Software Development Framework for Autonomous Decentralized Systems*

Transcription

1 An Object-Oriented Softwre Development Frmework for Autonomous Decentrlized Systems* Stephen S. Yu' Deprtment of Computer Science nd Engineering Arhon Stte University Tempe, AZ , USA Keunhyuk Yeom, Bing Go, Ling Li nd Doc-Hwn Be Computer nd nformtion Sciences Deprtment University of Florid Ginesville, FL , USA Abstrct Developing softwre for distributed computing systems is chllenging due to lck of good softwre development methodologies for distributed computing systems. t is very importnt to develop relible, dptble nd expndble ppliction softwre for distributed computing systems. Autonomous Decentrlized Systems (ADS is distributed computing system with on-line expnd l!. tlty, on-line mintinbility nd fult-tolernce cpbility. n this pper, frmework for developing ADS ppliction softwre is presented. Our frmework consists of objectoriented requirements nlysis, system design, implementtion, lloction, verifiction.nd mintennce. t is bsed on the object-oriented computtion model developed for ADS ppliction softwre development which supports on-line expndbility nd on-line modifibility. CASE environments for ADS softwre development re lso discussed. Keywords: utonomous decentrlized system, ppliction softwre development, object-oriented pproch, CASE environment. 1 ntroduction Due to the rpid development of computer nd communiction technologies, distributed computing systems re used widely in vrious res of pplictions [l]. n some ppliction res, it is required tht the system be continuously operting t ny time, including prtil system filure, system expnsion nd system mintennce. Hence, these systems should not only hve the fult-tolernce cpbility, but lso on-line expnsion nd on-line mintennce properties. n order to hve these properties, the Autonomous Decentrlized System ADS), which is composed of lrgely utonomous nd 6 ecentrlized components with the cpbilities of on-line expnsion, fult-tolernce, nd on-line mintennce, hs been developed [2, 31. The ADSs hve been pplied to severl res, such s the steel production process control systems nd trin trffic control systems. n order to effectively utilize ADSs, effective ppliction softwre development methodologies for ADSs re needed. *This work is supportedunder the collbortive reserch greement between the University of Florid nd Etchi, Ltd., nd the collbortive rcsereh greement between the Arieon Stte Univcnity nd Hitchi, Ltd. t Formerly with Computer nd nformtion Sciences Deprtment, Univenity of Florid, Ginerville, FL Developing softwre for distributed computing systems is more chllenging thn tht for centrlized computing systems due to dditionl complictions of interprocessor communiction, synchronirtion, etc.[ 1, 41 Becuse the object-oriented prdigm reflects the distributed structure of the problem spce nd is suitble for representing inherently concurrent behvior, it is suitble to support the softwre development for lrge scle distributed computing systems, like ADSs. We hve developed n object-oriented computtion model [5] for softwre development for ADSs. n this pper, we will present n object-oriented softwre development frmework for ADSS bsed on this computtionl model. Our frmework consists of object-oriented requirements nlysis, system design, implementtion, lloction, verifiction nd mintennce. We will lso discuss our CASE environment supporting these phses nd use n Automted Teller Mchine (ATM) to illustrte our frmework. 2 The Object-Oriented Computtionl Model Before we present our softwre development frmework, we will briefly summrize the computtionl model [5] which is the bsis for our frmework. The computtion model is bsed on the objectoriented concept nd supports on-line expndbility nd on-line modifibility t the ppliction softwre level. n the computtion model, ADS softwre is represented s set of modules. Ech module hs its own control thred, the object bse, the interfce bse, nd bse mngement mechnism (BMM). An object bse contins instnces of object clsses defined in the module. The objects in the object bse of module is clled locl objects of this module, nd the objects in the object bses of other modules is clled remote objects of this module. An interfce bse contins the object methods nd the object nmes to which these methods belong. There re two types of interfce: import interfce nd export interfce. The import interfce is list of methods in other objects invoked by itself. The export interfce is list of methods of its own to be invoked by other objects. The BMM provides functions used to modify the object bse nd interfce bse dynmiclly to support on-line fetures. The followings re mjor fetures of the computtion model: $4.00 Q 1995 EEE 405

2 Computtion Model Requirements Sttements objectpriented Requuements Anlysis System Design mplementtion Alloction Object Model & Dynmic Model D Module Description in DDL L + z j ADS Appliction SoAwn Figure 1: Our object-oriented frmework for ADS p pliction softwre development. clsses nd objects used s bses of softwre development two level encpsultion: module level nd object level synchronous remote object method invoction nd synchronous locl object method invoction full logicl loction trnsprency chieved by the loction mechnism to determine the locl object method invoction nd the remote object method invoction on-line expndbility nd on-line modifibility chieved by the BMM to modify the object bse nd interfce bse dynmiclly 3 Our Frmework Our frmework hs the following phses: objectoriented requirements nlysis, system design, implementtion, lloction, verifiction nd mintennce. The frmework for softwre development for ADS is shown in Figure 1. We strt the ADS softwre development with set of requirement sttements, which is trnsformed into the object model nd dynmic model using object-oriented requirements nlysis (OORA) technique. Our OORA technique is n extension of Object Modeling Technique (OMT) [S. The OMT is bsed on constructing two visul projections of the system, clled the object model nd the dynmic model. The object model shows clsses nd their structures derived from the knowledge bout ppliction domin nd the requirement sttements. The dynmic model shows finite-stte mchine model for ech clss in the object V e model. The object model nd dynmic model re represented by the module description in Design Description Lnguge DDL [5 in the system design phse. Then, ech modu e design in DDL is implemented in C++ nd the implemented modules re llocted into processors. At the end of ech phse, the dequcy of the results of ech phse is verified. The mintennce technique cn be pplied to mnge the ADS ppliction softwre. n this pper, while we discuss the overll frmework for the softwre development for ADS, our focus will be on the requirements nlysis nd verifiction, system design nd the CASE tools supporting these phses. 4 Object-Oriented Requirements Anlysis nd Verifiction OORA is rpidly gining populrity, promising to pre vide more understndble specifiction nd to better support object-oriented design nd implementtion. n this section, we will present our object-oriented requirements nlysis nd verifiction. 4.1 Object-Oriented Requirements Anlysis To generte precise, concise, understndble nd correct model of rel-world ppliction problem, we must exmine its requirements, nlyee their implictions nd restte them rigorously [S. The nlysis model consists of the object nd dynmic models. The object model cn be constructed s follows [6]: 1. identify object clsses from the requirement sttements. 2. identify ssocitions between clsses. 3. identify object ttributes. 4. orgnize clsses using inheritnce to shre common structure. We iterte the bove steps until the object model is correct. Finlly, we pply topdown nd/or bottom-up pproches to build our hierrchicl object model. n most existing OORA methodologies, the results of the requirements nlysis only concerns sttic informtion such s clss definitions, hierrchies, nd reltionships mong clsses. However, for distributed computing systems like ADS, more informtion, such s communiction behvior, persistency of objects nd role of objects, re needed in the requirements nlysis phse nd mde vilble to the design phse. The dynmic model in 61 using stte trnsition digrm (STDL is not suit Jle for representing communiction nd c ecking consistency. We hve developed new dynmic model to enhnce the originl STD. t cn be constructed s follows: 1. prepre scenrios. We prepre scenrios of typicl interction sequences. These scenrios show the mjor interctions, externl disply formts nd informtion exchnges. The pproch to construct the dynmic model by scenrios ensures tht importnt steps re not overlooked nd tht the overll flow of the interction is smooth nd correct. 406

3 construct event trce for ech scenrio. An event trce is n ordered list of events between objects. Exmine the scenrios to identify ll externl events including ll signls, inputs, decisions, interrupts, trnsitions nd ctions. build n STD bsed on event trce. t strts with the event trce digrms tht ffect the clss being modeled. Every scenrio or event trce corresponds to pth through the STD. Ech brnch in control flow is represented by stte with more thn one exit trnsition. Verify consistency. Check for the completeness nd consistency t the system level. Every event should hve sender nd receiver. Mke sure tht corresponding events on different STDs re consistent. n rel-world pplictions, softwre systems hve substntil number of object clsses nd ssocitions. To hndle this, we developed hierrchicl object model to "lyer" the object model s follows: After identifying object clsses nd ssocitions, we group the clsses using the following bottom-up guidelines: 0 Tightly-coupled clsses which frequently communicte ech other re grouped together. Ech ssocition should generlly be shown on single screen, but some clsses must be shown more thn once to connect different sheets. Try to minimize the number of bridge clsses which re the clsses which form the bridge between two screens or subjects (which re logicl constructs for grouping clsses). A str pttern is frequently useful for orgnising subjects: single core subject contins the toplevel structure of high-level clsses. Other subjects expnd ech high-level clss into generliztion hierrchy nd dd ssocitions to dditionl lowlevel clsses. Becuse it is not relistic to pply existing OORA pproch directly to lrge nd complex systems due to the complexity of the problem sttement itself, we use the following top-down pproch: 1. dentify the core ctivity res of the system which require nlysis, nd provide bsis for work prtitioning nd prllel development. Domin knowledge plys n importnt role in identifying these res. 2. Divide the problem sttements ccording to the core res identified in Step Apply our OORA pproch to ech of the core ctivity res to generte the object nd dynmic models for ech re.. *. --- Figure 2: Our verifiction pproch. A,;Build nformtion Tree Object-Oriented Requirements Verifiction Becuse the requirement sttements re high-level description of softwre system in nturl lnguge, nd becuse we need to use the domin knowledge nd ignore redundnt or unnecessry informtion from the given requirement sttements to derive OORS during OORA, there my exist some differences between requirement sttements nd OORS. Such differences should be identified nd their effects on the system should be evluted during the verifiction of OORS. Our verifiction pproch will identify the missing informtion in the OORS which my be deleted s unnecessry informtion nd the informtion in the OORS which is not specified in the requirement sttements. To verify the OORS, we check the completeness nd consistency between the requirement sttements in the nturl lnguge nd the OORS [7]. To do so, we trnsform the OORS which is expressed in terms of the object model nd dynmic model generted by OORA into forml specifiction using forml specifiction lnguge, which is then trnsformed to grphic form clled the informtion tree. We then verify the completeness nd consistency of the requirements specifiction by compring the informtion in the informtion tree with the given requirement sttements in the nturl lnguge. The informtion tree is built to orgnise the informtion so tht the verifiction cn be systemticlly performed without incresing the complexity of the problem itself. The overll verifiction process is shown in Figure 2. The input of our verifiction pproch consists of OORS expressed in terms of the object model nd dynmic model, nd the requirement sttements in the nturl lnguge given by the client. Our verifiction pproch cn be summrized s follows: 407

4 1. Trnsform the derived OORS into forml requirements specifiction described by forml specific& tion lnguge Build n informtion tree from the forml specifiction obtined in Step 1. Check the completeness nd consistency between requirement sttements nd OORS by compring ech given requirement sttement with the informtion represented by its corresponding pth or reltionship in the informtion tree. 5 System Design During the system design, we determine the structure of the system, which provides the context for more detiled decisions mde in lter design stges. By mking high-level decisions for the entire system, the system designer prtitions the problem into modules so tht further work cn be done by severl designers working independently on different modules. n our computtion model, ADS softwre is represented s set of modules, nd ech module hs its own control thred, number of locl objects nd interfces including import interfce nd export interfce. Bsed on this structure, we derive the following procedure for the system design: dentify ll objects nd ll inter-object communiction from the requirement sttements, object model nd dynmic model. At the requirements nlysis phse, we focused on clsses rther thn objects in object modeling. However, individul objects which ply different roles in the system nd their communiction behvior should be identified t the system design phse. Cluster the objects into modules. Bsed on our computtion model, module is not n object nor function, but pckge of objects, ssocitions, opertions, events nd constrints tht re interrelted nd include resonbly well-defined interfce with other modules. The formtion of the modules or the clustering of objects nd relted items directly influences the performnce of the system being developed. A good clustering lgorithm will estblish modulr design which will reduce inter-module communiction cost, exploit potentil concurrency mong objects, nd chieve fulttolernce nd relibility. For this purpose we use clustering lgorithm to systemticlly group the objects into modules ccording to given set of criteri: minimizing communiction, exploiting concurrency, functionlity nd user constrints. Our clustering pproch is bottom-up heuristic lgorithm which optimizes communiction with functionlity nd concurrency s constrints. dentify the control thred of ech module. A control thred is pth through set of stte digrms in which only single object t time is ctive. n our computtion model, ech module hs only one control thred constructing the body of itself, in which objects re initited nd the process ctivities of the module re defined. 4. Describe ech module using DDL defined in our computtion model. Our DDL is used to represent softwre design for ADSs. The DDL representtion of the softwre design reduces the gp between system design nd implementtion. 5. Decide boundry conditions. The boundry conditions such s initiliztion, termintion nd filure, must be tken cre of during system design. Constnt dt, prmeters, globl vribles, tsks nd others need to be initilized. n ADS softwre, content code [8] should be set for ech module. On termintion, internl objects cn simply be bndoned, nd ech tsk must relese ny externl resources it hd reserved. n cse of filure, pln must be developed for orderly filure, s well s grceful exit on ftl bugs by leving the remining environment s clen s possible nd recording or printing s much informtion bout the filure s possible before terminting. Exception hndling techniques for behviors like retry, ignore, wit nd time out re being developed s defined in our computtion model. 6 mplementtion nd Alloction n our frmework, coding is done using C++ with ADS constructs, such s invoction, receivexesult, gurd sttement, etc., which re bsed on our computtion model. The dvntges of using ADS constructs re tht the progrmmer will not hve to be bothered by the synchronistion, communiction nd/or loction of processors. The ADS constructs cn be trnslted utomticlly into C++ by control mechnism in our computtion model. After the implementtion, we need to llocte the modules to processors in the ADS system. For the module lloction, we use the criteri of minimizing communiction nd blncing the lod mong the subsystems tht constitute the distributed system [9]. Our module lloction lgorithm is heuristic nd suitble for llocting modules onto distributed system whose subsystems re connected in the form of LAN nd communicting by mens of brodcsting such s ADS. n this lgorithm we try to chieve lod blncing nd minimize the communiction thereby ttempting to increse the concurrency. The lgorithm includes fult tolernce spects such s dupliction, tht is, no two duplicted modules re llocted to the sme subsystem s this would defet the purpose of dupliction. Our pproch lso llows the user to specify constrints in lloction such s prticulr module needs to be llocted on to specific subsystem. 7 CASE Environment We hve developed CASE environment to id the system nlysts to generte object model nd dynmic models from the given softwre requirements ccording to our OORA pproch, nd to id the system designer to design the system rchitecture ccording to our system design pproch. This CASE environment includes generic drwing editor using Grphicl User nterfce (GU), two levels of integrtion such s common user interfce nd trnsferbility of dt mong ll the tools in the environment, constrint mintennce which checks 408

5 Dynmic Mcdel 1 - Dynmic 1 - Modules Described in DDL Verifiction t Module Digrm Communiction Problem Sttement Domin Knowledge 4 Obie Communiction Detiled Design. mplementtion x-window Appliction nvironment Figure 3: A CASE environment for our frmework for ADS ppliction softwre development. ble views tht disply the vlues of stte vribles mintined by the object modeling tool. A stte vrible includes the nme of the object model nd modifiction sttus. The user engges the current tool by clicking on the pproprite control on the tool s left edge. The dynmic modeling tool is very similr to the object modeling tool. t lso consists of stte vrible views, pull-down menu, viewer nd pnner. We cn build the components of the dynmic model such s stte, event, clss nd trnsition, nd mnipulte components such s move nd select using this tool. n implementtion phse, our computtion model provides lnguge constructs for ADS softwre tht control communiction, synchroniztion nd other ADS properties. These ADS constructs re trnslted into C++ by preprocessor. The preprocessor scns the ADS ppliction modules, checks the syntx ccording to the syntx defined by the computtion model nd generte source code. The lloction lgorithm hs been implemented under X window environment. The lgorithm consists of three min procedures: Cluster, Spillover nd Updte-Lod. The procedure Cluster clusters two nodes to form compound node. This is done by merging the two nodes, pivot nd non pivot node into single node. The procedure Spillover is for chieving lod blncing. t checks whether module cn be sfely llocted to subsystem. Ech time n lloction is performed, the lod on the subsystem to which the lloction is performed is updted by cll to the procedure Updte-lod. Finlly, we re going to construct CASE environment tools nd n integrted comprehensive set of services to support softwre development for dist ribu t ed computing systems. the connectivity between components, error checking, nd utomtion of output genertion from the CASE tools for OORA nd for system design Our gol is to provide CASE environment for ADS ppliction softwre development s shown in Figure 3, where two levels of integrtion re supported. The first level is the common user interfce. Commnds nd tools re ccessed uniformly in both the tools for OORA, such s the object modeling tool, dynmic modeling tool nd event trce editor, nd for system design, such s the object communiction modeling tool nd module modeling tool. The next level of integrtion is the trnsferbility of dt between the tools, which is nother kind of bridge between the tools. The CASE tools need to communicte ech other in order to fetch informtion nd check consistency. For exmple, the CASE tools for the system design my need informtion from the CASE tools for OORA, such s clss definitions nd communiction behvior. The design of our CASE tool is bsed on the frmework of Unidrw [lo]. We implemented this tool using the object-oriented lnguge C++ nd the CASE tools re running on X windows. We lso used some objects from the object-oriented grphicl toolkit nterviews [ll] such s dilog boxes, text editor nd structured grphics. The object modeling tool consists of viewer, pulldown menu contining controls tht execute specific commnd, controls for engging the current tool, pnner for pnning nd zooming the viewer nd stte vri- 8 An Exmple We will illustrte our pproch using simplified Automted Teller Mchine (ATM) system. The requirement sttements for the system is given s follows: Develop the softwre to support computerized bnking system with utomtic teller mchines (ATMs) to be shred by consortium of bnks. Ech bnk hs its own computer to mintin its ccounts nd mke updtes to ccounts. ATMs communicte with centrl computer of the consortium. An ATM ccepts bnk crd, intercts with the user, communictes with the centrl computer to process trnsctions, nd/or dispenses csh. For simplicity purpose, the system is ssumed to hve two ATMs, two Bnks nd one Consortium. For object-oriented requirements nlysis, we obtin the object nd dynmic models of the ATM system ccording to the procedures summrized in Section 4.1. The object model is shown in Figure 4. The stte trnsition digrm of clss ATM is shown in Figure 5. For object-oriented requirements verifiction, we first trnsform OORS into forml specifiction nd build n informtion tree from the forml specifiction. Figure 6 shows the complete informtion tree of n ATM system. For ech sttement in the requirement sttements, we check the consistency. For instnce, ATM dispenses csh. The corresponding pth of this sttement in the informtion tree is identified by selecting nodes such ATM, dispense-csh, csh nd s shown with the rrows in Figure 6. We compre this pth nd the given 409 -

6 Consists of 9 Consdum Consists of ssues lh, Holds, Account den7, 1 1 Bnk Crd U Accesses Figure 4: The object digrm for the ATM system. U sttement from the requirement sttements for the consistency. As result, we find n inconsistency, < 200, in the OORS. We lso consider the pth in the informtion tree, ATM, dispense-csh, csh, nd less thn or equl to $200, s n exmple. We mke the sttement or the enumertion of words for tht pth s follows: ATM dispenses csh (less thn or equl to $200). We serch sttement in the requirement sttements mtched with the sttement represented by tht pth. We find the sttement in the originl requirement sttement, "ATM dispenses csh". We determine whether less thn or equl to $200 is from the domin knowledge or mistke mde during OORA. Compring it with the domin knowledge dded during OORA, we find tht "less thn or equl to $200" is from the domin knowledge. For system design, we first identify objects nd interobject communictions. n this exmple, objects re ATM1, ATM2, Bnkl, Bnk2, Consortium, Bnk- Crds, Crd-Authoriztions, Accounts, Trnsctions, Updtes nd Users, nd interobject communictions re "Consortium communictes with ATM1, ATM2, Bnkl nd Bnk2," "Bnk-Crds, Crd-Authoriztions, Accounts, Trnsctions nd Updtes communicte with corresponding Bnk," "Updtes communicte with Accounts nd Trnsctions" nd "Users communicte with ATMs". Next step is clustering. The module communiction digrm fter clustering is shown in Figure 7. Then, identify control thred of ech module nd describe ech module by DDL. Finlly, we should hndle boundry conditions. First, we initilize the dtbse using ll vilble ccount dt nd set content code for ech module. The second condition is termintion, but we do not hve termintion conditions becuse the system will operte forever. The lst one is filure condition. For instnce, if user enters wrong pssword three times continuously, the crd is utomticlly ejected. 9 Discussion n this pper, we hve presented n object-oriented frmework for ADS ppliction softwre development. Our frmework contins object-oriented requirements nlysis, system design, implementtion, lloction, verifiction nd mintennce. We hve introduced hi- min screen Figure 5: The stte trnsition digrm for clss ATM. errchicl object modeling for mnging lrge complex systems. We hve lso constructed dynmic model from the event trces utomticlly using CASE tool. Since the requirement sttements written in nturl lnguge often contin mbiguities which led to diverse interprettions of the sme requirements nd cuse serious problem in requirements nlysis, one of future reserch is to del with the mbiguities in the requirement sttements for requirements nlysis. n design verifiction, we del with more specific design issues, such s concurrency, communiction nd dedlock in softwre development for ADS. We lso need to del with the testing of ppliction softwre on the ADS environments. We hve developed n lloction lgorithm bsed on the criterion of minimizing communiction nd lod blncing. On-line modifiction of existing distributed softwre my degrde the performnce of the system unless the lloction is done ll over gin which my be expensive in terms of time nd cost. Hence, we need to develop n efficient relloction lgorithm due to on-line modiction of distributed softwre. To stndrdize our frmework for distributed ppliction softwre development, we need to extend our computtion model to open system environments to chieve the unifiction of system mngement. We will lso consider the object-oriented softwre develop ment frmework using CORBA. Since ADS cn lso be operted in the multiple loop environment s well s the single loop environment, we lso need to extend our 410

7 i System ;) success Figure 6: The informtion tree for the ATM system. Figure 7: Module communiction digrm of the ATM system fter clustering. computtion model to the multiple loop environment. Acknowledgment The uthors would like to thnk K. Mori, K. Kvno, H. Suzuki, M. Orimo, C. Ski nd T. Ymmori of Hitchi, Ltd. for vluble discussions on vrious spects of the ADS systems. References [l] S. S. Yu, X. Ji, nd D.-H. Be, Trends in Softwre Design for Distributed Computing Systems, Proc. Second EEE Workshop on Future Trends of Distributed Computing Systems, 1990, pp [2] H. hr nd K. Mori, Autonomous Decentrlized Computer Control Systems, EEE Computer, Vol. 17, NO. 8, 1984, pp [3] K. Kwno, M. Orimo nd K. Mori, Autonomous Decentrlized Systems: Concept, Dt Field Architecture nd Future Trend, Proc. nt l Symp. on Autonomous Decentrlized Systems, 1993, pp [4] S. S. Yu, X. Ji nd D.-H. Be, Softwre Design Methods for Distributed Computing Systems, Journl of Computer Comm., Vol. 15, No. 5, My 1992, pp [5] S. S. Yu, nd G, -H. Oh, An Object-Oriented A p proch to Softwre Development for Autonomous Decentrlized Systems, Proc. nt l Symp. on Autonomous Decentrlized Systems, 1993, pp [S J. Rumbugh, M. Blh, W. Premerlni, F. Eddy, nd W. Lorensen, Object-Oriented Modeling nd Design, Prentice-Hll, Englewood Cliffi, New Jersey, [7] S. S. Yu, D.-H. Be nd K. Yeom, An Approch to Object-Oriented Requirements Verifiction in Softwre Development for Distributed Computin Systems, Proc. 18th nt l Computer Softwre 8 Applictions Conf., November 1994, pp [8] K. Mori, H. hr, Y. Suzuki, M. Koisumi, M. Orimo, K. Nki, nd H. Nknish, Autonomous Decentrlized Softwre Structure nd ts Appliction, Proc. ACM-EEECS Fll Joint Computer Con$, 1986, pp [9] S. S. Yu nd V. R. Stish, A Tsk Alloction Algorithm for Distributed Computing Systems, Proc. 17th nt l Computer Softwre ty Applictions Conf,, September 1993, pp [lo] J. Vlisides, Generlized Grphicl Object Editing, Technicl Report: CSL-TR , Computer Systems Lbortory, Stnford University, Stnford, CA, June Mrk A. Linton, Pul R. Clder, John A. nterrnte, Steven Tng nd John M. Vlissides, nterviews Reference Mnul, Version 3.1, Stnford University, Stnford, CA, 1992