MM A Software Architecture for II CC EE MICE Meeting RR AA L L 77-1 1 00 JJ uu ll y y 22 00 00 22 M. G G.. Ca ta nes i Inf n BB aa rr i

What means Architecture? The Architecture is the structure of the softw a re p roj ect I t in cl ud es the stra teg y a n d scop es d efin ition, p rog ra m m in g l a n g ua g es, softw a re a p p l ica tion s a n d con v en tion s a s w el l a s com m un ica tion m a n a g em en t ( m eetin g s, w eb p a g es, m in utes etc. etc. ) C a n b e d efin ed m ore or l ess form a l l y d ep en d in g from the com p l ex ity of the p roj ect, the g eog ra p hica l d istrib ution of the p a rticip a n ts, the tim e sca l e etc. etc... But cannot be skipped

In view of the MICE proposal a coordinate effort is needed to produ ce resu lts!! W e have m anly 2 possib le approaches : 1 Produce the numbers needed by the p rop osa l usi ng a l l the p rog ra ms tha t w e ha v e D on' t ma k e a ny g enera l i nteg ra ti on ha v i ng i n mi nd tha t some w ork w i l l be l ost Postp one the crea ti on of the true M I C E S of tw a re env i ronment 2 C rea te a S of tw a re A rchi tecture A S A P Push on the i nteg ra ti on of the di f f erent sof tw a re modul es S top the dev el op ment w i th the a l rea dy used p rog ra ms

Choice 1 pro & con Pro No time spent working in the Organization Matter No f ormal isms and d ef ined ru l es and d isc ipl ine C onc entration of the ef f orts onl y on the primary sc ope Con A ( l arge) f rac tion of the work wil l b e not u sab l e in the f u tu re P ossib l e errors d u e to l ac k in c ommu nic ations b etween d if f erent programs P ossib l e interf erenc es and c onf l ic ts at the integration time

Choice 2 p r o & con Pro A (large) fraction of the work will be usable in the future O p tim iz e the resources and m inim iz e the p roblem s at the integration tim e Allows a coherent effort and m inim iz e conflicts Con T im e sp ent working in the O rganiz ation M atter form alism s and d efined rules and d iscip line are a m ust and a consensus on this p oint is m and atory N eed sp ecializ ed m anp ower

Software: The HARP Strategy Harp was approuved in the February 2000 and the data tak ing was started in m ay 2001 T o optim iz e q ual ity, devel oping tim e and hum an resourc es we dec ided to use software engineering tool s and in partic ul ar to real iz e an A rc h itec tu ral D esign T his c hoic e was suc c essf ul l y and we buil d a f irst running version of the f ul l c hain of our sof tware in f ew m onths f rom J une to O c tober 2001

But what this practically means? Use a well tested method to follow the software dev elop men t from the v ery early stag e (Project and M anag em ents Pl ans, U s er and s of tw are R eq u i rem ents ) u n ti l the fi n al p rodu c t tests ( T es t p l an and rel eas e p rocedu re) T he starti n g p oi n t shou ld b e alway s the S oftware P roj ec t M an ag emen t P lan that desc ri b es 1. the ob j ec ti v es to b e reac hed b y the p rog ram an d the org an i z ati on of the work 2. T he task an d resp on si b i li ti es 3. T he sc hedu le 4. T he strateg y to mi n i mi z e ri sk s

1. t h e o b j e c t i v e s t o b e r e a c h e d b y t h e p r o g r a m a n d t h e o r g a n i z a t i o n o f t h e w o r k User Requirements : d ef ine th e f unc tio na l ity th a t th e so f tw a re must h a v e f o r rea c h th e resul ts E x a mp l e: UR-4 : T h e u s e r s h a l l b e a b l e t o d e s c r i b e t h e d e t e c t o r g e o m e t r y c o n s i s t e n t l y, t h o u g h a l l o w i n g d i f f e r e n t r e p r e s e n t a t i o n s, f o r d i f f e r e n t a p p l i c a t i o n s. T y p e : c a p a b i l i t y ( o r c o n s t r a i n ) P r i o r i t y : e s s e n t i a l S t a t u s : i m p l e m e n t e d S R D r e f e r e n c e s : S R -1 9, S R -2 0, S R -2 1

The Software Requirements derive from the User Requirements and from strateg ic dec isions tak en in the c ol l ab oration. : T h e s o f t w a r e s h a l l r u n o n P C s w i t h L i n u x o p e r a t i n g s y s t e m. P S : T h e s o f t w a r e s h a l l h a v e b e e n d e v e l o p e d i n C / C + + p r o g r a m m i n g l a n g u a g e ( a t l e a s t f o r t h e c o l l a b o r a t i o n i d e s o f t w a r e ). P S SR-1 Type: constraint riority: essential tatu s: im pl em ented SR-2 -w Type: constraint riority: essential tatu s: im pl em ented

What is a Architectural Design? T he A r c hite c tu r e o f a so f tw ar e is r e al iz e d d e te r m in in g the c o m p o n e n ts ( d o m ain d e c o m p o sitio n ) an d the se t o f d e p e n d e n c y r e l atio n s b e tw e e n the id e n tif ie d e l e m e n ts E ac h c o m l ib r ar ie s p o n e n t is an in d e p e n d e n t u n it o f so u r c e c o d e an d T he c o n n e c tio n b e tw e e n the d if f e r e n t d o m ain s d e f in e s the d e p e n d e n c e s an d p r o d u c e s the tim e se q u e n c e f o r the te st an d r e l e ase o f the o f f ic ial c o d e A c o r r e c t d e c o m p o sitio n al l o w s a p ar al l e l d e v e l o p m e n t o f the d if f e r e n t p e ac e s o f c o d e an d the r e so u r c e o p tim iz atio n

E As example D i splay R ec o n st r u c t i o n S i mu lat i o n F R AM E v en t M o d el D et ec t o r R espo n se D et ec t o r D esc r i pt i o n R O O T C L H E P G E AN T 4

Ta s k a n d r e s p o n s i b i l i t i e s : In general is convenient to match the resp onsib ility assignment to the resu lts of the d omain d ecomp osition In this w ay w ill b e no amb igu ity lef t b etw een the su b comp onents T he share of the w ork is easier and max imiz e the p arallel d evelop ment red u cing conf licts and / or interf erences

The schedule : The schedule is defined on the base of the Domain dep endency str uctur e and fr om the definition of the testing and r elease p r ocedur e F or each step of the dev elop ment y ou can define a schedule and the r esult of this effor t should be a S oftw ar e R elease. I t w ill ev olv e in a new one follow ing the same test p r ocedur es

The Software is not a static object: The d ev el op m ent is org aniz ed as cy cl es F or each cy cl e al l the step s shou l d be rev ised ( scop es, sched u l es etc. etc. ) A s ex am p l e in H A R P we hav e real iz ed u ntil now sev eral cy cl es to reach d ifferent g oal s 1. Technical R u n 2 0 0 0 2. Start of R u n 2 0 0 1 3. SP SC p resentation O ctober 2 0 0 1 4. L arg e A ng l e A nal y sis m ay 2 0 0 2

Coming back to MICE my p e r s onal v ie w A lot of efforts was made in the simulation of b oth detec tors and c ooling c hannel using different software ap p lic ations ( P AT H, I C O O L, G E AN T 4 ) T he c omp arison b etween the v arious p ac k ag es was done ex tensiv ely T he rec onstruc tion is on the c ontrary at a v ery early stag e

What is urgent. (still my point of view..) The collaboration have not yet made any general technical choice abou t: W Platform (Unix?) L ang u ag e (F ortran + C + +?) R e p os itory (C V S?) W h e re w e maintain th e s ou rc e c od e (C E R N + a mirror at F E R M I L A B?) hitou t this is imp os s ible to made any coherent ef f ort

What is urgent. (c o ntinue..) A form of communication management has been establ ished based on regul ar meetings, email minutes and w eb p ages B ut N o official d ocuments are av ail abl e and the testing and rel ease p roced ures are not formal iz ed T he l ack of d ecisions about the use of the ex ternal l ibraries manifest itsel f as a crisis at the integration time I n this w ay the ex change of cod e and the rep rod ucibil ity of resul ts is hard to be obtained

I strongly suggest that Independently by the decision about the appr oach 1 or 2. T o im plem ent al list the points m ar k ed in m y last 2 slides If you decide to f ollow the appr oach 2 also a dom ain decom position is a m andate In this last case the H par tially r eused A R P one can be

A critical point MICE use both package used in the Accelerator word and in H EP word T his is nice f eature but the interf ace between the two words it s not triv ial In particular the cooling channel was ex tensiv ely sim ulated using P AT H & ICO O L running on N T and written in f ortran, the H EP program s being on U N IX and written in C+ + T he porting of P AT H & ICO O L on U N IX is im portant T f & + he interf aces between ortran c+ program s need to be ex tensiv ely cheeked T he use of a f ram e like G AU D I can accom m odate both and be the f inal solution

Software: The HARP Strategy Harp was approuved in the February 2000 and the data tak ing was started in m ay 2001 T o optim iz e q ual ity, devel oping tim e and hum an resourc es we dec ided to use software engineering tool s and in partic ul ar to real iz e an A rc h itec tu ral D esign T his c hoic e was suc c essf ul l y and we buil d a f irst running version of the f ul l c hain of our sof tware in f ew m onths f rom J une to O c tober 2001