A Knowledge-based PSEE with the Ability of Project Monitoring

I.J. Informaton Engneerng and Electronc Busness, 2014, 4, 1-11 Publshed Onlne August 2014 n MECS http://www.mecs-press.org/) DOI: 10.5815/eeb.2014.04.01 A Knowledge-based PSEE wth the Ablty of Proect Montorng Shh-Chen Chou Department of Computer Scence and Informaton Engneerng, Natonal Dong Hwa Unversty, Tawan scchou@mal.ndhu.edu.tw Chao-We L Department of Computer Scence and Informaton Engneerng, Natonal Dong Hwa Unversty, Tawan 610121027@ems.ndhu.edu.tw Abstract Process-centered software engneerng envronments PSEEs) facltate managng software proects. Accordng to the change of enactment envronments and the ncrement of software development complexty, PSEE features should be enhanced. We desgned a knowledge-based PSEE named KPSEE. It offers the features: 1) maxmzng the degree of process parallelsm, 2) enhancng process flexblty, 3) managng product consstency, 4) ntegratng PSEEs, 5) keepng pace wth sgnfcant process change, 6) preventng technque leakage, and 7) offerng proect montorng ablty. Index Terms PSEE; Knowledge-Based; Product-Drven; Proect Montorng; Maxmze the Degree of Process Parallelsm I. INTRODUCTION Process-centered software engneerng envronments PSEEs) facltate managng software proects. PSEE research s affected by processes are also software [1]. More than a decade later, the research s stll valuable although t s not so hot as before. Accordng to the change of enactment envronments e.g., from sngle machne to the network) and the ncrement of software development complexty e.g., from waterfall to the Agle models [2]), PSEE features should be enhanced. A PSEE s composed of a process language and an enactment envronment. The language mplements software processes nto process programs for the envronment to enact. A process program s prmary composed of actvtes. An actvty s assgned to roles) played by software developers. When the condton of the actvty s true, the roles produce output products) e.g., specfcaton) by referrng to nput products) usng tools). For example, desgners.e., roles) produce a subdesgn document.e., output product) by referrng to subspecfcatons.e., nput products) usng Ratonal Rose.e., tool). Attachng a condton to an actvty s necessary to mplement the selecton and repetton constructs. The artcle n [3] mentoned the mportant PSEE features: 1) enactment support, 2) software team organzaton) dstrbuton, 3) consstency management, 4) process flexblty.e., dynamc changng process program durng enactment), 5) process evoluton, and 6) keepng pace wth sgnfcant change. Although tradtonal PSEEs offers one or more features mentoned above, they generally suffer from shortcomngs below. Ther process languages look lke programmng languages, whch may lmt the degree of process parallelsm. Snce the actvtes of certan processes are dffcult to predct e.g., the Agle models), lmtng the degree of parallelsm nduces trouble when modelng and enactng the processes. If multple organzatons cooperate for a software proect and they use dfferent PSEEs, coordnators [4-5] are needed. Snce the functons of dfferent PSEEs are heterogeneous, the ablty of a coordnator may be lmted by the PSEEs. Tradtonal PSEEs offer lmted functons to handle exceptons. They generally provde functons for process evoluton [6-8]. Handlng process evoluton may stop software proect executon, whch results n tme delay. If the cooperatng organzatons are mutually untrusted, technque leakage may occur because software development technque may be embedded n software products. Transferrng a product developed by an organzaton to an untrusted one may result n technque leakage. Tradtonal PSEEs release the load of proect managers by rememberng when to do what actvtes usng whch tools. However, an executng proect should be montored. Tradtonal PSEEs dd not offer montorng functons. If a PSEE facltates proect montorng, the PSEE wll be more valuable. To overcome the shortcomngs, we develop a new PSEE. Snce the PSEE s knowledge-based, we name t KPSEE knowledge-based PSEE). KPSEE offers the features mentoned n [2] and the followng enhanced features: KPSEE maxmzes the degree of parallelsm. The degree of parallelsm s maxmzed f an actvty s enacted mmedately when the condton of the actvty s true and the resources requred by the actvty such as nput products and roles) are avalable. KPSEE enacts actvtes n ths manner. Therefore, t maxmzes the degree of parallelsm.

2 A Knowledge-based PSEE wth the Ablty of Proect Montorng KPSEE enhances process flexblty. Process flexblty allows dynamc process program change [2, 9]. KPSEE enhances the flexblty by allowng dynamcally addng, removng, and changng all process components at anytme durng enactment. Here process components nclude everythng n a process program, such as roles and actvtes. KPSEE offers ths feature by allowng unstructured statements and provdng sold excepton handlng functons. Wth unstructured statements, KPSEE process statements can be placed wthout order. Ths smplfes the addton of process components. As to sold excepton handlng functons, t supports the changng and removng of process components. KPSEE s an ntegrator nstead of a coordnator, and offers smple nterface for the ntegraton. The nterface s the KPSEE process language. Process programs n other PSEEs should frst be translated nto KPSEE process programs. Snce KPSEE statements are unstructured, placng the translated process programs together results n an ntegrated KPSEE process program. KPSEE enacts an ntegrated program wthout the nterventon of other PSEEs. Therefore, other PSEEs wll not lmt the functon of KPSEE. KPSEE process language offers statements to trgger KPSEE for the handlng of exceptons and evolutons wthout stoppng the executng proects. Snce the characterstc of excepton and evoluton are smlar n ths artcle, we let excepton to nclude both evoluton and excepton n the rest of the text. KPSEE ntroduces the nformaton flow control [10-11] concept to control the access of software products, whch prevents technque leakage. KPSEE uses rules to facltate partal proect montorng t s mpossble to facltate full proect montorng). KPSEE offers default rules for the montorng. If necessary, rules can be added, removed, or changed by the proect managers. The kernel of KPSEE s a knowledge base. Surroundng the base are functons to enact process programs. It also offers a sub-system to facltate montorng software proects. In the rest of ths paper, secton II dscusses related work, secton III presents KPSEE n detals, secton IV proves that KPSEE offers the features we mentoned, and secton V s the concluson. II. RELATED WORK Generally, exstng PSEEs adopt programmng language constructs e.g., sequences, selectons, and repettons) to develop process languages. Therefore, a process language looks lke a programmng language. For example, CSPL [12] adopts the Ada95 programmng language for ts process language. All the features of Ada95 are offered by CSPL. However, most features mentoned n secton I are not provded. In the early days, PSEEs are generally centralzed. Centralzaton lmts the dstrbuton of software developers. Under ths consderaton, decentralzed PSEEs are attractve. Oz [13] s decentralzed. It s structured by homogeneous and ndependent subenvronments. Each sub-envronment s provded to a development organzaton. Multple organzatons cooperate for a software proect usng the submt protocol. OPERA [14] offers a kernel and an ntermedate language. All process programs enacted n OPERA should frst be translated nto the ntermedate language and then enacted by the kernel. Snce the kernel can be dstrbuted, the ntermedate language can be consdered ntegraton nterface. The researches n [6-8] manage process evoluton or process change. The general problem for the researches s tme-consumng because process programs may be suspended when handlng evoluton. As to product consstency management, we develop a technque to acheve that [15]. The technque manages the dependences among software products. When a product s changed, those drectly or ndrectly dependent on t wll be dentfed and changed accordngly. ADAMS [16] apples the fne-graned concept to manage software artfacts, ncludng all knd of software documents such as specfcatons and desgn documents. It s a SCM software confguraton management) model rather than a PSEE. Fner granularty offers the prmary features of: 1) evolvng one part of a product wll not affect other parts and 2) reducng the possblty that more than one developer ntends to develop the same artfact. As a SCM model, ADAMS keeps traceablty among artfacts. Therefore, t manages software consstency. SPACE [17] s a doman ndependent envronment. It apples metamodels to manage software process as well as artfacts. The use of meta-models allows semantc process/artfactorented collaboraton. SPACE offers good collaboraton among software organzatons and keeps product traceablty. Therefore, consstency management n SPACE s of no problem. The researches n [18-19] use process agents [18] or devaton rules [19] to detect and handle the devaton of software processes. In general, software process devaton almost always happens durng a software proect. Therefore, devaton handlng or process evoluton handlng) s necessary. However, some devaton, such as that n the Agle models, may be out of control. We are not sure whether the researches n [18-19] can handle the devaton. The model-drven approach [20-22] use metamodels to manage process varablty. For example, MoDErNE [20] reuses exstng process models and apples rules to customze the reused models. Durng process modelng, reused process models appear n a process as modelng tasks or edtors. Durng process enactment, f a modelng task or edtor s encountered, the assocated rules customze the process model. The approach solves the varablty of process. However, f exceptons occur after customzaton, MoDErNE cannot solve them usng meta models. Ths reduces the power of excepton handlng n model-drven approach. Snce preventng technque leakage s an mportant feature of KPSEE, we also survey ths type of PSEEs. However, we cannot dentfy a PSEE that offers the

A Knowledge-based PSEE wth the Ablty of Proect Montorng 3 feature, except our prevous research [23]. The research embedded an nformaton flow control model n a PSEE, whch s smlar to that of KPSEE. The maor dfference s that an nformaton flow control model s embedded n a PSEE n our prevous research, but KPSEE and the nformaton flow control model are fused together. III. KPSEE KPSEE decdes whether an actvty can be enacted by checkng the status of nput products. Therefore, t s also product-drven. As descrbed n secton I, f the nput product set IPds of an actvty Act are avalable and the condton Cond of the actvty s true, then Act s enactable. When the role set Rles requred to enact Act are avalable, Act s enacted mmedately. The followng rule depcts the kernel concept of KPSEE, n whch avlpd) s the set of avalable products, avlrle) s the set of avalable roles, and enactact) means enactng Act. IPds avl PD)) Rles avl RLE)) Cond TRUE) enact Act) The rule does not menton tools because we assume that software tools are avalable for software development organzatons. To prevent technque leakage, the kernel concept should be adusted. Suppose a software product s developed by roles) and a role s n an organzaton. Moreover, an organzaton trusts zero or more others. Wth the assumptons, when an actvty requres one or more nput products, the roles enactng the actvty should be n the organzatons that can access all the nput products. The organzatons that can access a product belong to the set ORG TORG ), n whch ORG s the set of organzatons that developed the product, TORG s the set of organzatons trusted by Org, and Org ORG. Based on ths, f the nput product set of an actvty s IPD = {IPd IPd s a product} and the organzatons that develop an nput product IPd s ORG = {Org Org s an organzaton}, then the roles that can enact the actvty should be n the role set AURLE = {Rle k Rle k s a role n an organzaton of the set ORG ) TOrg ) n whch TOrg, s the set, of organzatons trusted by the organzaton Org and Org ORG ) }. Sometmes, roles n AURLE are not enough to enact an actvty. To solve ths problem, a set of authorzed organzatons AO trusted by every organzaton should be avalable. Accordng to the descrpton above, we need the followng nformaton for technque leakage preventon: An organzaton s assocated wth a lst contanng the organzatons t trusts. That s, an organzaton Org should be assocated wth a TOrg,. A product Pd s assocated wth a lst of organzatons that produced t. That s, Pd should be assocated wth an organzaton set ORG. An authorzed lst AO contanng organzatons trusted by every organzaton should be offered. Software Developers Process program statements, Excepton handlng statements PSEE 1 Parser 1... PSEE n Parser n KPSEE process language Integraton mechansm) KPSEE functons Knowledge base manager KPSEE knowledge base Fg. 1. The archtecture of KPSEE Proect manager Proect montorng sub-system Havng descrbed the kernel concept of KPSEE, we descrbe KPSEE. Fg. 1 shows that KPSEE can be accessed drectly by software developers. It can also ntegrate process programs from dfferent PSEEs.e., KPSEE process language acts as an ntegraton mechansm). To ntegrate PSEEs, every PSEE should offer a parser to translate ther process programs nto KPSEE process programs. The component KPSEE functons n the fgure ncludes a parser, the functons to enact KPSEE process programs and prevent technque leakage, and an excepton handler. The component KPSEE knowledge base records the status of products and actvtes, and the relatonshps among products, roles, actvtes, organzatons, and tools. Informaton n the knowledge base s managed by the Knowledge base manager. KPSEE also offers a Proect montorng subsystem to facltate proect montorng. Informaton needed by the sub-system s offered by the KPSEE functons and the proect manager. The followng subsectons descrbe the KPSEE components. A. KPSEE Process Language KPSEE process language does not use tradtonal constructs such as selectons and repettons. Its statements are unstructured.e., wthout order). As long as the requred resources of an actvty are avalable and ts condton s true, the actvty s enacted mmedately. Ths maxmzes the degree of process parallelsm. Statements can be added, changed, or removed anytme durng process enactment. Ths enhances process flexblty and allows software processes wth unpredctable actvtes, such as the Agle processes, to be easly mplemented and enacted. KPSEE process language offers the followng smple statements. +RoleRle, PdRle, SD, IP, Org), -RoleRle, SD, Org), *RoleSD 1, SD 2 ). The former two statements respectvely add and remove a role, n whch Rle s a role, PdRle ndcates the products that can be used by the role, SD s a software developer playng the role, IP s the IP address assgned to the SD, and Org s the organzaton of the role. KPSEE must know the IP addresses to nform the requred roles for actvty enactment. It should also know the role s organzaton to prevent technque leakage. The *Role statement

4 A Knowledge-based PSEE wth the Ablty of Proect Montorng replaces SD 1 by SD 2. It handles SD departure. A departed SD should be replaced by another to mantan the products produced by the departed one. Table 1. Relatonshps between roles, tools, and products Pd PType Rle PdRle Tool PdTl Requrement 1 Customer {1, 2} Word edtor {1, 2, 3} Specfcaton 2 Doman expert {1, 2} UML tool {1, 2, 3} Desgn document 3 Analyst {1, 2, 3} Programmng Language {4} Source code 4 Desgner {2, 3} Testng tool {4, 5, 6, 7} Test case 5 Programmer {3, 4} Test report 6 Tester {4, 5, 6} Released product 7 Proect manager {1, 2, 3, 4, 5, 6, 7} PdRle facltates montorng actvtes. For example, requestng a programmer to use requrements for system analyss s nfeasble. In addton to the relatonshps between roles and products, those between products and tools should also be montored. For example, usng Mcrosoft Word to mplement a program s nfeasble. We use Table 1 to show the relatonshps among roles, tools, and products, n whch PType s a product type, Tool s a tool, and PdTl ndcates the products that can be operated by a tool. To allow more flexblty, the contents of Table 1 can be changed by a proect manager. +OrganzatonOrg, Rle, TOrg), -OrganzatonOrg), *OrganzatonOrg, TOrg). The former two statements respectvely add and remove an organzaton Org. When addng Org, the roles n t.e., Rle) and the organzatons trusted by t.e., TOrg) should be descrbed. The *Organzaton statement changes the organzatons trusted by Org. +AOrgOrg, Rle), -AOrgOrg), *AOrgOrg, Rle). The former two statements respectvely add and remove an authorzed organzaton. When addng an authorzed organzaton, roles n the organzaton.e., Rle) should be presented. The *AOrg statement changes the roles n an authorzed organzaton. +ProductPd, PType, Org), -ProductPd), *ProductPd): The statements respectvely add, remove, and change a product. PType s the type of the product see Table 1). Org s a set of organzatons that produced the product. The +Product statement can add ntally avalable products such as user requrements. Addng ntally avalable product s necessary because KPSEE s product-drven. If no avalable products exst, no actvty wll be enacted. +VarableVar, Val), -VarableVar), *VarableVar, Val): The statements respectvely add, remove, and change varables used n a process program, n whch Var s the varable set and Val s the correspondng value set for Var. The statements are necessary to mplement the selecton and repetton constructs. +ToolTlName, PdTl), -ToolTlName), *ToolTlName, PdTl). The statements respectvely add, remove, and change a tool, n whch TlName s a tool name, and PdTl s shown n Table 1. +ActvtyActID, IPd, OPd, Cond, Acton, Rle, Tool, Schl, Budget, HouAct), -ActvtyActID), *ActvtyActID, newipd, newopd, newcond, newacton, newrle, newtool, newschl, newbudget, newhouact): The former two statements respectvely add and remove an actvty. The *Actvty statement changes the contents of an actvty. In the statements, ActID s the dentty of an actvty to dfferentate actvtes, IPd s the set of nput products, OPd s the set of output products, Cond s the condton to trgger the actvty, Acton s the acton of the actvty, Rle s the set of roles to take the acton, Tool s the set of tools used n the actvty, Schl s the schedule of the actvty, Budget s the budget of the actvty, and HouAct s the housekeepng actons after the actvty fnshes e.g., f an actvty s n a loop, the housekeepng actons may contan a loop counter decrement statement). The *Actvty statement adds a word new before parameter names means the contents of the actvty s changed. +ScheduleBudgetTolSchl, TolBudget), *ScheduleBudgetTolSchl, TolBudget). They respectvely ndcate and change the schedule and budget of a proect. B. KPSEE Knowledge Base and ts Manager KPSEE knowledge base KPKB KPSEE knowledge base) s defned below, n whch s a depend on relatonshp: Defnton 1. KPKB = PD, ACT, ROLE, TOOL, ORG, AO, PDDEP, PDACT, PDROLE), n whch: PD s the set of software products. It s defned below. PD = {Name, Status, PType, Org) Name and Status are the name and status of the th product, respectvely. PType s shown n Table 1. Org s the organzaton set that produced the product. Product status may be A avalable), U unavalable), and D removed).} ACT s the set of actvtes, whch s defned below. ACT = {ActID, IPd, OPd, Cond, Acton, Rle, Tool, Schl, Budget, HouAct, Status) ActID, IPd, OPd, Cond, Tool, Shcl, Budget, and Status are respectvely the dentty, the set of nput products, the set of output products, the condton, the schedule, the budget, and the

A Knowledge-based PSEE wth the Ablty of Proect Montorng 5 status of the th actvty. Acton s the acton of the actvty. Rle s the set of roles to take the acton. Tool s the set of tools used n the actvty. IPd and OPd are subsets of PD. Actvty status may be E enactng), W wat for enactment), F fnsh enactment), and D removed).} ORG s the set of organzatons, whch s defned below: ORG = {Org, Rle, TOrg) Org s the th organzaton, Rle s the set of roles n Org, and TOrg s the set of organzatons trusted by Org } AO s the set of authorzed organzatons, whch s defned below: AO = {AOrg, Rle) AOrg s the name of the th authorzed organzaton and Rle s the set of roles n AOrg } ROLE s the set of roles. It s defned below: ROLE = {RName, SDName, PdRle, IP, Org) RName s the name of the th role, SDName s the developer s name playng the role, PdRle s shown n Table 1, IP s the IP address to access the role, and Org s the organzaton contanng the role.} F. TOOL s the set of tools. It s defned below: TOOL = {TlName, PdTl) TlName s the name of the th tool. PdTl s shown n Table 1} G. PDDEP s the set of product dependences. After fnshng an actvty, every output product depends on every nput product. PDDEP s defned below: PDDEP = PD PD 2 H. PDACT s the relatonshps between products and actvtes. If a product s developed by an actvty, there s a relatonshp between the product and the actvty. PDACT s defned below: PDACT = { Pd Act ) Pd s developed by the actvty Act. Pd PD and Act ACT} PDROLE s the relatonshps between products and roles. If a product was developed by one or more roles, the relatonshps are establshed between the product and the roles. PDROLE s defned below: PDROLE = ROLE PD 2 PDDEP facltate handlng the rpple effects nduced by changng or removng a product. PDACT and PDROLE facltate correctng a product. That s, the orgnal developers should re-enact the orgnal actvty to correct a product f necessary. The knowledge base KPKB should be assocated wth a set of functons to manage the knowledge. We collectvely call the functons the KPKB knowledge base manager. To smplfy descrbng the manager, we use the component of a defnton as a functon to retreve the component. For example, StatusPd ) retreves the status of the product Pd. Important KPKB management functons are lsted below. getactidpd ). Ths functon returns the dentty of the actvty that developed the product Pd. Accordng to Defnton 1, the functon returns ActID n whch Pd ActID. getsdsetpd ). Ths functon returns the IP set of the software developers that developed the product Pd the software developers played proper roles to develop the product). Accordng to Defnton 1, the functon returns the set {IPRle ) Pd Rle) Rle Rle)}. getdeppdsetpd ). Ths functon dentfes the products affected by removng or changng Pd. Therefore, t returns those drectly or ndrectly dependent on Pd. Accordng to Defnton 1, the functon returns the set deppdset defned as: {Pd Pd Pd ) Pd k deppdset, Pd Pd k ). deppdset s recursvely defned to dentfy the products ndrectly dependent on Pd. The KPKB manager also offers functons for the statement of +Actvty, +Product, and so on. The functons nsert to KPKB the nformaton obtaned from the parser. As to the functons that mplement -Actvty, *Actvty, -Role, *Role, -Product, and *Product, they handle exceptons. We descrbe them n the next subsecton. C. KPSEE Functons A parser for KPSEE process language s the basc functon. After parsng a statement, the parser nvokes functons to take proper actons. For example, after parsng the +Actvty statement, the parser nvokes the KPKB manager functon to nsert the actvty nformaton to KPKB. In addton to the parser, KPSEE offers a proactve functon to enact process programs and reactve ones to handle exceptons. The proactve functon dentfes actvtes wth true condtons and avalable nput products the actvtes are enactable). For an enactable actvty, the proactve functon nforms the requred roles. To prevent technque leakage, only roles n the organzatons that can access all the nput products are nformed. An dle role beng nformed should react. After the reacted roles are enough, the actvty s enacted mmedately. After an actvty s fnshed, the data structure of KPKB s adusted. To nform roles, two approaches can be appled. Frstly, roles n the authorzed organzaton lst and those that can access all the nput products are nformed smultaneously. Secondly, roles that can access all the nput products are nformed frst. If the reacted roles are not enough after a tme perod, roles n the authorzed organzaton lst are nformed. The second approach takes authorzed organzatons as valuable resources and should be used only when necessary. We accept the second approach. The executon logc of the proactve functon s shown n Algorthm 1.

6 A Knowledge-based PSEE wth the Ablty of Proect Montorng Algorthm 1. Executon logc of the proactve functon t enacts process programs). functon enactprocess): f avlipdactid )) CondActID ) then nsertpdopdactid ), U ); // Insert output products wth status U. nformrleactid ), OrgIPdActID )) )) k TOrg OrgIPdActID )) ) k ); // Inform the requred roles n the organzatons that are allowed to access all the nput products. settmeouttme); // Set tmeout counter. f enoughrleactid )) then // Enough roles causes actvty enactment. enactsubrle, ActID ) n whch subrle RleActID )); else f Tmeout) enough Rle ActID )) then nformrleactid ), RleAO)); // If the reacted roles are not enough, nform roles n the authorzed organzaton lst. f enoughrleactid )) then enactsubrle, ActID ) n whch subrle RleActID )); f fnshactid ) then // If fnsh s true, the actvty s fnshed. setstatusopdactid ), A ); // The output products become avalable. setstatusactid, F ); // The actvty has been fnshed. OPd OPd ActID ) do IPd IPd ActID ), Opd IPd ; Rle subrle, Opd Rle ; Opd ActID ; end do; HouActActID ); // Do the housekeepng actons of the actvty. There are bult-n functons offered by KPSEE, such as avl and settmeout. Perhaps the most mportant bult-n functon s nform, whch nforms the roles requred by an actvty when ts condton s true and nput products are avalable. Parameters of the functon nclude: 1) the roles requred by ActID and 2) the roles organzatons. The set subrole n Algorthm 1 s a subset of the reacted roles nformed by the proactve functon. Roles n subrole are selected to enact the actvty. The reactve functons handle exceptons. Exceptons may be caused by changng user requrements or software processes, verfcaton falure, the departure of software developers, and changng the trust relatonshps among organzatons. Changng user requrements or software processes may result n the addton, change, or removng of actvtes or products. Verfcaton falure may result n correctng products. The departure of software developers may result n replacng software developers. And, changng the trust relatonshps among organzatons may result n changng the lst of organzatons that can access a product. The addton of actvtes, products, roles, and organzatons and the handlng of authorzed organzatons are not descrbed here because they are KPKB manager functons. The handlng of the statement -Organzaton s not descrbed because t only causes the deleton of an organzaton. The statement *Organzaton causes the change of trustable organzatons of an organzaton. The change wll affect the organzatons that can access a product. The organzatons that can access a product are dynamcally dentfed durng process program enactment.e., the *Organzaton statement wll affect the set k TOrg OrgIPdActID )) ) k n Algorthm 1). In other words, the *Organzaton statement wll not affect other data structure n KPKB. Therefore, t s not descrbed. The mportant excepton handlng functons are descrbed below. Change a product. Ths functon mplements the statement *Product. Changng a product may result n changng the products drectly or ndrectly dependent on the changed one, whch s a rpple effect. Algorthm 2. Change a product. functon chgpdpd ): ActID = getactidpd ); // The KPKB functon getactid dentfes the actvty that produced Pd. setstatuspd, U ); // The functon setstatus sets the status of a product or an actvty. f statusactid ) = E ) then nformrleactid ), Stop enactment, ActID ); // If the actvty producng Pd s beng enacted, nform the roles enactng ActID to stop enactment. The nform statement s overloaded. setstatusactid, D ); // Changng Pd means the actvty producng t becomes ncorrect and should be removed. Software developers should redesgn the actvty and re-enact t to produce the correct Pd. // The followng statements handle rpple effects. affpdset = getdeppdsetpd ); // The KPKB functon getdeppdset dentfes the products drectly or ndrectly dependent on Pd. Pd affpdset do ActID = getactidpd ); setstatuspd, U ); f statusactid ) = E ) then nformrleactid ), Stop enactment, ActID ); setstatusactid, D ); end do; Remove a product. Ths functon mplements the statement -Product. Removng a product may also result n rpple effects.

A Knowledge-based PSEE wth the Ablty of Proect Montorng 7 Algorthm 3. Remove a product. functon rmvpdpd ): ActID = getactidpd ); setstatuspd, D ); f statusactid ) = E ) then nformrleactid ), Stop enactment, ActID ); setstatusactid, D ); // When a product s removed, the actvty producng t should also be removed. // The followng statements handle rpple effects. affpdset = getdeppdsetpd ); Pd affpdset do ActID = getactidpd ); setstatuspd, D ); f statusactid ) = E ) then nformrleactid ), Stop enactment, ActID ); setstatusactid, D ); end do; // Pd may depend on Pd and others. In ths case, Pd and the actvty developng Pd become ncorrect and should be removed. The actvty should be re-desgned then re-enacted to product correct Pd. Change an actvty. Ths functon mplements the statement *Actvty. The actons of changng an actvty wth dfferent status wll be dfferent. Algorthm 4. Change an actvty. functon chgactactid, newipd, newopd, newcond, newacton, newrle, newtool, newhouact): setstatusactid, D ); // Remove the actvty to be changed. addactactid, newipd, newopd, newcond, newacton, newrle, newtool, newhouact); // Add the actvty that have been redesgned. f statusactid ) = W ) then // The actvty s watng for enactment. // Do nothng. else f statusactid ) = E ) then // The actvty s enactng. nformrleactid ), Stop enactment, ActID ); // Inform the roles enactng the changed actvty to stop the enactment. setstatusactid, W ); // Wat for reenactment. else f statusactid ) = F ) then // The actvty has been fnshed. pdset = OPdActID ); pd pdset,chgpdpd ); setstatusactid, W ); // If ActID fnshed, the produced products should be changed. The chgpd functon Algorthm 2) can be nvoked. Remove an actvty. Ths functon mplements the statement -Actvty. The actons of removng an actvty wth dfferent status wll be dfferent. Algorthm 5. Remove an actvty. functon rmvactactid ) setstatusactid, D ); // Remove the actvty. f statusactid ) = W ) then // The actvty s watng for enactment. // Do nothng. else f statusactid ) = E ) then // The actvty s beng enacted. nformrleactid ), Stop enactment, ActID ); else f statusactid ) = F ) then // The actvty has been fnshed. pdset = OPdActID ); pd pdset,rmvpdpd ); // If ActID fnshed, the produced products should be removed. The rmvpd functon Algorthm 3) can be nvoked. Correct a product. When correctng a product, the orgnal developers that produced the product should re-enact the orgnal actvty. The orgnal developers are needed because new ones may be unfamlar wth the product. Algorthm 6. Correct a product. functon corrpdpd ): ActID = getactidpd ); // Identfy the actvty that produced Pd. setstatuspd, U ); // Avod an actvty to use the ncorrect product. IPset = getsdsetpd ); // The KPKB functon getsdset dentfes the IP set of the orgnal developers that produced Pd. f avlipdactid )) then loop whle nformipset) = FALSE); // Wat for the software developer responses. The nform functon s overloaded. enactipset, ActID ); // The orgnal developers enact the actvty. f fnshactid ) then setstatuspd, A ); setstatusactid, F ); // Correctng a product may affect others, whch should also be corrected. The correcton s acheved by recursvely nvokng corrpd. affpdset = getdeppdsetpd ); Pd affpdset, corrpdpd ); Replace a software developer. Ths functon mplements the statement *Role. Algorthm 7. Replace a software developer. functon chgsdsd 1, SD 2 ): Rle ROLE SDName Rle ) setsdname Rle, SD 2 ); SD, 1

8 A Knowledge-based PSEE wth the Ablty of Proect Montorng // ROLE s defned n Defnton 1. The functon setsdname sets the software developer s name that plays a role. D. Proect Montorng Support KPSEE montorng sub-system n Fg. 1 s a proactve functon that montors a proect followng the rules descrbed n ths sub-secton. Volaton of the rules wll be reported to the proect manager for proper handlng. The rules are KPSEE default settngs. Proect managers can add, remove, or change them. The rules are descrbed below see Table 1 for the meanngs of the symbols PType, PdRle, and PdTl): The rule to montor software products n an actvty ActID. For product combnaton, the product types.e., PType) of both the nput and output products should be the same. For product development, the product types of the nput products should be the same, those of the output ones should be the same, and those of the output ones should be one larger than those of the nput ones. Rule 1: [PTypeSetIPdActID )))- PTypeSetOPdActID ))) = ] [MaxPTypeSetIPdActID )))- MnPTypeSetIPdActID ))) = 0) MaxPTypeSetOPdActID )))- MnPTypeSetOPdActID ))) = 0) MaxPTypeSetOPdActID )))- MnPTypeSetIPdActID ))) = 1)] Contents n the frst square brackets mean product combnaton and those n the second mean product development. The functon PTypeSet extracts product types from a set of products. It equals to PTypeIPdActID )), n whch PTypeIPdActID )) s the type of the th nput product of ActID. The rule to montor roles n an actvty ActID. When nput products are referenced to produce output ones, the requred roles can use all the products the symbol PdRleRleActID )) s the products that can be used by the th role). Rule 2: PTypeSetIPdActID )) PTypeSetOPdActID ))) PdRleRleActID )) ) The rule to montor tools n an actvty ActID. When nput products are referenced to produce output ones, the requred tools can operate on all the products the symbol PdTlToolActID )) s the products that can be operated by the th tool). Rule 3: PTypeSetIPdActID )) PTypeSetOPdActID ))) PdTlToolActID )) ) Rules to montor the frequences of changng or correctng products and actvtes. Large frequences reflect the rsk of premature proect or untraned developers. Rule 4. corrcntpd )+chgcntpd ) FPd Rule 5. corrcntactid )+chgcntactid ) FAct Rule 6. corrcntpd)+chgcntpd) FPd Rule 7. corrcntact)+chgcntact) FAct Rules 4 and 5 montor the frequences of ndvdual product and actvty. Rules 6 and 7 montor those of the entre proect. The functons corrcnt and chgcnt return the counts of correctng and changng products and actvtes, respectvely. They are offered by the KPSEE functons component n Fg. 1. The numbers FPd, FAct, FPd, and FAct are offered by the proect manager. The rule to montor the frequency of changng roles.e., the departure of software developers). Large frequency reflects the rsk of unstable development teams. Rule 8. deptcntrle) FRle The functons deptcnt returns the departure frequency of software developers. It s offered by the KPSEE functons component. The number FRle s offered by the proect manager. G. Rules to montor schedule and budget of ndvdual actvty and the entre proect. Over-schedule and overbudget are possbly the most threatenng rsk. Volaton of the followng rules) wll enforce the proect manager to take proper actons. Rule 9. Tme)-startTmeActID ) ActScRate*SchlActID ) Rule 10. BudgetActID )-usedbudgetactid ) ActBdRate*BudgetActID ) Rule 11. Tme)-startTmePr) PrScRate*TolSchl Rule 12. BudgetPr)-usedBudgetPr) PrBdRate*TolBudget Pr) The functon Tme gets the current tme. The functon starttme returns the start tme of an actvty or the entre proect. The functon usebudget returns the budget used by an actvty or the entre proect. Both starttme and usedbudget are offered by the KPSEE functons component. The functons TolSchl and TolBudget return the total schedule and budget of the entre proect. They are obtaned from the +ScheduleBudget statement. The numbers ActScRate, ActBdRate, PrScRate, and PrBdRate are offered by the proect manager. H. The rule to montor the reacton tme of an nformed role and that to montor the watng tme of an enactable actvty. Rule 13. Tme)-nformTmeRle ) ReactTme Rule 14. Tme)-etblTmeActID ) WatTme The functon nformtme returns the tme when the role Rle s nformed. The functon etbltme returns the tme when the actvty ActID s enactable. Both the

A Knowledge-based PSEE wth the Ablty of Proect Montorng 9 functons nformtme and etbltme are offered by the KPSEE functons component. The numbers ReactTme and WatTme are offered by the proect manager. The rules facltate mprovng proect effcency. The montorng rules reveal that the KPSEE functons component n Fg. 1 offers many functons for proect montorng. We do not descrbe them because of ther easness. For example, nformtme ust records the tme when a role s nformed. IV. FEATURES KPSEE offers the features mentoned n secton I. Excepton handlng s sold because of Algorthms 2 through 7. Software development organzatons can be dstrbuted because KPSEE s dstrbuted. Enhancng process flexblty s offered because KPSEE allows dynamc addng, removng, and changng process components anytme durng process enactment. Integratng PSEEs can be acheved because placng process programs translated from other PSEEs n any order becomes a KPSEE process program. Keepng pace wth sgnfcant change s obvous because the change as sgnfcant as addng, removng, or changng process component at anytme durng process enactment are allowed. The other features are proved below. Maxmze the degree of process parallelsm If an actvty s enacted mmedately when ts condton s true and ts nput products, requred roles, and tools are avalable, the degree of process parallelsm s maxmzed. Accordng to Algorthm 1, when the nput products of an actvty s avalable and ts condton s true, KPSEE nforms the roles trusted by the nput products. As long as the reacted roles are enough, the actvty s enacted wthout watng. Therefore, KPSEE maxmzes the degree of process parallelsm. Prevent technque leakage Suppose Rle n Org s a role that enacts the actvty ActID. Moreover, Org cannot access one or more nput products of the actvty. If ths stuaton occurs, technque leakage happens. However, Algorthm 1 nforms roles n the organzatons OrgIPdActID )) )) k TOrg OrgIPdActID )) ) k ) or those n AO to enact the actvty. If an organzaton cannot access one or more nput products of ActID, t s not n the organzaton set OrgIPdActID )) or AO. In other words, roles n the organzatons that cannot access one or more nput products wll not be nformed. Ths prevents technque leakage. Usng roles n trusted or authorzed organzatons s the basc concept of nformaton flow control to prevent technque leakage. However, the on operaton of an nformaton flow control model [24] s not mentoned the on operaton adusts the subect that can access an obect after an nformaton flow). In fact, the on operaton n KPSEE s acheved by the statement Rle subrle, Opd Rle n Algorthm 1. Wth the statement, a product depends on roles producng t. When the product should be accessed to enact ActID m, the set OrgIPdActID m )) )) TOrg OrgIPdActID m )) ) k) can correctly dentfy the organzatons that can access the product. Manage product consstency Accordng to Algorthm 1, a product produced by an actvty depends on the nput products. When a product should be changed, Algorthm 2 forces the actvty producng the product to be changed and enacted to change the product. Moreover, the followng algorthm segment ensures that the products drectly or ndrectly depend on the changed product wll be changed accordngly. affpdset = getdeppdsetpd ); Pd affpdset do ActID = getactidpd ); setstatuspd, U ); f statusactid ) = E ) then nformrleactid ), Stop enactment, ActID ); setstatusactid, D ); end do; When a product should be removed, Algorthm 3 removes the product and the actvty producng the product. Moreover, the followng algorthm segment removes the products drectly or ndrectly dependent on the removed product. affpdset = getdeppdsetpd ); Pd affpdset do ActID = getactidpd ); setstatuspd, D ); f statusactid ) = E ) then nformrleactid ), Stop enactment, ActID ); setstatusactid, D ); end do; When a product Pd should be corrected, Algorthm 6 requres the software developers that developed Pd to reenact the actvty to correct Pd. The algorthm also corrects the products drectly or ndrectly dependent on Pd through recursvely nvokng Algorthm 6 as shown below. affpdset = getdeppdsetpd ); Pd affpdset, corrpdpd ); Note that changng or removng actvtes may also affect products. Algorthm 4 nvokes Algorthm 2.e., the functon chgpdpd );) to handle the change of affected products and Algorthm 5 nvokes Algorthm 3.e., the functon rmvpdpd );) to handle the removng of affected products. The nvocatons ensure product consstency. k

10 A Knowledge-based PSEE wth the Ablty of Proect Montorng Currently, our knowledge base whch s KPKB) s homogeneously. To mprove the performance of KPSEE, we prepare to upgrade the ablty of KPKB to offer the ablty of storng heterogeneous knowledge [25]. We need ths ablty because dfferent software tools may create documents n dfferent formats. V. CONCLUSION Accordng to the change of enactment envronments and the ncrement of software development complexty, PSEE features should be enhanced. We desgned a knowledge-based PSEE named KPSEE. It offers the followng features, n whch some are enhanced ones. It maxmzes the degree of process parallelsm. When the nput products of an actvty are avalable and ts condton s true, KPSEE nforms the roles trusted by the nput products. As long as the reacted roles are enough, the actvty s enacted wthout watng. Therefore, KPSEE maxmzes the degree of process parallelsm. It enhances process flexblty. KPSEE offers the flexblty by allowng dynamc addng, removng, and changng any components at anytme durng process enactment. The flexblty s acheved by allowng unstructured statements and offerng strong excepton handlng functons. It manages product consstency. Durng the devaton of products and actvtes, KPSEE properly handles the products drectly or ndrectly dependent on the changed or removed product. Therefore, KPSEE manages product consstency. It ntegrates PSEEs. KPSEE process statements are unstructured. Therefore, when process programs n dfferent PSEEs are translated nto KPSEE process statements. They can be placed n any order to become an ntegrated KPSEE process program. Therefore, KPSEE ntegrates PSEEs. It keeps pace wth sgnfcant change of a process. KPSEE allows addng, removng, and changng any component of a process program at anytme. Wth ths, no sgnfcant change wll affect process enactment. That s, KPSEE keeps pace wth sgnfcant change of a process. It prevents technque leakage. KPSEE s fused wth an nformaton flow control model. Wth the model, when an actvty can be enacted, KPSEE nforms the roles whose organzatons are allowed to access all the nput products. Ths prevents technque leakage. It offers proect montorng ablty. KPSEE offers rules to montor proect related events. For example, t montors both schedule and budget of actvtes and the entre proect. REFERENCES [1] L. Osterwel, Software Processes Are Software Too, 9 th IEEE Internatonal Conference on Software Engneerng, 2-13, New York, 1987 [2] SERENA, An Introducton to Agle Software Development, avalable on http://www.serena.com/docs/ repostory/solutons/ntro-to-agle-devel.pdf [3] R. Matnnead and R. Ramsn, An Analytcal Revew of Process-centered Software Engneerng Envronments, IEEE 19 th Internatonal Conference and Workshops on Engneerng of Computer-based Systems, pp. 64-73, 2012. [4] S. -C. Chou, Usng Product Status to Coordnate Heterogeneous Process Envronments, IEICE Trans. Informaton and Systems, vol. E86-D, no.1, pp.56-62, Jan. 2003. [5] S. -C. Chou, ADPE: Agent-based Decentralzed Process Engne, IEICE Transactons on Informaton and Systems, E88-D3), 603-609, Mar., 2005. [6] S. C. Bandnell, A. Fuggetta, and C. Ghezz, Software Process Model Evoluton n the SPADE Envronment, IEEE Transactons on Software Engneerng, Vol. 19, No. 12, 1128-1144, Dec. 1993. [7] S. -C. Chou and J.-Y. J. Chen, Process Program Change Control n a Process Envronment, Software - Practce and Experence, vol. 30, no. 3, 175-197, 2000. [8] G. Cugola, Toleratng Devatons n Process Support Systems va Flexble Enactment of Process Models, IEEE Transacton on Software Engneerng, vol. 24, no. 11, 982-1001, 1998. [9] D. Km, M. Km, H. Km, Dynamc Busness Process Management Based on Process Change Patterns, Internatonal Conference on Convergence Informaton Technology, pp. 1154-1161, 2007. [10] W. She, I. L. Yen, B. Thurasngham, and E. Bertno, The SCIFC Model for Informaton Flow Control n Web Servce Composton, 2009 IEEE Internatonal Conference on Web Servces, 2009. [11] A. Myers and B. Lskov, Complete, Safe Informaton Flow wth Decentralzed Labels, 14 th IEEE Symp. Securty and Prvacy, pp. 186-197, 1998. [12] J. Y. J. Chen, CSPL: An Ada95-lke, Unx-based Process Envronment, the IEEE Transactons on Software Engneerng, vol. 23, no. 3, pp. 171-184, March 1997. [13] I. Z. Ben-Shaul and G. E. Kaser, A Paradgm for Decentralzed Process Modelng and ts Realzaton n the Oz Envronment, n Proceedngs of the 16th ICSE, pp. 179-188, 1994. [14] C. J. Hagen, A Generc Kernel for Relable Process Support, Ph. D. Dssertaton of the Swss Federal Insttute of Technology Zurch, 1999. [15] J.-Y. Chen and S.-C. Chou, Consstency Management n a Process Envronment, Journal of Systems and Software, vol. 47, pp. 105-110, 1999. [16] A.D. Luca, F. Fasano, R. Olveto, and G. Tortora, Fnegraned management of software artefacts: the ADAMS system, Software Practce and Experence, vol. 40, no. 11, pp. 1007-1034, 2010. [17] S. Weber, A. Emrch, J. Broschart, E. Ras, and O. U nalan, Supportng Software Development Teams wth a Semantc Process-and Artfact-orented Collaboraton Envronment, Proc. SOFTEAM'09, 2009 [18] M.A. Almeda da Slva, R. Bendraou, X. Blanc, and M.P. Gervas, Early Devaton Detecton n Modelng Actvtes of MDE Processes, LNCS, vol. 6395, pp. 303-317, 2010. [19] M.A. Almeda da Slva, R. Bendraou, J. Robn, and X. Blanc, Flexble Devaton Handlng durng Sofware Process Enactment, Proc. EDOCW'11, pp. 34-41, 2011. [20] R. S. P. Macel, R. A. Comes, A. P. Magalhaes, B. C. Slva, and J. P. B. Queroz, Supportng Model-drven Development Usng a Process-centered Software

A Knowledge-based PSEE wth the Ablty of Proect Montorng 11 Engneerng Envronment, Automated Software Engneerng, 203), pp. 427-461, 2013. [21] F.A. Alexo, M.A. Frere, W.C. dos Santos, and U. Kulesza, Automatng Varabtly Management, Customzaton and Deployment of Software Processes: A Model-Drven Approach, Proc. ICEIS'11, pp. 372-387, 2011. [22] R. S. P. Macel, B. C. Slva, and N. S. Rosa, An Integrated Approach for Model Drven Process Modelng and Enactment, Proc. SBES'09, pp. 104-114, 2009. [23] S. C. Chou, W. C. Hsu, and W. K. Lo, DPE/PAC: Decentralzed Process Engne wth Product Access Control, Journal of Systems and Software, 763), 207-219, June, 2005. [24] A. C. Myers, JFlow: Practcal Mostly-Statc Informaton Flow Control, Proceedngs of the 26 th ACM Symposum on Prncples of Programmng Language, 228-241, 1999. [25] M. K. Yusof, A. F. A. Abdn, and M. N. A. Rahman, Archtecture for Accessng Heterogeneous Databases, Internatonal Journal of Informaton Technology and Computer ScenceIJITCS), vol 4, no. 1, pp. 25-31, 2012. Authors Profles Shh-Chen Chou s a Professor n the Department of Computer Scence and Informaton Engneerng, Natonal Dong Hwa Unversty, Tawan. He s maor n software engneerng, process envronment, software reuse, and nformaton flow control. Chao-We L s a graduate student n the Department of Computer Scence and Informaton Engneerng, Natonal Dong Hwa Unversty, Tawan.