petri nets 2000 - tidsskrift.dk
TRANSCRIPT
ISSN 0105-8517
Petri Nets 200021st International Conference on
Application and Theory of Petri Nets
Aarhus, Denmark, June 26-30, 2000
Workshop Proceedings
Software Engineering and Petri Nets
Organised by
Mauro PezzeSol M. Shatz
DAIMI PB – 548
June 2000
DEPARTMENT OF COMPUTER SCIENCEUNIVERSITY OF AARHUS
Ny Munkegade, Bldg. 540DK-8000 Aarhus C, Denmark
Preface
This booklet contains the proceedings of the Workshop on Software Engineering andPetri Nets (SEPN), held on June 26, 2000. This workshop was held in conjunction with the21st International Conference on Application and Theory of Petri Nets (ICATPN-2000),organised by the CPN group of the Department of Computer Science, University of Aarhus,Denmark. The SEPN workshop papers are also available in electronic form via the webpage: www.daimi.au.dk/pn2000/proceedings
The aim of the workshop was to bring together researchers and practitioners with inter-ests in Petri nets and/or software engineering, with the goal of exploring more closely thepotential impacts and pitfalls in applying net-based formalisms to software developmentproblems.
All submitted papers were refereed and evaluated under the direction of a program com-mittee with the following members:
Jonathan Billington, University of South Australia (Australia)Ugo Buy, University of Illinois at Chicago (USA)Robert France, Colorado State University (USA)Dino Mandrioli, Politecnico di Milano (Italy)Mauro Pezze, Politecnico di Milano (Italy)Sol Shatz, University of Illinois at Chicago (USA)
The program for the workshop included ten selected papers and two invited talks. Theinvited speakers were: Professor Michal Young (Oregon State University, USA) and Pro-fessor Manfred Broy (Technishe Universitat Munchen, Germany).
Mauro Pezze and Sol ShatzCo-organizers, SEPN-2000
Table of Contents
J. Merseguer, J. Campos, E. MenaPerformance Evaluation for the Design of Agent-based Systems: A Petri Net Approach 1
A. Chandler, A. Heyworth, L. Blair, D. SewardTesting Petri Nets for Mobile Robots Using Grobner Bases . . . . . . . . . . . . . . 21
M. Ceska, V. Janousek, T. VojnarGenerating and Exploiting State Spaces of Object-Oriented Petri Nets . . . . . . . 35
H. Giese, G. WirtzThe OCoN Approach for Object-Oriented Distributed Software Systems Modeling . 55
S. PhilippiSeamless Object-Oriented Software Development on a Formal Base . . . . . . . . . 75
N. C. Narendra, I. P. PalAn Architecture for Adaptive Planning and Scheduling of Software Processes Using
Timed Colored Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A. Burns, A. J. Wellings, F. Burns, A. M. Koelmans, M. Koutny, A. Romanovsky,A. Yakovlev
Towards Modelling and Verication of Concurrent Ada Programs Using Petri Nets . 115
J. Vachon, N. GuelfiCOALA: A Design Language for Reliable Distributed Systems Engineering . . . . . 135
M. Lemmon, K. X. HeSupervisory Plug-ins for Distributed Software . . . . . . . . . . . . . . . . . . . . . 155
K. El-Fakih, H. Yamaguchi, G. v. Bochmann, T. HigashinoProtocol Re-synthesis Based on Extended Petri Nets . . . . . . . . . . . . . . . . . 173
����������� ��������������������������� �!��"��#���$%��&��(')� ��* '�+�)�-,/.���&0��132546&7�0�8 &:9 * ���;�0���=<>�;� *@?A? �������B#6C
DFEFGIHJ�KAJ�L G JNM!OIJNLNP DRQTSVU JNL�W Q!XZY[ERG P Q!\^]�_B] O Q L ]IE KAJ \^Q
`;aFbdc!eRf!g�hji!klcNmdnpoq bdrts q g;huiRvwgxiRrtgxmyoz q fFg�{�rt|}bdgyn q |y~F�:iFr��wgxmd|�r�bj�cNk7� q m q vwcN� q ~^{�a q r�i���y�R�w�!���������w�x�!�!���[�j���R�N�!�T���N�!���(���������F�(���w�-�j���
���¡ y¢y£(¤V¥N¢w¦ {�cNk§bu¨ q mdg©f!gy|�rtvwi q iVf�rtn�aRªtgyn�gxi�b q bdrtcwi�«F|�rtiRv�n�cw¬Frtª�g q vwgyi�bd| q mdgiFc(¨ q f q �!|�rti��TcNª��wg�frti q |�sygya!bdrtsyrt|�n�® q ªtcFeF¯�®Rgxmdg q mdgBmdgy|�g q mds°®Fgxmd|�¨�®Rc8±�«Rgy|}²bdrtcwi³r�bd|8«!bdrtª�r�bu�5¬´gys q «F|�g�r�b�sycw«Fªµf6¬´g q iFgx¨¶bdgys·®RiFcwªtcwv��6bd® q b8f!c�gy|�aFmdc(��r�fFgiFgx¨A|�¸�rtª�ªt|�¬F«Fb/rtb/sycw«Fª�f�rti�b�mdc�fF«Fsyg7iRgx¨Aa!mdcw¬Fª�gxn�|ye�{!gysx«Fmdr�bj� q iVf;a´gxm�k§cNmdn q iRsygq mdg;bd®Rg;n�cN|}b�sxmdr�bdrts q ª q |�a´gysxbd|�k§cNm�bd®Rrt|�iRg°¨=¸�rtiVf�cNk�|�cNk§bu¨ q mdgweVhuibd®Fr�|�a q a´gxm¨0g)aFmdgx|�gyi�b q klc�mdn q ª q aRaFmdc q s·®Abdc q i q ªt�!|�ga´gxm�klc�mdn q iFsygk§cNmbd®Frt|�syª q |�|�cNk|}�!|}bdgyn�|ye[¹:«!m q aFaFmdc q s·®ºrt|;rti�bdgyvNm q bdg�f³rti5bd®Rg8g q mdª��6|}b q vNgy|�cNk»bd®Rg�|�c�k§bu¨ q mdgf!gy�TgyªtcwaFn�gyi�b�aFmdc�sxgy|�|yeVhui�bd®Rrt|�¨ q ��~Fr�b�rt|Ba´cN|�|�rt¬Rªtg�bdcaFmdg�f!rtsxb�bd®Rg;¬´gx® q ��r�cN«Fm¨�r�bd®RcN«Fb;bd®Fg+iFgysygy|�|�r�bu�¼bdc�s q m�m��5cw«!b:bd®Rg+sycwn�aFªtgxbdg+rtn�aFª�gxn�gyi�b q bdrtcwi¼aF® q |�gNe¯/c�|�®Rc�¨½bd®Rg q aRa!mdc q s°®^~^¨0gn�c�fFgxª q |�cNkµbj¨ q mdgmdgxb�mdrtgy� q ª7|�gxmd��r�sxg|}�!|}bdgyn¾rtiq a!m q vNn q bdrts;¨ q ��~!ª q bdgxm�~Fbd®Rg;syc�m�mdgy|�a´cwiRfFrtiRvk§cNmdn q ª[n�c�f!gyªIr�|�cN¬Fb q rtiFg�f q iRfq i q ª��!|�g�f)rtiZc�m·fFgxm�bdc|}bd«Rf!��a´gxm�k§cNmdn q iRsygwe
¿AÀFÁ¡Â�Ã^Ä�Å0Æ!Ç^ÈVE!ÉËÊdÌ:Q L°J Y J�L ÉÍE L X¼Q�\^Î J!P´Ï�J Ê L U¡\ J ÊxG P^Ð8KÒÑ�P XZE!Ó^UµÔ J Q M!J \RÊ
Õ ÖR×BØ´ÙIÚ�Û+Ü8Ý/ØIÞdÚB×
ß�\5Ê°à J ÔlQ!G·Ê©á J Q L G P ]´UlGdÊ L U§Ó O Ê J ]³G·E!ÉËÊdÌ:Q L°J Q!YIYIÔ§U§ÎNQ�ÊxUµEF\^GBà[QTS J U§\^Î LxJ QFG J ]ZÊ°à J U L Y/EFGxG°UµÓIU§ÔµâU�ÊxU J G�X¼Q�ãVU§\ M¼O G J E�É�ß�\RÊ J�L \ J Ê8Î�Q�Y[Q�ÓIU§ÔµUµÊ°U J G P Y/EFG°UµÊ°U§E!\IU§\ M ]´UlGdÊ L U§Ó O Ê J ]AG°E�ÉËÊdÌ;Q LxJ ] J S J ÔµâE!YIX J \RÊ�Q!G;Q�S J�L áZUµ\RÊ JNL°J GdÊxUµ\ M Q!YIY L EFQ!Îyà7äFå;à J Î(Ô§U J \RÊ�æ�G JNL S J�L XZE´] J Ô¡à[Q!G:Ó J Î(EFX J Ê°à Jã J áÒY^Q L Q!]´U M XçÊxEAG O Y^Y[E L Ê�]´UlGdÊ L U§Ó O Ê J ]èG°E�ÉËÊdÌ;Q LxJ ] J S J Ô§E!Y^X J \RÊNä¡ß}Ê�U§G�Ì�U§] J Ôµá L°J Î(E M â\IU§G J ]6Ê°à[Q�Ê;Ê°à JNL°J Q L°J ÉÍE OIL X¼Q�U§\³Ê J Îyà^\IE!Ô§E M U J GBÌ�àIUlÎyà�Q!]´SFEVÎNQ�Ê J ÉÍE L Î�ÔµU J \RÊ(æ�G J�L S J�L ] J âS J Ô§E!Y^X J \RÊxGNÇ L°J Ô§Q�Ê°U§E!\^Q!Ô7]IQ�ÊxQ�Ó[Q!G J XZQ!\^Q MFJ X J \RÊ8G°á´GdÊ J X¼G�é�ê8ë+ì K ÈIí P å Ï X)EF\IUµÊ°E L G PM!L E O YVÌ;Q LxJ Q�\^]î]´UlGdÊ L U§Ó O Ê J ]pE!Ó´ï J Î�ÊyG�ä�ß}Ê�U§GÌ J Ô§Ô�Q!ÎNÎ J Y´Ê J ]AÊ°à[Q�Ê�]´UlGdÊ L U§Ó O Ê J ]pE!Ó´ï J Î�ÊxGUµ\AÎ(EF\�ï O \^Î(Ê°U§E!\�Ì�UµÊ°àèðZñFò(óËô§õ)öN÷Fõ�ø^ùuú5û�üTý P üFü�þ-Ê J ÎyàI\IEFÔµE M á5Q LxJ Q)S J�L á5U§\RÊ J�LxJ G·Ê°U§\ M Q�YIâY L ERQ!ÎyàÊ°E�Q!]^] L°J G°G�Î J�L ÊxQ!Uµ\)ãVUµ\^])E!É�G°E�ÉËÊdÌ;Q LxJ ]IE!X¼Q�U§\^G�Ô§Uµã J:J â}Î�E!XZX J�L Î JFP Uµ\´ÉÍE L X¼Q�Ê°U§E!\L°J Ê L U J STQ!Ô-Q�\^]³\ J ÊdÌ©E L ã¼X¼Q�\[Q M!J X J \RÊ�Q�\^]ºQ!]´XZU§\IUlGdÊ L Q�Ê°U§E!\-äÿ ԵʰàIE OIM à�Êxà J�LxJ Q LxJ�L°J G J Q L Îyà J�L G:Ì�àIE�� OIJ GdÊxUµEF\ºXZEFÓIUµÔ J G°E�ÉËÊdÌ;Q LxJ!P UµÊ8ÊyQ�ã J G�G J \^G J
Uµ\A]´UlGdÊ L U§Ó O Ê J ] J \VSVU L E!\^X J \RÊxGû ��þ-Ó J Î�Q O G J UµÊ�U§G�Q�Ê J ÎyàI\IEFÔµE M á¼Ì�UµÊ°à�Q�YIY L EFY L UlQ�Ê J \ J ÌG·ãVU§ÔµÔlG;ÉÍE L Ê°à J G J ãVU§\^]�E�É�G°á´GdÊ J X¼G�ä/ì O Ê8UµÊ+Î(E O Ô§]ºU§\RÊ L EV] O Î J \ J Ì Y L E!ÓIÔ J X¼G�QFG;Ê°à J Uµ\´âQ�YIY L E!Y L UlQ�Ê J+O G J E�É0Ê°à J \ J Ê LxJ G°E O^L Î J GNäRß�\ºÊxàIU§G8Ì:QTáZÊxUµX J Î�E!\^G O XZU§\ M Î(E O Ô§]ºÓ J Î(EFX JQ�Y L EFÓIÔ J X¾ÉÍE L�O G J�L GNä´È´E P Ì J Q L°J Î(EF\^Î JNL \ J ]¼ÊxEZ] J S J ÔµEFY6\ J Ì½Ê J ÎyàI\IU�� OIJ G�Q!\^]³X J Ê°à´âEV]^G+Ì�à^U§Îyà XZU§\IU§X)U�� J Êxà J G J Y L E!Ó^Ô J XZGNä/ß�\ Ê°à^U§GÎ(EF\RÊ J�� Ê P ú�ñ�yù�Bö �°õ��^õ����(ñ ��ðZö�ø��yõ ûµü��TþQ�YIY J Q L G�Q!GQp]´UlG°Î�UµYIÔ§U§\ J U§\^G°U§] J G·E!ÉËÊdÌ:Q L°J¼J \ M U§\ JNJ�L Uµ\ M Ê°Ep] J Q�Ô©Ì�U�Êxà XZE´] J Ô:Y J�L ÉÍE L âXZQ!\^Î J EF\AG·E!ÉËÊdÌ:Q L°J G·á´G·Ê J XZG8] J G°U M \-ä Ñ Uµã J X¼Q!\Rá³Y J E!YIÔ J Î(EF\^Î JNL \ J ]�Q�Ó/E O Ê8G°E�ÉËÊdÌ;Q LxJ� ¯�®Rrt|/¨0cNmd¸;® q |/¬´gxgyi8fFgy�Tgxª�cNa´g�f:¨�r�bd®Rrti�bd®Rg-aFmdc��}gys°b-¯��������(²��� "!#�©c�kFbd®Fg0{�a q iRrt|�®�$0h%$'&�¯:e
1
Y JNL ÉÍE L X¼Q�\[Î J!P Ì J Ó J Ô§U J S J Ê°à[Q�Ê;Ê°à J Y J�L ÉÍE L X¼Q�\^Î J8J S�Q!Ô O Q�Ê°U§E!\³X O G·Ê�Ó J Q!ÎNÎ(EFX)Y^ÔµUlG·à J ]] OIL Uµ\ M Êxà J�J Q L Ô§á6G·ÊxQ MFJ G:E�É0Ê°à J G·E!ÉËÊdÌ:Q L°J ] J S J Ô§E!YIX J \RÊ�Y L E´Î J GxGNä
(»ø^ó ):õ+*-,Òñ�*!õ�ôtóËøR÷/.7ö�øR÷10^ö�÷Rõ�é Ð8KÒÑ í�û 2�þ0UlG8Ì�Ul] J ÔµáAQ!ÎNÎ J Y´Ê J ] Q!G�Q5G·ÊxQ�\[]IQ L ]A\IE!âÊxQ�ÊxUµEF\ Ê°EîXZE´] J Ô�G°E�ÉËÊdÌ;Q LxJ G·á´G·Ê J X¼GNä Ð \´ÉÍE L Ê O \^Q�Ê J Ô§á P�Ð8K Ñ ÔlQ!Îyã´G�E!É�Ê°à J \ J Î J GxGxQ L áJ�� Y LxJ GxG·U§S J \ J GxG+Ê°EAQ!ÎNÎ OIL Q�Ê J Ô§áÒ] J GxÎ L U§Ó J Y J�L ÉÍE L XZQ!\^Î J G°ãVUµÔ§Ô§GNä7å;à JNL°J à^QTS J Ó JNJ \ G J SRâJ�L Q�Ô»Q!YIY L EFQFÎyà J G;ÊxE³G°E!Ô§S J ÊxàIUlG+ÔlQ!Îyãèûµü�� P 2 3 P ü�4Tþjä65+\ J E�É�Ê°à J�M EFQ�ÔlG�E!É�Ê°àIUlG+Y^Q�Y J�L U§GÊ°à J G·Ê O ]Iá5E�É0Ê°à J Y J�L ÉÍE L X¼Q�\^Î J U§\^]´UlÎ J G;Uµ\�XZE!Ó^UµÔ J Q M!J \RÊ�G°á´GdÊ J X¼G P Ê°à O G P Ì J Y L E!Y/EFG JQ7(�,/.8�óËù:9;�^õ����(ñ ��ðZö�ø��yõ�ö�ø[ø/ñ�ù}ö�ùuó�ñ�øIúéÍY[Q�â Ð8K Ñ í0Ê°E] J Q�Ô[Ì�U�Êxà5Y J�L ÉÍE L XZQ!\^Î J G°ãVUµÔ§Ô§GE!\pÊ°à J G J ãVUµ\[]pE!É:G°á´GdÊ J X¼G�ä'5 O^L Q�YIY L EFQFÎyàAÊ°EAG°E!Ô§S J Ê°à J Y L EFÓIÔ J X UlG�Q!G�ÉÍE!Ô§Ô§E�Ì�G�Ç�Ì JX)E´] J Ô�Ê°à J Y L E!Ó^Ô J X ]´E!X¼Q�U§\ O G·U§\ M Y^Q�â Ð8K ÑBP ] J GxÎ L UµÓ^Uµ\ M G·ÊxQ�ÊxU§Î�Q�\[]6]´áV\^Q!X)UlÎ+SRU J Ì�GÌ�à J \Z\ J Î J GxGxQ L á!äTY^Q�â Ð8KÒÑ XZE´] J Ô§G�Ì�U§ÔµÔ M U§S J:O G�Ê°à J \ J Î J GxG°Q L áÓ^QFÎyã MFL E O \^]�Ê°EE!Ó´ÊyQ�U§\Ê°à J Î(E L°LxJ G°Y[EF\^]´U§\ M ÉÍE L X¼Q�Ô/XZE´] J Ô J�� Y LxJ GxG J ]5QFG=<�õ�ù>��ó0ø�õ(ùuú�ûµü�?Tþ}äA@ L E!X Y^Q�â Ð+K Ñ�P Ì J] J�L UµS J Q�Ê°U§X J Uµ\RÊ J�L Y L°J ÊxQ�Ê°U§E!\ZE�É Ï�J Ê L U´\ J ÊxGBÔ J Q!]´U§\ M ÊxECB J \ JNL Q!ÔµU�� J ]¼ÈRÊ°E´Îyà^QFGdÊxU§Î Ï�J Ê L UD J ÊyG�é>B�È Ï D�íûµü�þ}ä¡å;à O G P Ì J UµXZYIÔ§U§Î�U�ÊxÔµá M UµS J Q5G J X¼Q�\RÊxU§ÎNG�ÉÍE L Y^Q�â Ð+K Ñ U§\AÊ JNL X¼G+E�ÉÏ�J Ê L U¡\ J ÊxGNä Ï�J�L ÉÍE L X¼Q�\^Î J U§\^]´UlÎ J G�XZQTá6Ó J Î�E!XZY O Ê J ]³ÉÍE L B�È Ï D ÓVá6Q�Y^YIÔµáVU§\ M � O Q�\IâÊ°UµÊxQ�ÊxUµS J Q�\^Q!Ôµá´G°U§G©Ê J ÎyàI\IU�� OIJ G�Q!Ô LxJ QF]´á5] J S J Ô§E!Y J ]³U§\³Êxà J Ô§U�Ê J�L Q�Ê O^L°J äå;à JAL°J GdʼE!É+Êxà J Y^Q�Y J�L U§G¼E L°M Q�\IUlG J ] QFG)ÉÍE!Ô§ÔµE�Ì�GNä�ß�\¶G J Î�ÊxUµEF\E2 P Ì J ] J GxÎ L UµÓ J Q
G·á´G·Ê J X P Ó^Q!G J ] E!\ Q MFJ \RÊxG P Ì�à^U§Îyàpà^Q!G8Ó JNJ \ ÊyQ�ã J \�É L E!X>û�ü"2wþ}ä[ß�\îG J Î�Ê°U§E!\F? P Ì JM UµS JE OIL Y L EFY[ERG°Q!Ô�Ê°EÒQ!\I\IE!ÊxQ�Ê J G·á´G·Ê J X%Y J�L ÉÍE L X¼Q�\^Î J Q!G°Y J Î�ÊxGUµ\ Ð+K Ñ é�Y^Q�â Ð8KÒÑ í�Q!\^]Ì J ] J S J Ô§E!Y6Ê°à J Y^Q�â Ð+K Ñ X)E´] J Ô§G©ÉÍE L Êxà J G°áVG·Ê J X Y LxJ G J \RÊ J ]5U§\ºG J Î(Ê°U§E!\G2Iä^È J Î(Ê°U§E!\/HU§G�] J ]IU§ÎNQ�Ê J ]ºÊ°E6Ê L Q�\^G·ÉÍE L X Y[Q�â Ð8K Ñ ]IU§Q M!L Q�X¼G�U§\FÊxE Ï�J Ê L U-\ J ÊyG8U§\ E L ] JNL ÊxE6Q!ÎyàIU J S JÊ°à J ] J G°U LxJ ]¼ÉÍE L XZQ!Ô^XZE´] J ÔjäI@»U§\^Q!ÔµÔ§á P G·EFX J Y JNL ÉÍE L X¼Q!\^Î J�LxJ G O ÔµÊxG©Q�\^]5Î�E!\^Î�Ô O G·U§E!\^G©Q LxJY L°J G J \RÊ J ]-ä
J K¶×MLONQPSRUT�VWLYXØ[Z\L^]:Ú`_xØ a7P�Ù[LcbdL¡Ø´Ù^ÞWLOefPSVG]�L7ÙAe�Þ·Ý�L¾Þ·×@ØAZgLKEhjikKdbdlmipÖAlmKonqp\nFØIL'R
ß�\AÊ°àIUlG�G J Î�Ê°U§E!\ÒÌ J Ó L U J�r áºY LxJ G J \RÊ ÿ D8å ÿ ê W å;ß W ÿts ä�å;à J G°áVG·Ê J Xçà^Q!G8Ó JNJ \ ÊyQ�ã J \É L EFX¾ûµü�2TþVQ!\^]�UµÊ0Ì�U§ÔµÔRÓ J©O G J ]Q!G7Q!\ J�� Q!X)Y^Ô J Q�Ô§E!\ M ÊxàIUlG7Y^Q!Y JNL ÊxE+G·Ê O ]Iá�Y J�L ÉÍE L X¼Q�\^Î JE!\ºX)EFÓIU§Ô J Q M!J \RÊ�G°áVG·Ê J X¼G�äå;à J5M ERQ�Ô�E!É�Ê°à J G·á´G·Ê J X%UlG�ÊxE Y L E�SVU§] J XZEFÓIUµÔ J Î�E!XZY O Ê J�L�O G JNL GÌ�U�Êxà ]´Uvu JNL°J \RÊ
G JNL SVUlÎ J G�Êxà^Q�Ê J \Ià^Q!\^Î J Êxà J Î�Q!Y^Q�ÓIU§Ô§U�ÊxU J G�E�É:Ê°à J U L Î(E!XZY O Ê J�L äw5+\ J E!É©Êxà J G J G JNL SVUlÎ J GU§G�Ê°à J È´E�ÉËÊdÌ;Q LxJ ê J Ê L U J S�Q�Ô0È J�L SVU§Î J!P Êxà^Q�ÊQ�Ô§ÔµE�Ì�G O G J�L G;ÊxE6G J Ô J Î�Ê+Q!\^]�]´E�Ì�\IÔ§EFQF]³\ J ÌG·E!ÉËÊdÌ:Q L°J U§\ÒQ�\ J QFG·áºQ�\^] J#x Î(U J \RÊ8Ì;QTá!ä^å;àIUlG8G J�L SVU§Î J à^Q!G�Ó JNJ \AÊxàIE OIM àRÊ�Ê°E5Ì:E L ã6U§\Q�Ì�U LxJ Ô J GxG;\ J ÊdÌ:E L ã¼X J ]´UlQZQ�\^]ºY L E�SVU§] J G;G J S J�L Q�Ô�U§\RÊ J�LxJ G·Ê°U§\ M É J Q�Ê OILxJ GNÇ
y å;à J G°áVG·Ê J X X¼Q�\[Q M!J G»Ê°à J ãV\IE�Ì�Ô J ] MFJ \ J�J ] J ]�Ê°E LxJ Ê L U J S J G°E�ÉËÊdÌ;Q LxJ Ì�UµÊ°à^E O Ê O G JNLUµ\RÊ J�L S J \RÊxUµEF\ P´O G°Uµ\ M Q!\³EF\FÊxE!Ô§E M á!äy å;à J Ô§EVÎNQ�ÊxUµEF\ºQ!\^]³QFÎ�Î J GxG;X J Ê°àIE´]³Ê°E LxJ XZE�Ê J G·E!ÉËÊdÌ:Q L°J U§G:Ê L Q!\^G°Y^Q LxJ \RÊ:Ê°E O G J�L G�äy å;à J�LxJ U§G8Q{zxÎ�Q�ÊxQ�Ô§E M}| Ó L E�Ì�G°Uµ\ M É J Q�Ê OILxJ Ê°E¼à J ÔµY O G J�L U§\AG·E!ÉËÊdÌ:Q L°J G J Ô J Î�ÊxUµEF\-äy å;à J G°á´GdÊ J X X¼Q�U§\RÊxQ�U§\^G O Y Ê°Eî]IQ�Ê J Êxà J U§\´ÉÍE L X¼Q�ÊxUµEF\ L°J Ô§Q�Ê J ]îÊxE Êxà J QTS�Q�U§ÔlQ�ÓIÔ JG·E!ÉËÊdÌ:Q L°J äß�\³Êxà J ÉÍE!Ô§Ô§E�Ì�Uµ\ M[P Ì J Ó L U J�r áº] J GxÎ L U§Ó J Êxà J G·á´G·Ê J X Y^QTáVU§\ M Q�Ê·Ê J \RÊ°U§E!\�U§\�U�ÊyG8Î(EFX)â
Y[EF\ J \RÊxGNäFå;à J�LxJ U§G:Q~z°XZQ�ïdE L ]´E!XZE | \[Q�X J ]��+ô �+�xõ�* P Ì�à^U§Îyà5UlGBQ!\5Q MFJ \RÊ©G°Y J Î(UlQ�Ô§U§G J ]ZU§\� �©«!bdcwiRcNn�cw«F| q vwg+�:¯ ¬}�©|�g�f q�� $0®Rr�bdgys°bd«Fmdg�klc�m;sy«F|d¯/cwn�rt�yg�f�n�cw¬Rhuªtgg$0cwn�aR«!bdrtiRv��©|�|�rt|}²b q iFsygwe
2
O G JNL Uµ\RÊ J�L Q!Î�ÊxUµEF\-ä¡å;à J�LxJ U§GQ��¡ñW�yù>Bö��°õ�,Òö�ø/öN÷Fõ#��Q M!J \RÊÌ�à^EFG J ÊyQ!G°ã U§G�Ê°EAÎ LxJ Q�Ê J QÎ�Q�ÊyQ�Ô§E M Ì�àIUlÎyàAÌ�UµÔ§Ô7à J Ô§Y�Ê°à J�O G JNL Ê°E5G J Ô J Î(Ê�Ê°à JL°J � O U LxJ ]ºG·E!ÉËÊdÌ:Q L°J ä ÿ \IE!Ê°à JNL Q M!J \RÊ PÊ°à J{� �°ñ��ú�õ#�ÒÌ�U§ÔµÔ8à J Ô§Y Ê°à JAO G J�L U§\¶G J Ô J Î�ÊxUµ\ M Êxà J G·E!ÉËÊdÌ:Q L°J äS@»U§\^Q!ÔµÔ§á P Q���ö�ôµõ(úyð¼ö�øQ M!J \RÊUlG�U§\ Îyà^Q LxM!J E�É�Y J�L ÉÍE L XZUµ\ M Q!\RápQ!Î�ÊxUµEF\èY L°J SVUµE O G�Ê°E�Êxà J U§\^GdÊyQ�Ô§Ô§Q�Ê°U§E!\îE�É;Ê°à JG J Ô J Î�Ê J ]�G·E!ÉËÊdÌ:Q L°JFP Ô§Uµã J�J â�Î(EFX)X JNL Î J äå;à J G°áVG·Ê J X�Ì;Q!G-Y L EFY[ERG J ]Uµ\5ûµü�2Tþ O G°U§\ M ]´Uvu JNL°J \RÊ-Ê J ÎyàI\IE!Ô§E M U J G P \^Q�X J Ô§á W 5�ê�ì ÿû�ü�H�þ P}� å�å Ï Q!\^])X)EFÓIU§Ô J Q M!J \RÊyG�ä!ÈVEFX J Y JNL ÉÍE L X¼Q�\[Î J Ê J GdÊyG�Ì JNL°J Q!YIYIÔ§U J ]�Ê°E�]´Uvu JNL°J \RÊUµXZYIÔ J X J \RÊyQ�Ê°U§E!\[G P U§\èE L ] J�L Ê°EAG J Ô J Î(Ê�Ê°à J Ó J G·Ê�Ì:QTá E!É:QFÎ�Î J G°G°U§\ M³LxJ XZE!Ê J G·E!ÉËÊdÌ:Q L°J äW E!\^Î�Ô O G°U§E!\^G;Ì J�LxJ Êxà J ÉÍE!Ô§Ô§E�Ì�Uµ\ M Ç
y å;UµX J Î�E LxL°J G·Y/E!\^]IUµ\ M Ê°E W 5�ê8ì ÿ Q!\^]�X)EFÓIU§Ô J U§X)Y^Ô J X J \RÊxQ�ÊxUµEF\^G Q L°J Q�Ô§XZEFG·ÊU§] J \RÊ°UlÎ�Q!Ô¡ÉÍE L Q)Ì�Ul] J�L Q!\ M!J E�É'�^Ô J G;ÊxE)Ó J ]´E�Ì�\IÔ§EFQF] J ]-äy K E!Ó^UµÔ J Q MFJ \RÊ+Q!YIY L EFQ!Îyà J G�Q LxJ É�Q!G·Ê J \IE OIM à�Ê°E6Î�E!XZY J Ê J Ì�U�ÊxàÒÎ(Ô§U J \RÊ�æ�G JNL S J�L Q�YIâY L EFQ!Îyà7ä
ÿ ԵʰàIE OIM àAÎ(EF\^G°U§] JNL U§\ M Ê°à J UµXZY/E L ÊxQ�\[Î J Q�\^]³Êxà J�L°J Ô J S�Q�\^Î J E!É»Êxà J�LxJ G O Ô�ÊyG�E�É0Ê°à JÌ©E L ã ûµü�2Tþ P Ì J Ì:E O Ôl]pÔµU§ã J Ê°EAG·Ê LxJ GxG8Êxà JZJ \IE L XZE O GÎ(EFG·ÊE�É©U§XZYIÔ J X J \RÊ°U§\ M ]´Uvu JNL°J \RÊY L E!Ê°E!ÊdáRY J GZU§\ E L ] J�L ÊxE J S�Q�Ô O Q�Ê J Êxà J Y J�L ÉÍE L X¼Q�\^Î J E!É+Êxà J ]´Uvu JNL°J \FÊ5Q!Ô�Ê J�L \^Q�ÊxUµS J GNäß�\ Ê°à JºLxJ G·Ê�E�É�ÊxàIUlGY^Q!Y JNLNP Ì J XZE´] J Ô©Ê°à J G°áVG·Ê J X Uµ\ QÒY L Q M X¼Q�Ê°UlμÌ:QTá O G°Uµ\ M Y^Q�âÐ8K ÑBP Q�\I\IE!ÊxQ�Ê°U§\ M Î�E!\^G°UlGdÊ J \RÊ°Ô§á�Ê°à J G°á´GdÊ J X Ô§EFQF] éÍÌ J à^QTS J Q�\I\^E�ÊxQ�Ê J ]AÊ°à J G°á´GdÊ J XÔµERQ!]=ÊxQ!ãRU§\ M QFG5Q Ó^QFG·UlGZÊxà J J�� Y J�L UµX J \FÊyG6Q!\^] J�� Y J�L U J \^Î J E!É�Êxà J Q O Ê°à^E L G¼E�ÉÊ°à JÎ(UµÊ J ] Y^Q�Y J�L í�ä ÿ ÉËÊ J�L Ê°à^Q�Ê P Ì J ÎNQ�\AU§\RÊ J�L Y LxJ Ê+Ê°à J Y^Q�â Ð8K Ñ X)E´] J Ô»U§\AÊ J�L XZG8E�É Ï�J Ê L U\ J ÊyG¼Q�\^]=] J�L UµS J Êxà J Î(E LxLxJ G°Y[EF\^]´U§\ M Y J�L ÉÍE L X¼Q�\^Î J XZE´] J Ô�Ì�àIUlÎyà Ì�U§Ô§Ô�Ó J Y L E!Y J�L ÔµáQ�\^Q!Ôµá´G J ]¡äIå;àIUlG�Q�\[Q�Ô§áVG°UlG©UlG O G J ]6Ê°E J S�Q�Ô O Q�Ê J Êxà J G°áVG·Ê J X�ä
� �>Ú�ÛgL�VV°Þ·×\� Ø[Z\L�n1p\nFØAL�R Ü�nVÞ·×\�UTgP'�������
ß�\=Êxà J Y LxJ SVU§E O G¼G J Î(Ê°U§E!\ P Ì J à^QTS J�J#� Y^Ô§Q!Uµ\ J ]=Ê°à JAMFJ \ JNL Q!Ô©É J Q�Ê OIL°J G¼E�É�Ê°à J ÊxQ LxM!J ÊG·á´G·Ê J X�ä�D8E�Ì P Ì J ÉÍE´Î O G�E!\èXZE´] J Ô§Ô§Uµ\ M UµÊ O G°Uµ\ M Y^Q�â Ð8K Ñ \^E�ÊxQ�Ê°U§E!\-äO� J à^QTS J Î(E!\IâG·Ul] J�LxJ ] Ð+K Ñ Q�\[]è\IE�Ê�Êxà J \IE!ÊxQ�Ê°U§E!\èE�É;X J Ê°à^EV]IE!Ô§E M U J GG O Îyà QFGC5 K åçû �wþ P 5;5È´_û�ü�3Tþ�E L @ O G°U§E!\�û 4�þ�Ó J ÎNQ O G J E!É8UµÊxG)Ì�U§] J�L Q!ÎNÎ J YIÊxQ�\[Î J Uµ\ Ê°à J G°E�ÉËÊdÌ;Q LxJ5J \ M Uµ\ J�J�L U§\ MÎ(E!XZX O \IUµÊdá!äå;à J G°áVG·Ê J X ] J GxÎ L UµY´ÊxUµEF\¼Uµ\ Ð8K Ñ Q!Î�Î�E!XZYIÔ§U§G°à J G�Ì�U�Êxà6G·ÊxQ�ÊxU§Î+Q�\^]¼]IáR\[Q�XZU§Î�SRU J Ì�G
Uµ\�E L ] JNL ÊxE M U§S J Q)Î�E!XZYIÔ J Ê J ] J GxÎ L UµYIÊ°U§E!\ºE�É7Êxà J G°áVG·Ê J X�ä[@IE L Êxà J G°Q!ã J E�É�G·U§XZYIÔ§U§Î�U�ÊdáQ�\^] ÉÍE L Ê°à J Î(EF\VS J \^U J \^Î J E�ÉBE OIL Y L EFÓIÔ J X P Ì J E!\IÔ§á ] J GxÎ L U§Ó J Ê°à J ]´áV\^Q!X)UlÎ�SRU J Ì E�ÉÊ°à J G°á´GdÊ J X�ä
@»U M!O^L°J ü¼G·à^E�Ì�G�Ê°à J¼O G J Î�QFG J G\ J�J ] J ]pÊxE ] J GxÎ L UµÓ J Ê°à J ]´áV\^Q�XZUlÎ�Ó J à[QTSRU§E O^L E�ÉÊ°à J G°á´GdÊ J X�ä6� J ] J Q�Ô�Ì�UµÊ°àèÊxà L°JNJ ]´Uvu JNL°J \FÊ O G J ÎNQ!G J G P z°G°àIE�Ì G J�L SVU§Î J G |IP z°G°E�ÉËÊdÌ;Q LxJL°J Ê L U J STQ!ÔBG J�L SRUlÎ J�| Q�\^]jz J â�Î(E!XZX J�L Î J�| ä ÿ Ô§G°E P Ì J ÎNQ�\ G J�J Êxà J5O \IU�� OIJ QFÎ�Ê°E L Ì�àIUlÎyàUµ\RÊ JNL QFÎ�ÊyGBÌ�UµÊ°à³Ê°à J G°áVG·Ê J X P Êxà J z O G J�L+| äRå;à J+O G J Î�QFG J G©Q L°J ] J GxÎ L UµÓ J ]6Uµ\6Ê°à J ÉÍE!Ô§Ô§E�Ì;âUµ\ M ä�6� ÃVÂ@ÆwÀFÄ"�6���!ÀVÆk�»ÆwÀF�1�^ÆNÀ Å0ÀVÆ��!Ä����w ���Ã�¡£¢y Ï�L Uµ\[Î(U§Y^Q�Ô J S J \RÊ r E�Ì�Ç�Ê°à J)O G J Î�QFG J)M ERQ�Ô�UlG�Ê°EAG·à^E�Ì Ê°EºÊxà JZO G JNL Ê°à J QTS�Q�U§ÔlQ�ÓIÔ JG JNL SVUlÎ J G-Êxà^Q�Ê�Ê°à J G°á´GdÊ J X E1u JNL GNä�å;à J ÈVE�ÉËÊdÌ;Q LxJ ê J Ê L U J S�Q�ÔIÈ JNL SVUlÎ J U§G0E!\ J E!ÉIÊ°à^EFG JG JNL SVUlÎ J G:Q!\^]ºU�Ê�UlG�Q�ÔlG°EZ] J GxÎ L UµÓ J ]ºQ!G�Q O G J Î�QFG J ä
3
ElectronicUser
Commerce
RetrievalSoftware
Service
ServicesShow
¤Y¥v¦ ¦"§V¦ �:|�gQ$ q |�gy|
� Ã�¨> xÂC�´Ä�À Ä�À} �Ä���À}�[�[©;ÆwÀFÄ"�6���!À~�0ÆNÀF�q�IÆwÀ Å»ÀVÆ���Ä����w ��uê¡£¢y Ï�L Uµ\[Î(U§Y^Q�Ô J S J \RÊ r E�Ì�Ç/Êxà J�O G JNL+LxJ � OIJ GdÊyG8Êxà J G·á´G·Ê J XçÉÍE L Êxà J ] J G°U LxJ ]pG·E!ÉËÊdÌ:Q L°J äå;à J ì L E�Ì�G J�L�MFJ ÊxGBQ�ÎNQ�ÊyQ�Ô§E M Q�\^]�Êxà J X¼Q�ïdE L ]´EFX)E P ÿ ﵃ L°J ] P G°àIE�Ì�G�UµÊ�Ê°EÊ°à J�O G J�LwPÌ�àIE¼G J Ô J Î�ÊyG;Ê°à J G°E�ÉËÊdÌ;Q LxJ Gyæ�à J \ J�J ]^G�ä
y _ � Î J Y´Ê°U§E!\[Q�Ô J S J \RÊ r E�Ì�Ç�UµÉ[Êxà J�O G J�L UlG�\IE�ÊBGxQ�ÊxU§G� J ]�Ì�UµÊ°à)Ê°à J ÎNQ�ÊyQ�Ô§E M Y L°J G J \RÊ J ] PGyæ�à J ÎNQ�\¼Q!G°ãÉÍE L Q LxJ �^\ J X J \RÊNäRå;àIUlG�Y L E´Î J GxG�Î�E O Ôl]ZÓ J+L°J Y J Q�Ê J ]¼Q!G�XZQ!\VáÊxUµX J GQ!G;\ J Î J G°GxQ L á O \RÊ°U§Ô¡Ê°à J�O G JNL G J Ô J Î�ÊyG�Q)Î�E!\^Î L°J Ê J YIU J Î J E�É0G°E�ÉËÊdÌ;Q LxJ ä
«�©uÀ}�1 �Ä�Ã�¡'���/�Fê¬8¬ ÀFÄ��FÀG�0ÆwÀ~�1�IÆwÀ Å0ÀRÆ���Ä���' ���Ã�¡Y¢y Ï�L Uµ\[Î(U§Y^Q�Ô J S J \FÊ r E�Ì�ÇIÊ°à J�M EFQ!Ô¡U§G;ÊxE5Y L E�SVU§] J Êxà J�O G J�L Q!\ J â}Î�E!XZX J�L Î J Q!Î(Ê°U§SVU�ÊdáQ�\^]³Êxà J ]´E�Ì�\IÔ§EFQF]5E�ɻʰà J G°E�ÉËÊdÌ;Q LxJ G J Ô J Î�Ê J ]¡äÈVàIE�Ì G JNL SVUlÎ J G�Q!\^] J â�Î(EFXZX JNL Î JO G J Î�Q!G J G8Q LxJ E O Ê�E!É0Êxà J GxÎ(EFY J E!É�Ê°àIUlG8Q L ÊxU§Î�Ô JFP
Ê°à O G P Ì J Î�E!\^Î J \RÊ L Q�Ê J EF\³Êxà J ÈVE!ÉËÊdÌ:Q L°J ê J Ê L U J S�Q!Ô7È J�L SVU§Î J äÏ�L Q M X¼Q�Ê°UlÎ8EFÓ´ï J Î(Ê·â}E L U J \FÊ J ]³X J Ê°à^EV]IE!Ô§E M U J G8G O ÎyàAQFG�û 4 P � P ü�3Tþ�]´E¼\IE�Ê8] J Q�Ô7Ì�U�Êxà
Y JNL ÉÍE L X¼Q�\[Î J G°ãVUµÔ§ÔlG�ä�ÈVE P Ì J ÎNQ�\�G°QTá=Ê°à^Q�Ê�Ê°à JNL°J U§Gº\IE!Ê�Q!\�Q!ÎNÎ J Y´Ê J ] ð¼õ(ù�9Iñ�* ÊxEX)E´] J Ô©Q!\^] GdÊ O ]´áèG·á´G·Ê J X@Y J�L ÉÍE L XZQ!\^Î J U§\èÊ°à J E!ÓIï J Î�Ê°âjE L U J \RÊ J ]îG·E!ÉËÊdÌ:Q L°J ] J S J Ô§E!YIâX J \RʳY L E´Î J GxGNä:å;àIUlG³Ô§QFÎyã=U§XZYIÔµU J G6Ê°à[Q�ʺʰà JNL°J U§G³\IE�Ê�Q Ì J Ô§Ô�â�] J �^\ J ] ÔlQ�\ M!O Q M!J E Lø/ñ�ù�ö�ùjó�ñ�ø�ÊxE)Q!\I\IE!ÊxQ�Ê J G°á´GdÊ J X Ô§EFQF] P G°á´GdÊ J X ] J Ô§QTá´G:Q�\^] L E O Ê°U§\ M)L Q�Ê J G�ä[5+\5Êxà J Î(E!\IâÊ L Q L á P ÉÍE L X¼Q!ÔFG°Y J Î(Uv�[Î�Q�Ê°U§E!\�ÔlQ�\ MFO Q MFJ G P G O Îyà�Q!G Ñ 5�åg5ÈZûµü"�Nþ P E L»Ï�J Ê L U!\ J ÊxG:û�ü�?Tþ P à^QTS JÎ(E!\[G·Ul] J�LxJ ]ºQ�\[]ºG·Ê O ]´U J ]³Ê°à J Y L EFÓIÔ J X U§\�] J Y´Êxà-ä[å;à O G P Ê°à J�LxJ Q LxJ G J S J�L Q�Ô�Y L E!Y/EFGxQ�ÔlGÌ�à J�LxJ Ì J Î�Q!\�Ô J Q L \5É L E!X�äÿ G0Ì J;LxJ X¼Q L ã J ] P U�Ê�UlG»E OIL E!Ó´ï J Î�ÊxUµS J ÊxE+Y L E!Y/EFG J Q Ð+K ѺJ�� Ê J \^G·U§E!\ºéÍY^Q�â Ð+K Ñ í7ÊxE
] J Q!Ô[Ì�UµÊ°àºY JNL ÉÍE L X¼Q!\^Î J EF\5Êxà J G°E�ÉËÊdÌ;Q LxJ ] J S J ÔµEFYIX J \RÊ©Y L E´Î J G°G:Q�Ê©Ê°à J ] J G·U M \6G·ÊxQ M!J ä� J Î(EF\^G°U§] JNL Ê°à^Q�Ê;E OIL Y L E!Y/EFGxQ�Ô/X O G·Ê�Q!ÎNÎ(E!XZYIÔ§UlG·à³Ì�U�ÊxàºÓ/E�Êxà P Ê°à J X J Ê°àIE´]�Q�\^]6Ê°à J\IE�ÊyQ�Ê°U§E!\7ä1@0U L GdÊ P Êxà J X J ÊxàIE´]ZÌ�UµÔ§Ô M UµS J�O G�Êxà J Y L E´Î J GxG�ÊxE�X)E´] J ÔIÊxà J G°áVG·Ê J X Q!\^])Ê°à JL°J Ô J STQ!\RÊ»Y^Q L Q!X J Ê JNL G-Ê°E8Ó J ÊxQ�ã J \�U§\RÊ°EQ!ÎNÎ(E O \FÊwä�� J Q!]´SFEVÎNQ�Ê J ÉÍE L Q�Y^Q�Ê·Ê J�L \´âjE L U J \RÊ J ]Q�YIY L E � UµX¼Q�Ê°U§E!\-ä Ñ Q�Ê J Ô§á P ] J G·U M \³Y^Q�Ê°Ê JNL \^Gû �Tþ-à^QTS J8M Q!Uµ\ J ] LxJ Ô J S�Q!\^Î J Uµ\ºG·E!ÉËÊdÌ:Q L°J ] J âS J Ô§E!Y^X J \RÊ0] OIJ Ê°E8Ê°à J U L G·U§XZYIÔ§U§Î�U�Êdá�Q!\^] r^J#� U§ÓIU§ÔµUµÊdá!äTì O Ê0Ê°àIUlG7Ì�U§Ô§ÔFÓ J G O Ó´ï J Î�Ê0E�ÉIÉ O Ê OILxJL°J G J Q L Îyà-äIÈ J Î�E!\^] P Î�E!\^Î J�L \IU§\ M Êxà J \IE!ÊxQ�ÊxUµEF\ P UµÊ�Ì�UµÔ§Ô-Ó J Ê LxJ Q�Ê J ]ºU§\6ÊxàIU§G�Ì©E L ã�äß�\)E L ] J�L Ê°E�à^QTS J Q�Î�E!XZYIÔ J Ê J Y JNL ÉÍE L X¼Q�\[Î J \IE�ÊyQ�ÊxUµEF\ P Ê°à J+Ð8K Ñ Ó J à^QTSVU§E OIL Q�Ô´Q!\^]
GdÊ L°O Î(Ê OIL Q�Ô¡XZE´] J Ô§G8X O G·Ê�Ó J Î(E!\[G·Ul] J�LxJ ]-ä ÿ ÔlG·E P Y JNL ÉÍE L X¼Q!\^Î J Ì�U§ÔµÔ»YIÔ§QTáºQ)Y L EFXZUµ\ J \RÊL EFÔ J U§\ Êxà J UµXZYIÔ J X J \RÊyQ�Ê°U§E!\=]´U§Q M!L Q�X¼GNä7ß�\ ÊxàIUlGY^Q!Y JNLNP Ì J Q LxJ U§\RÊ JNL°J GdÊ J ] EF\IÔµáèU§\Ó J à^QTSVUµE OIL Q!ÔIQ!G°Y J Î�ÊyG P Î�E!\^Î L°J Ê J Ôµá�Uµ\)Ê°à J G J � OIJ \^Î J ]´UlQ M!L Q�X Q�\^])Êxà J GdÊyQ�Ê J Ê L Q�\^G°UµÊ°U§E!\]´U§Q M!L Q�X¼GNä1@ O Ê OILxJ Ì:E L ã´G�Ì�UµÔ§Ô�] J Q!Ô[Ì�UµÊ°à¼Êxà J8LxJ G·Ê©E!É¡Ê°à J�Ð8K Ñ ]´UlQ M!L Q�X¼G�Ê°E] J G°Î L U§Ó JÓ J à^QTSVUµE OIL é O G J Î�QFG J ]IU§Q M!L Q�X¼G P QFÎ�Ê°U§SVU�Êdá)]´UlQ M!L Q�X¼G P Î(EFÔµÔlQ�Ó/E L Q�ÊxUµEF\�]´UlQ MFL Q!XZGyí P G·Ê LxO Î(âÊ OIL Q�Ô-QFG·Y J Î(ÊxG P Q�\^]ºU§X)Y^Ô J X J \RÊxQ�ÊxUµEF\A]´U§Q M!L Q�X¼GNä
4
å;à JºÐ+K Ñ \IE�ÊyQ�ÊxUµEF\ Ê°E ] J Q�Ô;Ì�UµÊ°à Ê°U§X J UlG)Ó^Q!G J ]=E!\ Ê°à J�O G J E�É8ÊxUµX J�LxJ G·Ê L U§Î(âÊ°U§E!\^GNä�å;àIUlG LxJ G·Ê L UlÎ�Ê°U§E!\[GîQ L°J J�� Y LxJ GxG J ] QFGÒÊxUµX J É O \[Î�Ê°U§E!\[GèE!\ X J G°GxQ MFJ \^Q!X J G PJ ä M ä Pg® éÍX J GxG°Q M!J 5+\ J ä L°J Î J UµS J å;U§X J âZX J GxG°Q M!J 5+\ J ä G J \^]Iå;U§X J í°¯>üpG J Î!ä²±Rä£� J Î(E!\IâG·Ul] J�L XZE LxJ�L°J Q�Ô§U§G·Ê°UlÎ;ÊxE�Q�\^\IE�ÊyQ�Ê J Ê°à J X J G°GxQ MFJ G·U�� J äFß�\5Ê°àIUlGBÌ;QTá P Ì J Î(E O Ô§]5ÎNQ�ÔlÎ O ÔlQ�Ê JY JNL ÉÍE L X¼Q�\[Î J ÉÍE L ]´Uvu J�LxJ \RÊ�\ J Ê8G°Y JNJ ]IGNä
³ ¢�´ � ÀIµO�»ÀI¡w�!À Åw��[¶[Ä��[¬ Æß�\6E L ] JNL Ê°E O \^] JNL G·ÊxQ!\^]ZÊxà J Y L E!Ó^Ô J X P UµÊ:UlGBU§\RÊ JNL°J GdÊxUµ\ M Q�XZE LxJ ] J ÊxQ!UµÔ J ]³] J GxÎ L UµYIÊ°U§E!\E�É^Êxà J ÈVE!ÉËÊdÌ:Q L°J ê J Ê L U J S�Q�Ô^È J�L SRUlÎ J;O G J Î�QFG J äTå;à O G P Q�ú�õ�·#0^õ�ø��yõg*�ó�ö�÷1�°ö�ðçû 2�þIà^Q!G�Ó J�J \] J S J Ô§E!Y J ]6Ê°EZÊ LxJ Q�Ê�Q!Î�Î OIL Q�Ê J ÔµáZÊxà J X J \RÊ°U§E!\ J ] O G J ÎNQ!G J!P G J�J � MFOIL°J 2Iä
{1K}
{100K}{100K}
{100K}
{1K}
{0.9}
{1K}
{1K}{1K}
{1K}
{1K}
{1K}
{1K}
{1K..100K}
refine_catalog(refinement_plus)
select_sw_service(info)
c1:Catalogcreate_catalog(info_plus)
observe_GUI_catalog(c1)
select_sw(name)
[info_need] more_information(refinement2, ci)
{1K}
{prob} {1K..100K}[satisfied]
create_salesman(info_sale)
[not satisfied]
1..n show_catalog_GUI(c1)
create_browser(c1)
get_catalog(info_plus)
refine_catalog(refinement)
electronic_commerce
info_sale_plus
request(info_sale)
delete_browser
select_sw(name)
c i+1
Salesman
BrowserAgent
SwManagerAlfred
¤`¥�¦ ¦�¸^¦ {!g�±�«FgyiRsyg;fFr q v�m q n klc�mBbd®Fg8{!c�k§bj¨ q mdg � gxb�mdrtgy� q ª[{!gxmd��rtsyg�«R|�g�s q |�g
ÿ G J � O^J \^Î J ]´U§Q M!L Q�X LxJ Y L°J G J \FÊyG�X J GxG°Q M!J G�G J \RÊBQ�XZEF\ M E!Ó´ï J Î�ÊyG�ä Ð G O Q!ÔµÔ§á P Q�X J GdâG°Q M!J U§G�Î�E!\^G°Ul] J�LxJ ]îQ!G�\^E³ÊxUµX J Î�E!\^G O XZU§\ M Uµ\îÊ°à J G°Î�E!Y J E�É:Ê°à J XZE´] J Ô§Ô J ]èG·á´G·Ê J Xºäì O Ê�Uµ\AQ)XZE!ÓIU§Ô J Q M!J \FÊ�G°á´GdÊ J X P Ì J ]´UlG·Ê°U§\ M!O UlG°àºÓ J ÊdÌ J�J \�X J G°GxQ MFJ G;G J \RÊ�ÓRá6E!Ó´ï J Î�ÊxGE!\ZÊ°à J GxQ�X J Î�E!XZY O Ê J�L Q!\^]ZX J GxG°Q M!J G�G J \RÊ:Q�XZEF\ M E!Ó´ï J Î�ÊyG�E!\³]´U²u J�LxJ \RÊ;Î(E!XZY O Ê J�L G PÊ°àIERG J Ì�àIUlÎyàîÊ L QTS J Ô�Ê°à L E OIM àÒÊxà J \ J ÊNä»å;à J � L G·Ê�ãVUµ\[]pE!É:X J G°GxQ MFJ GÌ�U§ÔµÔ�Ó J Î�E!\^G°U§]´âJ�LxJ ] Q!G\IE�âjÊ°U§X J Î�E!\^G O XZUµ\ M ä»å;à J G J Î(EF\^]èãVUµ\^] Ì�UµÔ§Ô:Î�E!\^G O X J ÊxUµX J QFGQ�É O \^Î�ÊxUµEF\E�É;Ê°à J X J G°GxQ MFJ G·U�� J Q�\^]îÊxà J \ J Ê�Y J�L ÉÍE L XZQ!\^Î J éuG·Y J�J ]^í�ä ��JNL°J Q!\ Q�\I\^E�ÊxQ�Ê°U§E!\ P Uµ\´âG·Ul] J Ó L QFÎ J G P Ì�U§Ô§Ô©Ó J X¼QF] J U§\^]´UlÎ�Q�Ê°U§\ M Êxà J X J GxGxQ M!J G·U�� J äw@^E L U§\^G·ÊxQ!\^Î JFP U§\�@0U M!OILxJ
5
2 P6¹»º ¼ º�½�¾ ¹W¿ ¹»º À�Á  ½#º X J GxG°Q M!J UlG�ÔlQ�Ó J Ô§Ô J ]èÌ�U�Êxà ®qÃFÄYÅ�Æ�¾Wº ± P Ì�à^UµÔ J�¹�Ç"È"¿ ½#É�¾É}¼ ÈqÊ Ë£ÌYÍL°J � O U LxJ G8Ê°à J XZE�S J X J \RÊ+E�É ®qÃ�Î1ÎFÄYÅ�Æ�¾Wº#¹ ±Rä ÿ Ô§G°E P UµÊ�Ì�U§Ô§Ô0Ó J Y[ERG°G°U§ÓIÔ J Ê°E�Q�\I\^E�ÊxQ�Ê J QL Q!\ M!J ÉÍE L Êxà J G°Uv� J Uµ\îÊxà J6Ð8KÒÑ Î(E!XZXZE!\èÌ;QTá P Ô§Uµã J Uµ\ÐÏ ÈIÀ�º ²Ñ�Ò�ÈIÀ Ï É�¾� È[Ñ X J GxG°Q M!JFPÌ�à J�LxJ Q ®}ÃqÄ�ÓvÓvÃ�ÎqÎÔÄ ±8ÔlQ�Ó J Ô7Q!YIY J Q L G�äß�\³Q)G J � O^J \^Î J ]´UlQ MFL Q!X P Î(EF\^]´UµÊ°U§E!\^G LxJ Y LxJ G J \RÊ©Ê°à J Y[ERG°G°U§ÓIUµÔ§UµÊdáZÊ°à^Q�Ê:Êxà J X J G°GxQ MFJ
Ê°à^Q�Ê©Êxà J á¼à^QTS J QFG°G°E´Î(UlQ�Ê J ]ZÌ�U�Êxà³Î�E O Ôl]5Ó J G J \RÊwä ÿ \³Q!\I\IE�ÊyQ�ÊxUµEF\ P Q!Ô§G°E�U§\^G°U§] J Ó L Q!Î J G PJ�� Y LxJ GxG·U§\ M Ê°à JJ S J \RÊ�Y L EFÓ^Q�Ó^UµÔ§U�Êdá³G O ÎNÎ J G°G�Ì�U§Ô§Ô-Ó J Q!GxG·E´Î(UlQ�Ê J ]6Ê°E J Q!Îyà�Î(EF\^]´UµÊ°U§E!\-ä ÿL Q!\ M!J UlG»QFÎ�Î J Y´Ê J ]ÊxERE[äwÈ JNJ!P ÉÍE L Uµ\^G·ÊxQ!\^Î JFP Êxà J Y L EFÓ^Q�ÓIU§Ô§U�Êdá ®�ÎªÓ Õ ±BQ!GxG·E´Î�U§Q�Ê J ]U§\Ö@0U M!OILxJ2�Ê°EZÊ°à J Î(EF\^]´UµÊ°U§E!\ Ñ"È ¾ ¹»É�¾� ¹×[º�Ø ä^ÈVE!X J ÊxUµX J G P U�Ê8UlG�Y/EFGxG·U§ÓIÔ J Ê°à^Q�Ê�Ê°à J Y L E!Ó^Q!ÓIUµÔ§UµÊdá5U§GO \IãV\IE�Ì�\�Ì�à J \XZE´] J Ô§Ô§Uµ\ M ä ÿ Ô§G°E P UµÊ�Î�E O Ôl]�Ó J Êxà^Q�Ê0Ê°à J Y L E!Ó^Q!ÓIU§ÔµUµÊdá�Q8X J GxG°Q M!J E´Î�Î OIL GU§G�Q)Y^Q L Q!X J Ê JNL G O Ó´ï J Î(Ê�Ê°E5G·Ê O ]´áFäIß�\�E OIL8J�� Q�XZYIÔ J!P Êxà J Î(EF\^]´UµÊ°U§E!\ ²Ñ�Ò�È Ñ�º�º�Ø QFG°G°E´Î(UµâQ�Ê J ]�Ê°EÊ°à J Ï ÈIÀ�º ²Ñ�Ò�ÈIÀ Ï É�¾� ÈÔÑ X J G°GxQ MFJ UlG�Î L UµÊ°UlÎ�Q!Ô´ÉÍE L Êxà J G°áVG·Ê J X P Ó J Î�Q O G J UµÊ LxJ S J Q�ÔlGàIE�̶X O Îyà³Uµ\RÊ J Ô§ÔµU M!J \FÊ:Ê°à J ì L E�Ì�G JNL UlG#Ù´G°E P Ì J Ì:Q!\RÊ©ÊxE)G·Ê O ]Iá¼U�ÊwäRß�\�G O Îyà6G°U�Ê O Q�ÊxUµEF\^G PÌ J Ì�U§ÔµÔ7Q!\I\IE!ÊxQ�Ê J Q�\ºU§] J \RÊ°Uv� J�LwP Î(E L°LxJ G°Y/E!\^]´U§\ M Ê°EZÊ°à J�O \IãV\IE�Ì�\ºY L EFÓ^Q�Ó^UµÔ§U�ÊdáFä
³ ¢:Ú � ��A wÀFÛ©Ä"�Ô¡»Æ��� ���Ã�¡ Åw��Ô¶^Ä��[¬ ÆÈ J � OIJ \^Î J ]´UlQ M!L Q�X¼G0G·à^E�Ì àIE�Ì EFÓ´ï J Î(ÊxG0Uµ\RÊ J�L Q!Î�Ê P Ó O Ê�Ê°E+ÊxQ!ã J Q+Î�E!XZYIÔ J Ê J SVU J Ì E!É^Ê°à JG·á´G·Ê J X ]´áV\^Q�XZUlÎ�G P U�Ê©U§G�Q!Ô§G°EUµ\RÊ J�LxJ G·Ê°U§\ M Ê°E O \^] J�L GdÊyQ�\^]�Ê°à J ÔµUµÉ J E�É�E!ÓIï J Î�ÊyG�ä�ß�\ Ð+K Ñ�PÊ°à J ú�ù}ö�ù}õù>�°ö�øIú�óËùuó�ñ�ø ]´UlQ M!L Q�X UlGBÊxà J Ê°EVE!Ô/Ê°à[Q�Ê�] J GxÎ L UµÓ J GBÊ°à^U§G;Q!G°Y J Î�Ê;E�É7Ê°à J G·á´G·Ê J Xºä@IE L:J QFÎyà5Î(ÔlQ!GxGBÌ�UµÊ°à L°J Ô J S�Q�\RÊ:]´áV\^Q!XZU§Î8Ó J à^QTSVUµE OIL Q�GdÊyQ�Ê J Ê L Q�\^G°UµÊ°U§E!\6]´UlQ MFL Q!X X O G·ÊÓ J G°Y J Î(Uv� J ]-äß�\ Q5GdÊyQ�Ê J Ê L Q�\^G°UµÊ°U§E!\A]´UlQ M!L Q�X ÊdÌ©E J Ô J X J \RÊxG+Ì�UµÔ§Ô7Ó J Î�E!\^G°Ul] J�LxJ ] P Ê°à J öq�(ùjó:ÜwóËùuó�õ(ú
Q�\^] Ê°à J ÷10^ö���*Tú�ä ÿ Î(Ê°U§SVU�ÊxU J G L°J Y LxJ G J \RÊ�ÊyQ!G°ã´G�Y J�L ÉÍE L X J ]=ÓVá Q�\ E!Ó´ï J Î�ʼU§\ Q M UµS J \GdÊyQ�Ê J ä�È O Îyà Q!Î�ÊxUµSVUµÊ°U J GZÎ(EF\^G O X J Î�E!XZY O ÊyQ�Ê°U§E!\ Ê°U§X J Êxà^Q�ʼX O GdÊ¼Ó J X J Q!G OILxJ ] Q!\^]Q�\I\IE!ÊxQ�Ê J ]-äBå;à J Q�\^\IE�ÊyQ�Ê°U§E!\ Ì�U§ÔµÔ8Ó J U§\^G°U§] J Ó L QFÎ J G¼G·àIE�Ì�U§\ M Ê°à J Ê°U§X J \ J�J ] J ]=ÊxEY JNL ÉÍE L X UµÊNä»ß}É:UµÊ�UlG�\ J Î J GxG°Q L á P Q³XZU§\IU§X O X Q�\^]îQ�X¼Q � U§X O X S�Q!Ô OIJ G�Î(E O Ôl]ÒÓ J Q�\Iâ\IE�ÊyQ�Ê J ]¡ä-È J�JFP ÉÍE L+J#� Q�XZYIÔ J!P Ó[EFÔ§]ÒÔ§Q!Ó J Ô§G�Ó J ÊdÌ J�J \ÒÓ L QFÎ J G8U§\�@0U MFOILxJ G�H P ý P 46Q!\^]{�VäB O Q L ]IGBG°àIE�̶Î(EF\^]´UµÊ°U§E!\^G©U§\6QÊ L Q�\[G·UµÊ°U§E!\¼Êxà^Q�Ê:X O G·Ê©à^E!Ôl]¼Uµ\6E L ] J�L ÊxE�� LxJ Êxà J Î�E LxL°J âG·Y/E!\^]IUµ\ MZJ S J \RÊwä ÿ Y L EFÓ^Q�Ó^UµÔ§U�Êdá¼X O G·Ê�Ó J Q!GxG°EVÎ�U§Q�Ê J ]¼Ê°EZÊxà J X�äIß}Ê�Ì�U§ÔµÔ7Ó J Q!\I\IE�ÊyQ�Ê J ]Uµ\ Ê°à J G°Q!X J Ì;QTáèQFG MFO Q L ]IGÌ JNL°J Q�\I\IE!ÊxQ�Ê J ] Uµ\ Ê°à J G J � OIJ \^Î J ]´UlQ MFL Q!X P Q�\[] Ê°à JG°Q!X J Î�E!\^G°U§] J�L Q�Ê°U§E!\[G+X O G·Ê�Ó J ÊyQ�ã J \pU§\RÊ°E QFÎ�Î(E O \RÊNä7È JNJ!P ÉÍE L Uµ\[GdÊyQ�\^Î J!P ÔlQ�Ó J Ô ®"ÎÔÓ Õ ±ïdE!U§\ J ]³Ê°E¼Î�E!\^]´UµÊ°U§E!\7Ý Ñ"È ¾=Þ�ß"¹º1ÀàÓ ¹»É�¾� ¹×[º�Ø1á Uµ\~@0U MFOILxJ H[äKAJ GxG°Q M!J G·U�� J X¼QTá¼Ó J EFX)UµÊ·Ê J ]�G°Uµ\^Î J Ê°àIUlG;Uµ\IÉÍE L XZQ�Ê°U§E!\ºQ�YIY J Q L G:U§\6Êxà J G J � OIJ \^Î J
]´U§Q M!L Q�X�ä�ß�\Ê°à J:J�� Q!X)Y^Ô JFP Ì J à[QTS J ] O YIÔµUlÎ�Q�Ê J ]�Ê°à^U§G0U§\´ÉÍE L X¼Q�Ê°U§E!\Ê°E M Q�U§\ LxJ QF]IQ�ÓIU§Ô§U�ÊdáFä� J \IE�Ì Y LxJ G J \RÊ�Ê°à J G·ÊxQ�Ê J Ê L Q�\^G°U�ÊxUµEF\p]´UlQ MFL Q!X¼G�ÉÍE L E OIL G·á´G·Ê J X O G·U§\ M Ê°à J Y^Q�â
Ð8K Ñ \IE!ÊxQ�Ê°U§E!\-ä
â³ÆwÀRÄ6Æ# ��A NÀF �Ä��[¡0Æ�� ���Ã�¡ Å'���[¶[Ä"�Ô¬E¢8ß�\m@»U M!O^L°J ? P Ê°à J Ó J à^QTSVUµE OIL E!ÉBQ O G JNL UlG LxJ YIâL°J G J \RÊ J ]-äVå;à J+O G J�L UlG©U§\³Ê°à J�¿YÉ1 ¾ G·ÊxQ�Ê J+O \FÊxUµÔ¡G�æTà J Q!Î(Ê°U§S�Q�Ê J G;Q ¹º1¼ º�½�¾ ¹¿ ¹»º À�Á  ½#ºJ S J \RÊNä�å;àIU§G J S J \RÊÒG J ÊxG Ê°à J O G JNL U§\ Ê°à Jã¿YÉ1 ¾�²Ñ"Ê Ò�ÈIÀ ½#É�¾É}¼ È1Ê GdÊyQ�Ê J ä+å;à JäÈ[Å�幺1ÀvÁ"º Ë£Ì£Í ½�É�¾É}¼ È1ʼJ S J \RÊ P G J \RÊ�ÓVá ÿ Ô�É LxJ ] P Q�Ô§ÔµE�Ì�G:Êxà J�O G J�L Ê°E J#� Q!XZUµ\ J Êxà J ÎNQ�Ê°âQ�Ô§E M Ê°E¼Ô§EVE!ã¼ÉÍE L Ê°à J ] J G°U L°J ]³G°E�ÉËÊdÌ;Q LxJ!P UµÉ0UµÊ8UlG�U§\³Êxà J ÎNQ�ÊxQ!ÔµE M^P Êxà J�O G J�L G�G J Ô J Î�ÊxGÊ°à J;¹»º ¼ º�½æ¾ ¹W¿ J S J \FÊ P Uµ\�E!Ê°à JNL Î�Q!G J Gyæ�à J G J Ô J Î�ÊxG�Ê°à JkÀ�º�×OÑ"º ½#É�¾É}¼ ÈqÊZJ S J \RÊNä
ç ©¨jÄ�ÀVŶÆ# ��A NÀF �Ä��[¡0Æ�� ���Ã�¡ Å'���[¶[Ä"�Ô¬E¢+å;à JAJ#� Q�XZYIÔ J G O YIY/EFG J G)Êxà^Q�Ê ÿ Ô�É LxJ ]=U§G6Q�ÔµâÌ:QTá´G+Y LxJ G J \RÊ�U§\pÊ°à J G°áVG·Ê J X P \^EºÎ L°J Q�Ê°U§E!\ J S J \RÊ�UlG L°J Ô J S�Q�\RÊ+ÉÍE L E OIL Y OIL Y/EFG J GNäÈVEèÊ°à J GdÊyQ�Ê J Ê L Q�\^G°U�ÊxUµEF\ ]IU§Q M!L Q�X Ó J�M Uµ\^G5Ì�à J \¶Q Á1 º�¿ ¹»º À�Á  ½#º#¹¼J S J \RÊ5UlG5G J \RÊ
6
[not satisfied]^Alfred.refine_catalog(refinement)
^Alfred.select_sw(name){1K}
WAIT
{1K}
Do:observe
observe_GUI_catalog(c1){100K}
{0.9}
^Alfred.select_sw_service(info)
catalogWaiting for
{1K}
¤Y¥v¦ ¦#è^¦ {�b q bdg:b�m q iF|�r�bdr�cNi5fFr q v�m q n k§cNmBbd®Rg;«F|�gxm
Ê°EÒÊ°à J³O G JNL ä ÿ ﵃ LxJ ]Oé GÓ J à[QTSRU§E O^L U§GÊdáVYIUlÎ�Q�ÔBÉÍE L Q G J�L S J�L E!Ó´ï J Î�Ê�Ó J à[QTSRU§E O^L ä»ß}ÊÌ:Q!U�ÊyG+ÉÍE L Q�\ J S J \RÊ LxJ � OIJ GdÊxUµ\ M Q�G J�L SRUlÎ J é ¹»º ¼ º�½æ¾ ¹W¿ ¹»º À�Á  ½#º!PO¹#Ç�È"¿ ½�É�¾É}¼ È1Ê Ë£Ì£ÍµPÀ�º#×OÑ�º ½#É�¾É}¼ ÈqÊ E L=¹»º ¼ º�½�¾ ¹W¿ í�äA@IE L©J Q!Îyà5E!É-Ê°à J G J�LxJ � OIJ G·ÊxG:UµÊ:Y J�L ÉÍE L X¼G©Q)Î(EF\^Î LxJ Ê JQ!Î(Ê°U§E!\ P Q�\^]ZÌ�à J \6UµÊ©UlG:Î(E!XZYIÔ J Ê J ] P Q�X J GxGxQ M!J U§G:G J \RÊ�Ê°EÊ°à J Î(E L°LxJ G°Y[EF\^]´U§\ M E!ÓIâï J Î(Ê�Uµ\�E L ] JNL ÊxE5Î(EFX)Y^Ô J Ê J Ê°à J ÊyQ!G°ã�ä ÿ ÉËÊ JNL Ê°à J X J G°GxQ MFJ UlG�G J \RÊ P ÿ Ô�É LxJ ] LxJ Ê OIL \[GÊ°E�UµÊxG�Ì:Q!U�ÊBG·ÊxQ�Ê J ÊxE�G JNL S J Q!\IE�Êxà J�LBL°J � O^J G·ÊNä1@0U M!OILxJ H�G·à^E�Ì�G ÿ ﵃ L°J ]Oé G�Ó J à^QTSVUµE OIL äå;à J G·Ê JNL°J E�ÊdáVY J ]³Ê L Q�\^G°U�ÊxUµEF\�êìë°í"î�ï ð�ï�î"ñqò%ó�ï�ð;ô X J Q!\^G�Êxà^Q�Ê ÿ ﵃ L°J ]�XZQTá³Q�Ê·âÊ J \^]ºE�Ê°à J�L G J�L SRUlÎ J G:Ê°à^Q�Ê�Q LxJ \^E�Ê�E�É0Uµ\RÊ J�LxJ G·Ê;à J�LxJ ä
{0.9}
show_catalog_GUI(ci)
[not ^user.satisfied]refine_catalog(refinement)
^browser.refine_catalog(refinement_plus)
{0.1}
{1K}
{100K}
{1K}
{1K}
^browser.select_sw(name)
Do:create_GUI(c)^user.observe_GUI_catalog(ci)
Do:add_info3 Do:add_info2
Do:add_info1
[^user.satisfied]select_sw(name)
<<more_services>>WAIT
select_sw_service(info) ^SwManager.get_catalog(info_plus)
{1K}
{1sg}
{1K}
{100K}
{1K}
{1sg}
{1sg}
{1sg}
¤Y¥v¦ ¦æõ/¦ {�b q bdg:b�m q iF|�r�bdr�cNi5fFr q v�m q n klc�m£�©ª�k§mdg�f
� Ã�¨> xÂC�´Ä�À�ö÷�[¡w�[¶/ÀRÄ6Æ# ��A NÀF �Ä��[¡0Æ�� ���Ã�¡ Å'���[¶[Ä"�Ô¬E¢ Ñ Uµã J ÿ Ô�É LxJ ] P Êxà J ÈVE�ÉËÊdÌ;Q LxJK Q�\[Q M!JNL Ó J à^QTS J GpQ!GÒQ!\ G J�L S J�L E!Ó´ï J Î�Êwä+ß}ÊèU§GpÌ;Q�UµÊ°U§\ M ÉÍE L Q LxJ � OIJ GdÊ J S J \RÊé%Ï ÈIÀ�º ²Ñ�Ò�ÈIÀ Ï É�¾� È[ÑVPªÊqº�¾ ½#É�¾É}¼ ÈqÊ^P'À�º�ø[ß"º#¹¾ í8Ê°E J \^Q!ÓIÔ J Ê°à J QFÎ�ÊxUµEF\^G+Ê°E�Q!Î�Î�E!XZYIÔ§U§G°àÊ°à J ÊxQ!G°ã�ä1@0U MFOILxJ ý�G·à^E�Ì�G�U�ÊyGBG·ÊxQ�Ê J Ê L Q�\[G·UµÊ°U§E!\¼]´UlQ MFL Q!XGÙ�UµÊBUlG�U§\RÊ J�LxJ G·Ê°U§\ M ÊxE�\IE�Ê JÊ°à J QFÎ�Ê°U§E!\[GBY J�L ÉÍE L X J ]ZÊxE LxJ G°Y[EF\^]¼Êxà JtÊ1º�¾ ½�É�¾É}¼ È1Ê)L°J � O^J G·ÊNäI@»U L GdÊ P Q!\6EF\FÊxE!Ô§E M áU§G:Î(EF\^G O Ô�Ê J ]¼Q!\^] P Q�ÉËÊ JNL Êxà^Q�Ê P ÊdÌ:E]´Uvu JNL°J \RÊ©E!ÓIï J Î�ÊyGBQ L°J Î L°J Q�Ê J ] P Ê°àIERG J U§\VS!EFÔµS J ]Uµ\ºÊyQ!G°ã5X¼Q�\^Q M!J X J \FÊwäùÄ�ÃV¼ÆNÀRÄ6Æ� ��[ NÀ~ NÄ"�Ô¡»Æ��� ���Ã�¡ Åw��Ô¶^Ä��[¬E¢�å;à J G·ÊxQ�Ê J Ê L Q�\^G°U�ÊxUµEF\p]´UlQ MFL Q!X Uµ\ã@0U M!OILxJ4�] J GxÎ L UµÓ J G©Ê°à J ì L E�Ì�G JNL é G©ÔµUµÉ J ä´ß}Ê�UlG:QFG©ÉÍE!Ô§ÔµE�Ì�GNÇVE!\^Î J Êxà J ì L E�Ì�G J�L UlG�Î LxJ Q�Ê J ]5UµÊ
7
WAIT
request(info_sale)
Do:add_info4
^salesman.reply(info_sale_plus)
^browser.reply(catalog){100K}
{0.5sg..50sg}
{1K}
{1sg}
get_catalog(info_plus)
[info_need] more_information(refinement2,ci){1K..100K}{prob}
Do:get_info
{1K}
Do: create_catalog
Do: create_browser
^browser.create_browser(ci) {1K}
^catalog.create_catalog(info_plus)
{1sg}
{1 min}{1K}
{1K}
¤Y¥v¦ ¦�ú^¦ {�b q bdg;b�m q iF|�rtbdrtcNi¼fFr q v�m q n klc�m�bd®Rg8{!c�k§bu¨ q mdggû q i q vwgxm
X O G·Ê M E;Ê°E�Êxà Jgü/Ì ý�¼ É�½#º!P Ì�à J�LxJ U�Ê»Uµ\VS!EFã J G ÿ ﵃ L°J ]Oé G ¹�Ç"È"¿£¹ ½�É�¾É}¼ È1Ê Ë£Ì£Í X J ÊxàIE´]Ê°E¼SVUlG O Q!ÔµU�� J Êxà J Y LxJ SVUµE O G°Ôµá¼EFÓ´ÊxQ!Uµ\ J ]�Î�Q�ÊyQ�Ô§E M ä ÿ Ê�ÊxàIUlG�GdÊyQ�Ê J UµÊ8Î�Q!\AQ�Ê·Ê J \^]³ÊdÌ:E]´Uvu JNL°J \FÊ J S J \RÊxG PªÀ�º#×OÑ�º ½#É�¾É}¼ È1Ê E L�¹º1¼ º�½æ¾ ¹¿ äVß}É-Ê°à J � L G·Ê J S J \RÊ:EVÎNÎ OIL GBÊ°à JNL°J Q LxJÊdÌ©E³]´U²u J�LxJ \RÊ�Y[ERG°G°UµÓ^UµÔ§U�ÊxU J G�ÇÔ� L GdÊ P UµÉ�Ê°à J ì L E�Ì�G J�L à^QFG�Êxà J \ J Î J G°GxQ L á6ãV\IE�Ì�Ô J ] MFJÊ°E G°E!Ô§S J Êxà J ÊyQ!G°ã P Q L°J �^\ J X J \RʳQ!Î(Ê°U§E!\¶UlG5]´U L°J Î�Ê°Ô§á Y JNL ÉÍE L X J ]6Ù©G J Î(EF\^] P UµÉ�UµÊÎ OILxLxJ \RÊ°Ô§á=à[Q!G5\^E�Ê5ÊxàIU§G³Ó^QFÎyã MFL E O \^] P Ê°à J ì L E�Ì�G J�L X O GdÊ6EFÓ´ÊxQ!Uµ\ Uµ\´ÉÍE L X¼Q�Ê°U§E!\É L EFX Êxà J ÈVE!ÉËÊdÌ:Q L°JAK Q!\^Q MFJ�LwP ÓRá G J \^]´U§\ M QÐÏ ÈIÀ�º ²Ñ�Ò�ÈIÀ Ï É�¾� È[Ñ LxJ � OIJ G·Ê5E L ÓVáÊ L QTS J ÔµÔ§Uµ\ M ÊxEAÊ°à J G·E!ÉËÊdÌ:Q L°J YIÔlQ!Î J ä»ß}É:Êxà J-¹»º ¼ º�½�¾ ¹W¿ J S J \FÊ�E´ÎNÎ OIL G P Ê°à J ì L E�Ì�G JNLX O G·Ê8Î LxJ Q�Ê J Q¼È´Q�Ô J G°X¼Q�\ºUµ\[GdÊyQ�\^Î J Q!\^]º]´U J ä
^alfred.show_catalog_GUI(ci)
Do:goto_Sw_place
Do:goto_MU_Place
create_browser(c)
delete_browser
Do:goto_MU_Place
{1K}
{1K}{100K} {100K}
{1K}
{100K}
{1K..100K}
{100K..200K}
^salesman.create_salesman(info_sale)
^SwManager.more_in-formation(refinement2, ci)
[not info_need]
[info_need_travel]
select_sw(name)
refine_catalog(refinement_plus)
{1K..100K}
WAIT
[not info_need or info_need_local][info_need_travel]
[info_need_local]
Do: refine
^alfred.show_catalog_GUI(ci+1){100K}
{1sg}
reply
¤`¥�¦ ¦#þI¦ {�b q bdg:b�m q iR|�r�bdrtcwi5f!r q vNm q n k§cNm�bd®Rg=ÿ»mdc�¨�|�gxm
� �[©uÀVÆ�¬8�Ô¡ � ��A wÀ�Û©Ä��[¡»Æ��� ���Ã�¡��/���[¶^Ä��[¬�¢+å;à J È´Q!Ô J G·X¼Q�\�é G M ERQ�ÔºU§G ÊxE M UµS J J âÎ(EFX)X JNL Î J G J�L SVU§Î J G P QFG³Ì J Î�Q�\�G JNJ U§\�@»U M!O^L°J �Vä ÿ ÉËÊ J�L UµÊxGAÎ LxJ Q�Ê°U§E!\½UµÊ Q!G°ã´GÊ°à J ÈVE�ÉËÊdÌ;Q LxJ K Q!\^Q MFJ�L ÉÍE L GxQ�Ô J Uµ\IÉÍE L XZQ�Ê°U§E!\-ä£�¶U�Êxà¶Ê°à^U§G³Uµ\IÉÍE L XZQ�Ê°U§E!\ Ê°à JÒJ âÎ(EFX)X JNL Î J ÎNQ�\�GdÊyQ L ÊNä´å;àIUlG;U§G;QZÎ(EFX)Y^Ô J#� ÊxQ!G°ã¼Êxà^Q�Ê�X O GdÊ�Ó J ] J GxÎ L UµÓ J ]6Ì�U�ÊxàºUµÊxGE�Ì�\ O G J ÎNQ!G J Q!\^]�G J � O^J \^Î J ]IU§Q M!L Q�X Ì�àIUlÎyà³UlG�E O Ê�E�ɻʰà J GxÎ(EFY J E�É0Ê°à^U§G�Y[Q�Y J�L äå;à J Y^Q�â Ð+K Ñ X)E´] J Ô§G7Ê°à[Q�Ê�Ì J à^QTS J ] J S J Ô§E!Y J ]Q L°JBJ�� Y LxJ GxG·U§S J©J \IE OIM à�ÊxE+QFÎ�Î(EFX)â
YIÔµUlG°àÒÌ�UµÊ°àè]´U²u J�LxJ \RÊ�U§X)Y^Ô J X J \RÊxQ�ÊxUµEF\^GNä ÿ \ J Î J GxGxQ L á�Î�E!\^]IU�ÊxUµEF\ Ê°E�] J G·U M \pX J Ê°àIE´]IG
8
begin_electronic_commerceDo: electronic_commerce
create_salesman(info){1K}
Do: add_info_sale
^SwManager.re-quest(info_sale)
{1K}
end_electronic_commerce
{1sg}
¤`¥�¦ ¦��´¦ {�b q bdg;b�m q iR|�r�bdrtcwi¼f!r q vNm q n klcNmBbd®Rg�{ q ªtgy|�n q i
U§G5Ê°à J U L Uµ\[] J Y J \^] J \^Î J E�É �^\[Q�Ô8U§XZYIÔ J X J \RÊxQ�Ê°U§E!\½] J Î(UlG·U§E!\[G�ä©ß�\¶Ê°à^Q�Ê6Ì;QTá P Ì J Î�Q!\O G J Êxà J G J XZE´] J ÔlG;Ê°E¼] J S J ÔµEFYºQ!YIYIÔ§U§ÎNQ�Ê°U§E!\[G;Ó^Q!G J ]ºE!\ W 5�ê�ì ÿ P X)EFÓIU§Ô J Q M!J \RÊyG P´J ÊxÎ�äì O Ê�Ê°àIUlG M Q�YîÓ J ÊdÌ JNJ \ ] J G·U M \ Q!\^]îUµXZYIÔ J X J \RÊyQ�Ê°U§E!\ Î�E O Ôl]îÓ J6O \^] J G·U L Q!ÓIÔ J Uµ\ Î J�L âÊxQ�U§\½Î�QFG J G�ä£@IE L6J�� Q�XZYIÔ J!P U§\ Ê°à J G·á´G·Ê J X�Êxà^Q�Ê6Ì J Q LxJ Ê LxJ Q�Ê°U§\ M Ì J Q LxJ \IE�ʳG OILxJàIE�̽X¼Q�\Vá5X¼Q�ïdE L ]IE!XZEFG©G·àIE O Ôl]³Q�Ê·Ê J \^] L°J � O^J G·ÊxG P à^E�Ì X¼Q�\Vá5Î(EF\^Î O^L°LxJ \RÊ O G JNL G;Î�Q!\O G J Ê°à J G·á´G·Ê J X P»J ÊxÎ!ä � E�Ì J S J�LwP Q�ÉÍE L X¼Q�Ô©XZEV] J Ô§ÔµU§\ M Ì�UµÊ°à Ï�J Ê L U�\ J ÊxGG°E!Ô§S J GÊ°à J G J� O^J G·Ê°U§E!\^G�GxQ�ÊxU§G·É�Q!Î(Ê°E L U§ÔµáFäå;à J ] J G°U M \ÒY L E!Y/EFG J ]AU§\=ûµü�2TþB] J Q!Ô§G+Ì�U�ÊxàpEF\ J)O G JNL Q�\^]ÒE!\ J X¼Q�ïdE L ]´EFX)E[ä Ï�J Ê L U
\ J ÊyG�Q�Ô§ÔµE�̽ʰE LxJ Y LxJ G J \RÊ�Î�Q!G J G�G O Îyà�Q!GNÇü!äg5+\ JO G J�L Q�\[]³EF\ J X¼Q�ïdE L ]´EFX)E�éËÊxà J Y L E!Y/EFG J ]ºG·á´G·Ê J X¼í(ä2´ä�È J S J�L Q�Ô O G J�L G�G JNL S J ]6ÓRá³E!\ J X¼Q�ïdE L ]IE!XZE^ä?Iä K Q�\Vá O G JNL G�G J�L S J ]5ÓVá5X¼Q�\Vá5X¼Q�ïdE L ]IE!XZEFG P E!\^Î J Y J�L8L°J � O^J G·ÊNäå;à O G P Uµ\^Î L°J Q!G°Uµ\ M Êxà J XZE´] J ÔµÔ§Uµ\ M�J u�E L Ê P U�Ê;Î(E O Ô§]ZÓ J Y/EFGxG·U§ÓIÔ J Ê°EQTSFE!Ul]�Ê°à J \ J Î J G·â
G·UµÊdá5E�É�U§X)Y^Ô J X J \RÊ°U§\ M Ê°à J G°á´GdÊ J X ÉÍE L Y LxJ ]´UlÎ�ÊxUµ\ M Y J�L ÉÍE L X¼Q�\^Î J � M!OILxJ GNä
� �>Ú�ÛgL�VV°Þ·×\� a=Þ�Ø[Z��°L¡Ø´Ù^Þ�×gL¡Ø[nÿ Ê�Ê°àIUlG�Y/E!U§\FÊ P Ì J à[QTS J XZEV] J Ô§Ô J ]6Êxà J G°áVG·Ê J X Ì�UµÊ°àAY^Q�â Ð+K Ñ \IE�ÊyQ�Ê°U§E!\ P ÊxQ�ãVU§\ M Uµ\RÊxEQ!Î�Î�E O \RÊ�Êxà J ÔµERQ!]ZU§\¼Ê°à J G J � OIJ \[Î J ]´UlQ MFL Q!X Q!\^])Ê°à J G·ÊxQ�Ê J Ê L Q!\^G°U�ÊxUµEF\5]´U§Q M!L Q�X¼GNäFÈVE PQ�Y L Q M X¼Q�ÊxU§Î�Q�YIY L ERQ!Îyà6E!É»Êxà J G·á´G·Ê J X à^QFG;Ó JNJ \�E!Ó´ÊyQ�U§\ J ]-äIì O Ê�Ê°àIUlG LxJ Y LxJ G J \RÊxQ�Ê°U§E!\U§G+\IE�Ê+Y L°J Î(UlG JJ \IE OIM à�ÊxE J�� Y LxJ GxG�E OIL \ JNJ ]IGNä�ê J X J X�Ó JNL Êxà^Q�Ê�Ì J Ì;Q�\RÊ�ÊxE6Y LxJ ]IU§Î(ÊÊ°à J G°áVG·Ê J X Ó J à^QTSVUµE OIL Uµ\�]´Uvu JNL°J \FÊ;Ì;QTáVGNäI@»U L GdÊ P Ì J Ì:Q!\RÊ©ÊxE)G·Ê O ]Iá5àIE�Ì Ê°à J G°á´GdÊ J XÌ©E L ã´G�Ì�UµÊ°à EF\IÔµáîE!\ J5O G J�L G J�L S J ]îÓRáîE!\ J XZQ�ïdE L ]´E!XZE[äw5+\èÊ°à J E�Êxà J�L à[Q�\^] P U�Ê)U§GQ�ÔlG·E)E�É7E OIL Uµ\RÊ J�LxJ G·Ê:ÊxE�ãV\IE�̽ʰà J G°á´GdÊ J X Ó J à^QTSVU§E OIL Ì�à J \ºG J S J�L Q�Ô O G JNL G:Q LxJ G JNL S J ]ÓRá6E!\IÔ§á6EF\ J XZQ�ïdE L ]´E!XZE P E L ÓRáºG J S JNL Q!Ô[X¼Q�ïdE L ]IE!XZEFGNäß�\ÒE L ] JNL Ê°EºE!ÓIÊxQ�U§\pQ!\^G°Ì JNL G�Ê°EºE OIL � OIJ G·Ê°U§E!\^G P Ì J \ J�J ]AÊxE³Q�Y^YIÔµáAY J�L ÉÍE L X¼Q�\^Î J
Q�\^Q!ÔµáRÊ°UlÎÊ J Îyà^\IU�� OIJ G+Ê°EºÊ°à J ] J S J ÔµEFY J ] Y^Q�â Ð+K Ñ ]IU§Q M!L Q�X¼G�ä�ì O ÊÊ°à JNL°J UlG�Q6ÔlQ!ÎyãAU§\Ê°àIUlG£� J Ôl]5Ó J ÎNQ O G J \IE�Y JNL ÉÍE L X¼Q!\^Î J XZE´] J Ô J#� U§G·ÊBÉÍE L:Ð+K Ñ�P G°E�Ê°à J Y L Q M X¼Q�Ê°UlÎ�XZE´] J ÔU§G�\IE!Ê J�� Y LxJ GxG·U§S J:J \IE OIM à7ä ÿ ÔlG·E P Ì J \ J�J ]�Ê°E J�� Y LxJ GxG�G·á´G·Ê J X Î(E!\[Î OILxL°J \^Î(á P Ó O Ê Ð8KÒÑX)E´] J Ô§GÎ�E!\^Î OIL°LxJ \[Î(áºUµ\ÒQ³S JNL áºY/ERE L Ì;QTá!ä�å;à O G P UµÊ�UlG L°J � O U LxJ ]AQ5ÉÍE L X¼Q�Ô0X)E´] J Ô�E�ÉÊ°à J G°á´GdÊ J X Ì�UµÊ°àAÎ(EF\^Î O^L°LxJ \^Î�á5Î�Q!Y^Q�ÓIU§Ô§U�ÊxU J G�äå7EºG·EFÔµS J Ê°à J G J Ô§QFÎyã´G P Ì J à^QTS J Îyà^EFG J \ Ï�J Ê L U7\ J ÊxGQ!G�ÉÍE L XZQ!Ô»XZE´] J Ô P Ó J Î�Q O G J UµÊ
à^Q!G©Ê°à J�LxJ X¼Q L ã J ]¼Î�Q!Y^Q�Ó^UµÔ§U�ÊxU J G;Q�\^]³Q�ÔlG·EÊ°à JNL°J Q LxJ Ì J Ô§ÔµâjãV\IE�Ì�\6Q!\^Q�Ô§áRÊ°UlÎ�Ê J ÎyàI\IU�� OIJ GÊ°E³G·Ê O ]´á G·á´G·Ê J X Y JNL ÉÍE L X¼Q�\[Î J U§\pG·Ê°E´Îyà^QFGdÊxU§Î Ï�J Ê L U7\ J ÊX)E´] J Ô§GNä¡å;à O G P Ì J Y L E!Y/EFG JG·EFX J ù>�°ö�ø^ú��(ñ���ð¼ö�ùjó�ñ�øm�æ0´ôµõ�ú�Ê°EZEFÓ´ÊxQ!Uµ\ Ï�J Ê L U�\ J ÊxG;É L E!X Y^Q�â Ð8K Ñ ]IU§Q M!L Q�X¼G�ä
9
ß�\Êxà J ÉÍE!Ô§ÔµE�Ì�U§\ M^P Ì J XZE´] J Ô´Ì�U�Êxà Ï�J Ê L UF\ J ÊxG0Êxà J � L GdÊ0ÊdÌ:E+Y L E!Y/EFG J ]�G·á´G·Ê J XZG P Ê°à JÊ°àIU L ]ºEF\ J Ì�UµÔ§Ô-Ó J ] J S J Ô§E!Y J ]³Uµ\AQ)É O Ê OILxJ Ì©E L ã�ä[@IE L Ê°à J � L G·Ê8G·á´G·Ê J X P EF\ J�O G J�L Q!\^]E!\ J X¼Q�ïdE L ]´E!XZE P B�È Ï D à[QTS J Êxà J5J�� Y LxJ GxG°UµS J Y[E�Ì J�L Ê°EÒQFÎ�Î(EFXZYIÔµUlG°àèÊ°à J ÊyQ!G°ã�ä»å»EGdÊ O ]´áÊ°à J G J Î�E!\^]�G°á´GdÊ J X P G J S JNL Q!Ô O G J�L G»G J�L S J ]ÓVá�EF\ J XZQ�ïdE L ]´E!XZE P G·Ê°E´Îyà^Q!G·Ê°UlÎ�Ì J Ô§ÔµâÉÍE L X J ]ZÎ(E!Ô§E O^L°J ] Ï�J Ê L UI\ J ÊyG�û ?�þ/Q L°J E!É/U§\RÊ J�LxJ G·ÊNäI5+\^Î J Êxà J G°áVG·Ê J X¼G�Q LxJ XZEV] J Ô§Ô J ] P Ì JO G J Q�\^Q!ÔµáRÊxU§ÎÊ J ÎyàI\^U�� OIJ G�U§X)Y^Ô J X J \RÊ J ]ÒUµ\mB L°J Q�ÊyÈ Ï D û H�þ0Ê°EVE!ԻʰE5EFÓ´ÊxQ!Uµ\ Ê°à J ÊxQ LxM!J ÊY JNL ÉÍE L X¼Q�\[Î JL°J � O U LxJ X J \FÊyG�ä
� ¢�´ �+Àq NÄ��£¡0À} ¬ Ã7Å»ÀI©S¨}Ã^Ä/�ÒÆNÁ-Æ# wÀ}¬ Âk� � ê¡0À~¬8�wÃ[Ä�Å»Ã�¬ Ã��Ô¡»Å Ã�¡»À~�0ÆNÀRÄ@»U L GdÊ P Ì J Q LxJ)M E!U§\ M Ê°E�E!Ó´ÊyQ�U§\îQ Ï�J Ê L U0\ J ÊÉÍE LJ QFÎyàîG°á´GdÊ J X Î�Ô§QFG°G P Ê°à J �yñ�ðg�^ñ�ø/õ�ø^ùø/õ�ù�ú�äI5+ÓVSVU§E O G°Ôµá P!J S J�L á�Q!\I\IE!ÊxQ�Ê J ]¼G·ÊxQ�Ê J Ê L Q!\^G°U�ÊxUµEF\5]´U§Q M!L Q�X Ì�UµÔ§Ô M UµS J�O GBÊ°à J+M!O Ul] J!PQ�\^]6Ê°à J ÉÍEFÔµÔ§E�Ì�U§\ MZM!J \ J�L Q�Ô/Ê L Q�\^G·ÉÍE L X¼Q�ÊxUµEF\ LxO Ô J G;Ì�UµÔ§Ô-Ó J Q�YIY^ÔµU J ]¡Ç���w©�À7´�¢ ��Bñk*�ó �8õ#�°õ�ø^ù���óËø�*TúñW��ù>�°ö�øIú�óËùuó�ñ�øIú��yö�øAòyõ+ó*!õ�ø^ùjó )©õ+*�óËøAö�ú�ù}ö�ù}õ+ù>�°ö�ø^ú�óËùuó�ñ�ø*�ó�ö�÷1�°ö�ð����A�°ö�øIú�óËùjó�ñ�øIú~'9´ó��9 *!ñ ø/ñ�ù�ú>�Iõ�ø�* ø/õ�ùÖ�°õ(ú�ñ�0A�»�yõ(úAö�ø�* ù��xö�øIú�óËùjó�ñ�ø^úG'9´ó��9*!ñ����9Iõ;)Y�yú�ù���óËø�*m�óËôËô�òyõ�ù>�°ö�ø^ú�ôµö�ù�õ+*ÒóËø[ù}ñ��jóËð�ð¼õ+*�ó�ö�ù}õ��³ù��xö�øIú�óËùjó�ñ�ø^ú��}ù:9^ö�ù`)`�xõºóËø� õ#�°ñ�ùjóËð¼õ���óËø ù�9IõÖ<�õ�ù>��ó�ø/õ�ù�����9Iõ5ú(õ+�yñ�ø�* ��óËø�*°�óËôËô©òyõ!�uùjóËðZõ+*"�)ù��xö�øIú�óËùjó�ñ�ø^ú)óËø ù�9Iõ<�õ(ù>��ó�ø�õ(ù��#��9IõpðZõyö�ø�ñW� ù:9^õpõ%$��Iñ�ø/õ�ø^ùjó�ö�ôËô'&d*�ólú�ù���ó�ò#0´ù�õ�*ä�°ö�ø�*!ñ�ð Ü�ö���ó�öFò(ô§õ��(ñ�� ù�9Iõù��°ö�øIú�óËùjó�ñ�ø~)`��óËøV÷èùuóËð¼õG�óËôËô8òyõ~�yö�ôv�#0´ôµö�ù�õ+* öTú�öã�xñ�øIú�ù�ö�ø^ù`�+0´ø��(ùjó�ñ�ø½ñ�³ù�9Iõºð¼õ(úxú�öN÷Fõúyó � õîö�ø�* ø/õ�ù�ú>�^õyõ�*(��,Òñ��°õèõ�ôµö!òyñ��xö�ù�õ�*°���°ñ+�Iñ�ú�ö�ô�úÒô�ó)�!õÒù:9^ñTú�õº÷�ó:Ü�õ(ø�óËø+*�,.-F�yñ�0´ôv*=òxõù}ö��!õ�øÒóËø[ù}ñ³ö1�+�yñ�0´ø^ù0/Bò�0´ù£Bõt9^ö�Ü�õk�xñ�øIú�ó*!õ#�°õ+*6ðZñ �°õ�óËðg�^ñ���ù�ö�ø^ù:ù�ñ÷Rö�óËø ú�óËðg�/ôtó��óËù1&����w©�À�Ú6¢;���(ùjó�ñ�ø^ú6óËøIú�ó*FõÒöpú�ù}ö�ù}õÒñW�³ù:9^õºú�ù}ö�ù}õ�ù>�°ö�øIú�óËùuó�ñ�ø�*�ó�ö�÷1�°ö�ð ö �°õF�yñ�ø^úyó*Fõ��xõ�*öTú ùjóËðZõm�yñ�øIúæ0´ð)óËøR÷2/�ú�ñ óËø�ù:9^õG<�õ�ù>��ó�ø/õ�ù�ð¼ñ�*!õ�ô8ù�9Iõ3&ã�óËôËôòyõm�xñ�øIú�ó*!õ#�pö�ú ùuóËð¼õ+*ù��°ö�øIú�óËùjó�ñ�øIú3�4��9^õ8ùjóËð¼õ\�óËôËô�òxõ �yö�ô���0´ôµö�ù}õ+*£�+�°ñ�ð¾ù�9Iõ65�<C(èö�ø�* *�ólú.�)ñ��^õ��°ö�ùuó�ñ�øIú8ø�õyõ�*Fõ+*ù}ñ �Iõ#���(ñ���ðçù�9Iõ)ö1��ùuó�ñ�ø"����w©�À ³ ¢87=0^ö���*TúZóËø ù:9^õ¼ú�ù�ö�ù�õZù>�°ö�ø^úyóËùjó�ñ�øÐ*�ó�ö�÷1�°ö�ðM�óËôËô;òyõ��yñ�ðZõ5óËð�ð¼õ+*�ó�ö�ù�õ6ù��°ö�øIú�ó:9ùuó�ñ�øIú/�óËù�9 ù�9Iõ ö�úyú(ñ���ó�ö�ù�õ�*��yñ��æ�°õ(ú>�Iñ�ø�*�óËøV÷°���°ñ!òyöFò(óËôtóËùjó�õ(ú;�(ñ ��ù:9^õ~�°õ(ú�ñ�ô 0´ùjó�ñ�ø ñ�°�yñ�ø;9< ó��ùuú=����w©�À � ¢Ö�/ù}ö�ù}õ(ú)óËø=ù:9^õ6úyù�ö�ù�õ6ù��°ö�øIú�óËùjó�ñ�øÐ*�ó�ö�÷1�°ö�ðì�óËôËô;òyõ ��ôµö1�yõ(ú6óËø ù�9Iõk<�õ�ù���ó�ø�õ(ù��� 0´ù:ù:9^õ��xõ��óËôËô�òyõ�ø�ñ�ù:ù:9^õ�0´ø[ó·�0^õQ�/ôµöq�yõ�ú�óËøîù:9^õ�ø�õ(ù0/©òyõ+�xö 0Vú�õ)öq*1*�óËùuó�ñ�ø/ö�ôÔ�/ô§ö1�yõ�úC�óËôËôòxõ�ø/õyõ+*!õ+*5ö�ú�ö�ø óËø���0´ù�ù}ñ��xñ�ø < ó��ùuóËøV÷¼óËð)ðZõ+*�ó�ö�ù}õù>�°ö�ø^úyóËùjó�ñ�ø^ú>�dñFò(ù�ö�óËø�õ�*³ò=&5ö+�1�/ô?&�óËøR÷@g0´ô§õBAC��
@»U M!O^L°J Gt� P � P ü�3 P ü!ü¼Q!\^] ü�2 L°J Y L°J G J \RÊ�Êxà J \ J ÊxG\ JNJ ] J ]ÒÊxEAXZEV] J Ô�E O^L úD&Tú�ù�õ(ð�xñ�ð\�^ñ�ø�õ(ø[ù�ú�ÊyQ�ãVU§\ M Uµ\RÊxEQ!ÎNÎ(E O \FÊBÊ°à J Y L°J SRU§E O G�Ê L Q�\^G·ÉÍE L X¼Q�ÊxUµEF\ LxO Ô J GNä ÿ ÎNÎ(E L ]´U§\ M ÊxEB�È Ï D \IE!ÊxQ�Ê°U§E!\Aû�ü�þ P UµXZX J ]´UlQ�Ê J Ê L Q�\[G·UµÊ°U§E!\^G�é�� L Uµ\ M U§\�� JNL E�ÊxUµX J í�Q LxJ ] L QTÌ�\ZQ!G�Ó[Q L Gé:�^Ô§Ô J ]^í P Ì�àIUµÔ J Ê°U§X J ]pÊ L Q�\^G°UµÊ°U§E!\^GQ LxJ ] J YIUlÎ�Ê J ]èQ!G�Ó/E �´J GZé O \[�^ÔµÔ J ][í�ä»å;U§X J ]ÒÊ L Q�\^G°UµâÊ°U§E!\^G:Q LxJ Q!\I\IE�ÊyQ�Ê J ]ZÌ�UµÊ°à-� L U§\ ML Q�Ê J G P Ì�à^UµÔ J U§XZX J ]´UlQ�Ê J Ê L Q�\[G·UµÊ°U§E!\^G©Q LxJ Q!\I\IE�ÊyQ�Ê J ]Ì�U�ÊxàºY L EFÓ^Q�ÓIU§Ô§U�ÊxU J G:ÉÍE L Î(EF\ r UlÎ�Ê LxJ G°E!Ô O Ê°U§E!\7äå;à J G J � O^J \^Î J ]IU§Q M!L Q�X Ì�U§ÔµÔ�Ó J Ê°à J¼MFO Ul] J Ê°E�E!Ó´ÊyQ�U§\îQã�yñ�ðg�/ô§õ(ù�õ Ï�J Ê L U�\ J Ê�ÉÍE L
Ê°à J G°á´GdÊ J X O G°U§\ M Ê°à J Y LxJ SVU§E O GZÎ�E!XZY[EF\ J \Rʼ\ J ÊxGNä`� J X O GdÊ6Î�E!\^G°Ul] J�L Ê°à[Q�Ê Ð8KÒÑ]´U§G·Ê°U§\ MFO U§G°à J G P U§\�Q�Î(EF\^Î O^L°LxJ \RÊ-G·á´G·Ê J X P ÊdÌ©E�]´Uvu J�LxJ \RÊ7ãVUµ\[]+E!É´X J G°GxQ MFJ G�U§\�Q�G J � OIJ \^Î J]´U§Q M!L Q�X�Ç
y Ê°àIERG JLxJ Y LxJ G J \RÊ J ]³ÓRá³QÉ O ÔµÔ0Q LxL E�Ì�à J Q!] éBö�óËù©ú�õ(ð¼ö�ø[ùuó�(úwí P Q�\^]
10
P15P7
wait_for_service wait_UserforCatalog P4
P6
observe_GUI_catalog
alfred.select_sw_service
alfred_refine_catalog
alfred.select_sw
electronic_commerce
end_ec
begin_ec
¤`¥�¦ ¦FE^¦ �©|�gxm£��gxb�mdr[iFgxb�sycNn�a´cwiRgxi�b
wait_Alfred
P36
P3P4
P5
P6
P7
P8
P9
show_GUI_catalog
add_info3
add_info1 user.observe_GUI_catalogSw_Manager.getcatalog
add_info2
create_GUI
browser.select_sw_browser browser.refine_catalog
refine_catalogselect_software
select_sw_service
¤Y¥v¦ ¦FG^¦ �©ª�kµmdg�fk��gxb�mdr^iRgxbBsycNn�a´cwiFgyi�b
y Ê°àIERG JLxJ Y LxJ G J \RÊ J ]³ÓRá³Q�à[Q�ÔµÉ�Q L°L E�Ì�à J QF] édø�ñH9%Bö�óËù©ú�õ�ðZö�ø^ùjó��úTí�äå;à J ÉÍEFÔµÔ§E�Ì�U§\ M Ê L Q!\^G·ÉÍE L XZQ�Ê°U§E!\ LxO Ô J G�Ì�U§ÔµÔ´Ó J;O G J ]Ê°E�E!Ó´ÊyQ�U§\Êxà J \ J Ê�G°áVG·Ê J X�ä�ì O Ê
� L G·Ê P UµÊ�X O GdÊ�Ó J ÊyQ�ã J \ºUµ\RÊ°E¼QFÎ�Î(E O \RÊ©Êxà^Q�Ê P ÉÍE L;J S J�L á¼X J GxG°Q M!J Uµ\³Ê°à J G J � O^J \^Î J ]IU§Q�âM!L Q�X P Êxà J�LxJ Q LxJ ÊdÌ:EÊ L Q!\^G°U�ÊxUµEF\^G:Ì�U�Êxà6Êxà J G°Q!X J \^Q!X J U§\6ÊdÌ:E)]IU²u J�LxJ \RÊ�Î(E!XZY/E!\ J \RÊ\ J ÊyG P Êxà J \ J Ê L°J Y L°J G J \RÊ°U§\ M Êxà J G J \^] JNL Q�\^]6Ê°à J \ J Ê LxJ Y LxJ G J \RÊxUµ\ M Ê°à J�L°J Î J U§S JNL ä
���w©�À�I6¢�J��ù�9Iõ5ðZõ(úyú�ö�÷RõC9Iö�ú�Bö�óËù�ú�õ�ðZö�ø^ùjó��úD/+ñ�ø^ô'& ñ�ø�õ¼ù>�°ö�ø^ú�óËùuó�ñ�ø8�óËôËô©ö��q�Iõyö �¼óËøù:9^õ��yñ�ðg�/ô§õ(ù�õ+ø/õ�ù7úC&Tú�ù}õ�ðLK-ù:9´ólú�ù��°ö�øIú�óËùjó�ñ�ø��óËôËô[úæ0��1�^ñ���ù0ù:9^õ�óËø��yñ�ð)óËøR÷Zö�ø�*�ñ 0´ùà�yñ�ð)óËøR÷ö��»�(ú`�+�°ñ�ð òyñ�ù�9�ø/õ�ùQ�xñ�ð\�^ñ�ø�õ(ø[ù�ú3�
wait
P3
P4
P5
P6
P7
P8
browser.reply_remote add_info4request
salesman.reply
get_catalogmore_information_remote
browser.create_browser
create_catalog
get_info
browser.reply_local
more_information_local
¤Y¥v¦ ¦"§2M[¦ {�cNk§bu¨ q mdgtû q i q vwgxm���gxb�mdr^iRgxb�sycNn�a´cwiFgyi�b
11
P1
P2
P3
wait
P5P6
P7
P8
P9
P10
P11
P12
P13
P15
P16
P17
P18
P19
P20
SwManager.more_information_remote
reply_local
reply_remote
goto_MU_Place2
create_browser_agent
alfred.show_catalog_GUI
refine_catalog_browser
select_sw_browser
salesman.create_salesman
goto_Sw_Place
refine
goto_MU_Place
not_info_need_or_local
info_need_travel1
SwManager.more_information_local
info_need_local
info_need_travel
not_info_need
delete_browser
¤`¥�¦ ¦"§}§V¦ ÿ»mdc�¨�|�gxm=��g°b�mdr[iFgxb�sycwn�a´cNiRgyi�b
P1 P2 begin_add_info_sale
end_add_info_saleP5P6
SwManager.requestcreate_salesman
user.electronic_commerce
add_info_saleuser.end_ec
user.begin_ec
¤`¥�¦ ¦�§ ¸^¦ { q ª�gx|�n q i���gxb�mdr^iRg°b�sycwn�a´cNiRgyi�b
���w©�ÀON�¢�J�©ù�9Iõ�ðZõ(úyú�ö�÷Rõ�9^öTú;ø/ñH9%Bö�óËù7ú�õ�ðZö�ø^ùjó��úD/¡ù�9Iõ�ù>Bñù>�°ö�ø^ú�óËùuó�ñ�øIú=�óËôËô[ö��q�Iõyö��8óËøù:9^õ;ø/õ�ù¡úC&Tú�ù}õ�ð ö�ø�*�ö�ôtú(ñö�ø6õ%$!ù>�°öY��ôµö1�yõQ�óËôËô^òyõ+ö1*1*Fõ+*ðZñ�*!õ�ôËôtóËøV÷�ù�9Iõ��xñ�ð�ð 0´ø^ó�yö�ùuó�ñ�øò�0=�8õ#�3����9Vólú��/ô§ö1�yõC�óËôËô6�°õ+�yõ(ó:Ü�õ�ö�øîö �»�`�+�°ñ�ð ù�9Iõ�ú�õ(ø�*!õ#�ù��°ö�øIú�óËùjó�ñ�øîö�ø�*-�óËôËô»ö1*q*³ö�øö��»�ù}ñ5ù:9^õ��xõ��yõ�ó:ÜTõ#��ù>�°ö�ø^úyóËùjó�ñ�øP�å;à J \ J ÊZG·á´G·Ê J X ÉÍE L Ê°à J6J�� Q�XZYIÔ J U§G�G·à^E�Ì�\îU§\8@0U MFOILxJ ü�?Iä7ß�\ E L ] J�L ÊxE O \^] JNL â
GdÊyQ�\^]îàIE�Ì Ê°E Q!YIYIÔ§á Ê°à J Y LxJ SVUµE O G LxO Ô J G P Ì J Q L°JZM EFUµ\ M ÊxE J�� YIÔlQ�U§\èàIE�Ì ÊxEAE!Ó´ÊyQ�U§\Ê°à JGÈ[Å"¹º1ÀvÁ"º Ë£ÌYÍ ½�É�¾É}¼ È1Ê Ê L Q!\^G·UµÊ°U§E!\ Uµ\ Êxà J \ J ÊZG·á´G·Ê J X é�@»U M!O^L°J ü�?Fí�É L EFX@Êxà JGÈ[Å�幺 À�Á"º Ë£ÌYÍ ½�É�¾É}¼ È1Ê X J GxG°Q M!J G J \RÊ�ÓVá ÿ Ô�É LxJ ]ÒÊ°EºÊ°à J¼O G JNL Uµ\pÊ°à J G J � O^J \^Î J ]´UlQ MFL Q!X�ä� J Î�Q!\ÒEFÓ^G JNL S J U§\ ÿ Ô�É LxJ ]6é G�\ J ʼé�@0U MFOIL°J �Fí�Q!\^] U§\ÒÊxà JZO G J�L é G+\ J Ê5é�@»U M!O^L°J �Fí8Ê°à JY L°J G J \^Î J E!É/Êxà^Q�Ê�Ê L Q!\^G°U�ÊxUµEF\-äFÈVE P Uµ\ZÊxà J \ J Ê:G·á´G·Ê J X Ê°à J Ê L Q!\^G°U�ÊxUµEF\ZQ!YIY J Q L G�Ì�UµÊ°àZÊ°à JO \IU§E!\AE�É�Êxà J U§\^Î(EFX)U§\ M Q!\^]�E O ÊxÎ(EFXZUµ\ M Q L ÎNG�E�É�Êxà J Î(EFXZY[EF\ J \RÊxG P G°áV\^Îyà L E!\IUlG°Uµ\ M U§\Ê°àIUlG�Ì;QTá¼Ó[E!Ê°à�E!Ó´ï J Î�ÊyG�ä
@»U§\^Q!ÔµÔ§á P Ì J+L°J X¼Q L ã�Ì�UµÊ°àºQ�\ J#� Q!XZYIÔ J Ê°à^Q�Ê©Êxà J Î(E!\[Î OILxL°J \^Î(á J�� Y LxJ GxG J ]ZU§\ Ð8KÒÑà^Q!GÓ JNJ \ QFÎyàIU J S J ]pU§\èÊ°à J \ J Ê)G°áVG·Ê J X%ÓVáèG·áV\^Îyà L EF\IU§G°U§\ M Î(EFX)Y/E!\ J \RÊ\ J ÊxGNä��¶à J \½�À�º�É�¾Wº ¹�É}¼ º#¹ Ï É}Ñ Ê L Q!\^G°U�ÊxUµEF\�� LxJ G»E!\ J Ê°EFã J \UlG»Y^Ô§QFÎ J ]Uµ\ ý"QqÎ Q!\^]�EF\ J Ê°E!ã J \�UlG0YIÔlQ!Î J ]Uµ\ ý"RÔÃ!P Q�Ô§ÔµE�Ì�U§\ M Q)Î(EF\^Î O^L°LxJ \RÊ J#�´J Î O Ê°U§E!\5E!É-Ê°à J À�º�øÔß�º�¹W¾ Q!\^] Øqº ¼ º#¾Wº Å À�È"¿£¹»º À Ê L Q�\^G°UµâÊ°U§E!\^GNä� ¢:Ú �+Àq NÄ��Q¡»À} �¬ Ã-Å0ÀI©Y¨}Ã^Ä°�èÆ�Á-Æ� NÀI¬ Âk� � Ã�¡»À{¬8�wÃ[ÄTÅ0Ã�¬ Ã{�Ô¡»Å½ÆwÀ}�[ÀRÄ��[©
�0ÆNÀRÄ�Æß�\=E L ] JNL Ê°EèXZEV] J Ô�Ì�UµÊ°à Ï�J Ê L U;\ J ÊxG)Êxà J G·UµÊ O Q�Ê°U§E!\ E�ÉG J S JNL Q!Ô O G JNL G)Ó J U§\ M G JNL S J ]ÓRáîE!\ J X¼Q�ïdE L ]´EFXZE P Ì J \ JNJ ]îÊ°EpUµ\[Î(Ô O ] J G J S J�L Q�Ô�ÊxE!ã J \^G�U§\ G°E!X J YIÔlQ!Î J GÔµU§ã JFP ÉÍE L
12
m1=
2
P1
wai
t_Sw
Man
ager
P5
P6
P7
P8
wai
t_U
serf
orSe
rvic
e
wai
t_U
serf
orC
atal
og
P15
P16
P17
P18
P19
P20
begi
n_ad
d_in
fo_s
ale
P22
P23
end_
add_
info
_sal
e
P25
P26
P27
wai
t_B
row
ser
P29
P30
P31
wai
t_A
lfre
d
P35
P36
P37
P38
P39
P40
P41
P42
P43
P46
P44
P45
P47
P49
P48
P50 P5
1
P52
P53
P54
P55
P56
brow
ser.
repl
y_re
mot
ego
to_M
U_P
lace
2
get_
info
obse
rve_
GU
I_ca
talo
g
mor
e_in
form
atio
n_re
mot
e
goto
_MU
_Pla
ce
goto
_Sw
_Pla
ce
add_
info
_sal
e
show
_cat
alog
_GU
I
crea
te_c
atal
og
add_
info
4 crea
te_s
ales
man
add_
info
3
add_
info
2
add_
info
refi
ne
crea
te_B
row
serA
gent
crea
te_G
UI
brow
ser.
repl
y_lo
cal
info
_nee
d_tr
avel
info
_nee
d_lo
cal
sele
ct_s
w
refi
ne_c
atal
og
not_
info
_nee
d
sale
sman
.rep
ly
requ
est
sele
ct_s
w_b
row
ser
refi
ne_c
atal
og_b
row
ser
sele
ct_s
w_s
ervi
cege
t_ca
talo
g
t38
t37
t36
elec
tron
ic_c
omm
erce
not_
info
_nee
d_or
_loc
al info
_nee
d_tr
avel
1
mor
e_in
form
atio
n_lo
cal
dele
te_b
row
ser
begi
n_ec
end_
ec
¤`¥�¦ ¦�§ è^¦ ¯�®Rg\��gxb�mdr^iRg°b�klcNmBbd®Rg©¨�®Rcwªtg�|}�!|}bdgyn
13
Uµ\^G·ÊxQ!\^Î JFPÔ¿YÉ1 ¾ Ì'¹º À�Ò�ÈIÀTSIº À�Á  ½#º ä-ÈVU§\^Î J Ê°à J G°á´GdÊ J XçX O G·Ê�]´U§G·Ê°U§\ MFO U§G°àÒÓ J ÊdÌ J�J \Ò]´Uvu JNL âJ \RÊ�Ê°EFã J \[G¼éËÊ°à J á LxJ Y L°J G J \FÊ�]´Uvu JNL°J \RÊ L°J � O^J G·ÊxGyí P Ì J QF]I]èQ�Î(E!Ô§E O^L ]IE!X¼Q�U§\îÉÍE L Ê°à JL°J � O^J G·ÊxG P Ê°à O G;Ô J Q!]IUµ\ M ÊxE5GdÊxEVÎyà[Q!G·Ê°UlÎ+Ì J Ô§ÔµâuÉÍE L X J ]³Î(EFÔµE OIL°J ] Ï�J Ê L U�\ J ÊyG�û ?�þjä
5 OIL E!Ó´ï J Î�Ê°U§S J \IE�Ì UlG0Ê°E LxJ QFÎyà�Ê°à J G·Ê°E´Îyà^QFGdÊxU§Î©Ì J Ô§Ô�âjÉÍE L X J ]Î�E!Ô§E OILxJ ]�\ J ÊyG0ÉÍE L Ê°à JÎ(E!XZY/E!\ J \RÊxG�Q�\[]�ÉÍE L Ê°à J G°áVG·Ê J X�ä Ñ-J Ê O G�Ó JNM U§\)Ì�UµÊ°à�Ê°à J Î(E!XZY/E!\ J \RÊ�\ J ÊxGNä ÿ G�Uµ\)Ê°à JY L°J SVUµE O G»G°á´GdÊ J X P Î(EFX)Y/E!\ J \RÊ»\ J ÊxG0Ì�U§ÔµÔ´Ó J EFÓ´ÊxQ!Uµ\ J ]�É L E!X�Êxà J Q�\I\IE!ÊxQ�Ê J ]GdÊyQ�Ê J Ê L Q�\IâG·UµÊ°U§E!\5]´UlQ MFL Q!X¼G�ä � J Ó J�M Uµ\5Ê°à J Ê L Q�\^G°Ô§Q�Ê°U§E!\)ÊxQFG·ã�éËÉ L E!X Y L Q M XZQ�Ê°UlÎ�XZE´] J Ô^Ê°E�ÉÍE L X¼Q!ÔX)E´] J Ôlí O G·U§\ M Êxà J�LxO Ô J G8G·ÊxQ�Ê J ]³U§\AÊxà J Y LxJ SVU§E O G�G J Î(Ê°U§E!\-ä[å;à JÏ�J Ê L U7\ J ÊyG�ÉÍE L ÿ ﵃ L°J ]Q�\^]ZÊxà J ÈVE�ÉËÊdÌ;Q LxJ+K Q!\^Q MFJ�L Ì�U§Ô§Ô/Ó J Ê°à J G°Q!X J Ó J Î�Q O G J E!\^ÔµáZE!\ J U§\^G·ÊxQ�\[Î J E!É J QFÎyà5U§GY L°J G J \RÊ;U§\ºÊ°à J G°á´GdÊ J X�ä�5+\³Ê°à J Î�E!\RÊ L Q L á P Êxà J G·á´G·Ê J X Ì�U§ÔµÔ-à[QTS J Q!G;X¼Q�\Vá6U§\^G·ÊxQ!\^Î J GE�É O G JNL G P Ó L E�Ì�G JNL G;Q�\[]³GxQ�Ô J G°X J \�Q!G LxJ � O U L°J ] P G O YIY[ERG J �^S J ÉÍE L Ê°à J�J�� Q�XZYIÔ J ä
D�E�Ì P Y^QTá6Q�Ê·Ê J \RÊ°U§E!\ºE!\°@»U M!O^L°J ü#H P Ì�àIU§Îyà LxJ Y LxJ G J \RÊxGBÊ°à J Ì J ÔµÔµâuÉÍE L X J ]6Î(EFÔµE OILxJ ]Ï�J Ê L U�\ J Ê�ÉÍE L Êxà J5O G J�L ä7å;à JOU Î(EFÔµE OIL X J Q�\[GÊ°à^Q�Ê�Ê°à J G·á´G·Ê J X ] J Q�ÔlGÌ�U�Êxà E!\ J ÊxE�^S J+L°J � O^J G·ÊxGBQ!\^]ZÊxà J U§\IUµÊ°UlQ�Ô/X¼Q L ãRU§\ M Ï Ã U§\6YIÔlQ!Î J\¿YÉ1 ¾ Ò�ÈIÀ ¹º À�Á1 ½�º ] J \IE!Ê J GBÊ°à[Q�Ê:Q!ÔµÔÎ(ÔlQ!GxGUµ\^G·ÊxQ!\^Î J G�Ì�U§ÔµÔ©Ó J5O G J ]¡ä K E L°J E�S J�LwP Q�Ô§Ô�Ê°à J YIÔ§QFÎ J G�Uµ\èÊxà J \ J Êà^QTS J Î�E!Ô§E OIL#UQ�\^]³Ê°à J Q L Î�G�Q LxJ Ô§Q!Ó J Ô J ]³Ì�UµÊ°à�Êxà J Ul] J \RÊ°UµÊdá5É O \^Î�ÊxUµEF\èé¯WV�X8í P U§\³ÊxàIUlG�Ì:QTá6E!\IÔ§á5E!\ JL°J � O^J G·Ê�Î�E O Ôl]³Ó J � LxJ ]ºEF\^Î J Q�Ê°U§X J ä
@»U M!O^L°J üwý³G·à^E�Ì�G�Êxà J Ì J ÔµÔµâuÉÍE L X J ]ÒÎ(EFÔµE OILxJ ] Ï�J Ê L U»\ J Ê�ÉÍE L Êxà J ì L E�Ì�G J�L ä^ß}Ê�à^QFGÓ JNJ \îE!Ó´ÊyQ�U§\ J ]pQ�YIYIÔ§áVUµ\ M Êxà J Ê L Q!\^G·ÉÍE L XZQ�Ê°U§E!\ LxO Ô J G+Ê°E³Ê°à J ì L E�Ì�G JNL3Y G+ÈIå�ëä¡ß�\IUµÊ°UlQ�ÔXZQ L ãVU§\ M Ï Ã U§\�Y^Ô§QFÎ Jgýwà G·àIE�Ì�G-Ê°à^Q�Ê�Q+X¼Q � U§X O X E!É[�^S J Ó L E�Ì�G JNL G»Î(E O Ô§]�Ó J Î LxJ Q�Ê J ] PE!\ J ÉÍE L�J Q!Îyà O G J�L G L°J � O^J G·ÊNä^È´Q!Ô J G·X¼Q�\ºÌ J Ô§Ô�âjÉÍE L X J ]6Î�E!Ô§E OILxJ ] Ï�J Ê L U�\ J Êé�G J�J @0U M!OILxJü�4Fí©à^QFG;Ó JNJ \A] J G·U M \ J ]6U§\ºÊ°à J GxQ�X J Ì;QTá!ä
P15 R
P7
R
wait_for_service
Rm1wait_UserforCatalog
R
P4
R
P6R
observe_GUI_catalog
alfred.select_sw_service
alfred_refine_catalog
alfred.select_sw
electronic_commerce
end_ec
begin_ec<x> <x>
<x>
<x>
<x> <x>
<x>
<x>
<x><x><x><x><x><x>
R:crequest:cS:mm1:m
¤`¥�¦ ¦�§�õ[¦ �:|�gxmBsycNª�cN«Fmdg�f ��gxb�mdr/iFgxb�sycwn�a´cNiRgyi�b
D�E�Ì P Ì J Q LxJ8M EFUµ\ M Ê°E�ÉÍE´Î O G©E!\6Ê°à J Î(EFX)Y^Ô J Ê J Ì J Ô§ÔµâuÉÍE L X J ]6Î(E!Ô§E O^L°J ]Z\ J Ê:ÉÍE L Ê°à JG·á´G·Ê J X P G JNJ @0U MFOILxJ ü"�´ä»å;à J Ê L Q�\^G·ÉÍE L X¼Q�ÊxUµEF\ LxO Ô J G M U§S J \ Uµ\ Êxà J Y L°J SVUµE O G�G J Î�ÊxUµEF\Ì�UµÔ§Ô M UµS J�O G�Ê°à J�M!O Ul] J ÊxE6Î(EF\^G·Ê LxO Î�Ê8UµÊNä�ß�\ QF]I]´UµÊ°U§E!\ P Ê°à J ÉÍE!Ô§ÔµE�Ì�U§\ M Ê L Q!\^G·ÉÍE L XZQ�Ê°U§E!\L°O Ô J G;Ì�U§Ô§Ô-Ó J Q!YIYIÔ§U J ]³Î�E!\^Î J�L \IU§\ M Ê°à J Î�E!Ô§E OIL G�Ç���w©�À�Z6¢;�+ôËôA�yñ�ôµñ 0A�yú:ö�ø�*�ðZö �.��óËøV÷�úQ*!õ�)�ø/õ+*+óËøZù:9^õ\�yñ�ðg�Iñ�ø/õ�ø^ù¡ø�õ(ùuú`�óËôËô^òyõ:óËøI9Iõ#��óËù�õ�*ò=&¼ù�9Iõø/õ�ù�úC&Tú�ù}õ�ð[����w©�ÀO\�¢ ��9IõÖ��ôµö1�yõ(ú/�óËù�9Ð�xñ�ôµñ�0A��ö�ø�*D]�ñ �³ð¼ö��.��óËøR÷�ú³óËø ù�9Iõ~�yñ�ðg�Iñ�ø/õ�ø^ùuú6ø/õ�ùuú-�óËôËôö��1�^õyö���óËøpù:9^õ�ø�õ(ùBúC&Túyù�õ�ð óËø ù�9Iõ�ú�ö�ð¼õCBöH&����w©�ÀO^�¢ ��9Iõ6ö��»�(ú�ôµöFòyõ(ôËôµõ+*�óËøèù�9Iõ-�yñ�ð\�^ñ�ø�õ(ø[ù�ø/õ�ù�úÖ�óËôËô�ö+�1�^õxö �ZóËø ù:9^õ)ø/õ�ù;úD&Tú�ù�õ(ðóËøÒù�9Iõ�ú(ö�ðZõÖBöH&�
14
P1 Rm1
P2R
P3 R
wait
R
P5
RP6R P7 R
P8R
P9R
P10R
P11R
P12 R
P13R
P15R
P16
R
P17 R
P18 R
P19
R
P20
R
SwManager.more_information_remot
reply_local
reply_remote
goto_MU_Place2
create_browser_agent
alfred.show_catalog_GUI
refine_catalog_browser
select_sw_browsersalesman.create_salesman
goto_Sw_Place
refine
goto_MU_Place
not_info_need_or_local
info_need_travel1
SwManager.more_information_local
info_need_local
info_need_travel
not_info_need
delete_browser
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x><x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x><x><x><x>
<x>
<x>
<x>
<x>
<x>
<x>
<x><x><x>
<x><x><x> <x>
<x>
R:crequest:cS:mm1:m
¤`¥�¦ ¦�§1ú^¦ ÿ7mdc(¨�|�g°m:sycNªtcw«Fmdgyf���gxb�mdr[iFgxb�sycNn�a´cwiRgxi�b
P1Rm1
P2R
begin_add_info_saleR
end_add_info_saleR
P5R
P6R
SwManager.requestcreate_salesman
user.electronic_commerce
add_info_saleuser.end_ec
user.begin_ec
<x>
<x><x><x>
<x>
<x> <x> <x> <x>
<x>
R:crequest:c
S:m
m1:m
¤`¥�¦ ¦�§1þI¦ { q ªtgy|�n q iZsycNª�cN«Fmdg�f ��gxb�mdr[iFgxbBsycwn�a´cNiRgyi�b
���w©�À7´`_6¢85�ñ�ø < ó��ùuóËøV÷5ö��»�(ú�ö �°õù�9IñTú�õ�ù�9Iö�ùBö��1�^õyö��ôµöFòxõ�ôËôµõ+*ZóËø ök�yñ�ðg�Iñ�ø/õ�ø^ù�ø/õ�ùBò#0´ùø/ñ�ù0óËø6ù�9Iõt�yñ�ðg�Iñ�ø/õ�ø^ù0ø/õ�ù''9´ó��96óËù0ólú;úD&�ø���9A�°ñ�ø[ólú�õ�*(�ba-9Iõ�øG�yñ�ø < ó�(ùjóËøR÷Zö�����ú8ö��q�Iõyö �D/ù:9^õ8ø�õ(ù0úC&Tú�ù}õ�ð¾ðC0Vú�ù69Iö ÜTõ�ù�9Iõ�ù>Bñ�ö �»�(ú�ôµö!òyõ�ôËôµõ+*c/����°õ(ú�õ��æÜwóËøR÷)óËøºù�9VólúgBö2&ù�9Iõ���ó��9^õ�ú�ùú(õ�ð¼ö�ø^ùjó���ÿ GZQ�\ J�� Q�XZYIÔ J E!É�ê O Ô J �pG J�J E O ÊxÎ(EFXZUµ\ M Q L Î�GÉÍE L Ê°à J G°áV\^Îyà L E!\IUlG J ]èÊ L Q!\^G·UµÊ°U§E!\[G¹º ¼ º�½æ¾ ¹W¿ Q�\^] É}¼ Ò%À�º�ØªÓ ¹º1¼ º�½�¾ ¹W¿ U§\°@0U M!OILxJ GQ�ZQ!\^]Òü�H L°J G·Y J Î(Ê°U§S J Ô§á!ä
� J³L°J XZQ L ãÒÊ°à^Q�ÊÊxà J Î�E!XZYIÔ J Ê J Ì J ÔµÔµâuÉÍE L X J ] Î(E!Ô§E O^L°J ]è\ J Ê�ÉÍE L Êxà J G°á´GdÊ J X ] J âG°Î L U§Ó J G+Î�E!\^Î OILxL°J \^Î(áºQ�Ê8Êxà J GxQ�X J Ô J S J Ô�Q!G�Ê°à J Î(EFX)Y^Ô J Ê J \ J Ê�ÉÍE L Ê°à J G·á´G·Ê J X M UµS J \Uµ\³Ê°à J Y L°J SRU§E O G©G J Î(Ê°U§E!\-ä K E L°J E�S JNLNP U�Ê�U§\FÊ L E´] O Î J G�Q�\ J Ì Ô J S J Ô¡E�É»Î�E!\^Î OILxL°J \^Î(áFäVå;à JO G J E�É0Î(E!Ô§E O^L°J ])Ê°E!ã J \^G:XZE´] J ÔlG:Î(E!\[Î OILxL°J \RÊ O G J�L:L°J � OIJ G·ÊxG©E�É»Q)Î(EFXZYIÔ J Ê J G JNL SVUlÎ JFP QFGU�ÊBÎNQ�\ZÓ J G J�J \ZUµ\)Ê°à JQ¹º ¼ º�½æ¾ ¹W¿ ¹º1ÀvÁ1 ½�º Ê L Q!\^G·UµÊ°U§E!\ P Ê°à^Q�ÊBÎ�Q�\ � LxJ G J S JNL Q!ÔFÊxE!ã J \^G0É L E!XYIÔ§QFÎ Jt¿YÉ1 ¾ Ì�¹»º À�Ò�ÈIÀ:SIº1ÀvÁ1 ½�º�LxJ Y L°J G J \FÊxUµ\ M G J S J�L Q�Ô O G J�L�LxJ � OIJ G·ÊxGNäd �°L-Ù[_yÚ�ÙªR P�×+Ý�L�Ù[L'nRÜ�V�Ø[nå;à J8LxJ G O ÔµÊxG©Y L°J G J \RÊ J ]5Uµ\¼ÊxàIUlG:G J Î(Ê°U§E!\5à[QTS J Ó J�J \6E!ÓIÊxQ�U§\ J ]ZÉ L EFX Ê°à J Î(EFX)Y^Ô J Ê J \ J ÊxGÊ°à^Q�Ê�X)E´] J Ô�Ê°à J¼J�� Q�XZYIÔ J G�Ù�Ê°à J Î�E!XZYIÔ J Ê J \ J Ê�Êxà^Q�Ê�XZE´] J ÔlGÊxà J Î�QFG J U§\îÌ�à^U§ÎyàîÊ°à JG·á´G·Ê J X UlG O G J ] ÓVáîE!\ J6O G JNLNP Ì�àIE UlGQ�Ê·Ê J \^] J ] ÓVápEF\IÔµáîE!\ J X¼Q�ïdE L ]´EFX)EAQ!\^]èÊ°à JÎ(E!XZYIÔ J Ê J \ J Ê;Ê°à[Q�Ê�XZE´] J ÔlG:Ê°à J ÎNQ!G J U§\�Ì�àIU§Îyà³Ê°à J G°á´GdÊ J X UlG O G J ]³ÓVá6G J S JNL Q!Ô O G J�L G PÌ�àIU§ÎyàAQ L°J Q�Ê°Ê J \[] J ]ºÓVá5E!\^Ôµá³E!\ J X¼Q�ïdE L ]´EFXZE^ä
15
P1R
wai
t_Sw
Man
ager
P5R
P6 R
P7 R
P8R
wai
t_U
serf
orSe
rvic
eRm
1
wai
t_U
serf
orC
atal
ogR
P15
R
P16 R
P17
RP1
8R
P19
Rm
1
P20
R
begi
n_ad
d_in
fo_s
ale
R
P22 R
P23 R
end_
add_
info
_sal
eR
P25
Rm
1
P26
RP2
7 R
wai
t_B
row
ser
R
P29
R
P30
R
P31
R
wai
t_A
lfre
d
P35 R
P36
R
P37R
P38R
P39
R
P40
R
P41 R
P42 R
P43 R
P46
R
P44
R
P45
RP4
7 R
P49 R
P48
R
P50
R
P51
R
P52
R
P53
R
P54 R
P55
R
P56
Rbr
owse
r.re
ply_
rem
ote
goto
_MU
_Pla
ce2
get_
info
obse
rve_
GU
I_ca
talo
g
mor
e_in
form
atio
n_re
mot
e
goto
_MU
_Pla
ce
goto
_Sw
_Pla
ce
add_
info
_sal
e
show
_cat
alog
_GU
I
crea
te_c
atal
og
add_
info
4
crea
te_s
ales
man
add_
info
3
add_
info
2
add_
info
refi
ne
crea
te_B
row
serA
gent
crea
te_G
UI
brow
ser.
repl
y_lo
cal
info
_nee
d_tr
avel
info
_nee
d_lo
cal
sele
ct_s
w
refi
ne_c
atal
og
not_
info
_nee
d
sale
sman
.rep
ly
requ
est
sele
ct_s
w_b
row
ser
refi
ne_c
atal
og_b
row
ser
sele
ct_s
w_s
ervi
cege
t_ca
talo
g
t38
t37
t36
elec
tron
ic_c
omm
erce
not_
info
_nee
d_or
_loc
al info
_nee
d_tr
avel
1
mor
e_in
form
atio
n_lo
cal
dele
te_b
row
ser
begi
n_ec
end_
ec
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x><
x>
<x><x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x> <x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x> <x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x>
<x> <x>
<x> <
x>
<x>
<x>
<x>
<x>
R:c
requ
est:c
S:m
m1:
m
¤`¥�¦ ¦�§(�´¦ ¯�®Rg�sycNª�cN«Fmdg�f���g°b�mdr[iFgxb�klc�m©bd®Fg:¨�®RcNª�g�|}�!|}bdgyn
16
ß}Ê»UlG»E!ÉIE OIL Uµ\RÊ J�LxJ G·Ê7Ê°EG·Ê O ]´á�Êxà J G°á´GdÊ J Xc�°õ(ú>�Iñ�øIú�õ�ùjóËðZõ©U§\�Êxà J Y L°J G J \^Î J E!É[Q O G JNLL°J � O^J G·ÊNä�å7EEFÓ´ÊxQ!Uµ\�Ê°à J;LxJ G°Y[EF\^G J ÊxUµX J!P � L G·Ê�Ê°à J Êxà L E OIM à^Y O Ê�E�É[Ê°à J=¹º1¼ º�½�¾ ¹¿ ¹»º À�Á  ½#ºÊ L Q�\^G°U�ÊxUµEF\ P Uµ\AÊxà J \ J ÊG·á´G·Ê J X P Ì�UµÔ§Ô�Ó J Î�Q!ԧΠO Ô§Q�Ê J ]AÓVá�Î�E!XZY O ÊxUµ\ M Ê°à J G·Ê J Q!]´á�GdÊyQ�Ê J]´U§G·Ê L U§Ó O Ê°U§E!\èE!É©Êxà J U§G°E!XZE L YIà^U§Îe5�ñ�ø[ùuóËøª0^ñ�0Vú��-óËð¼õ�,Òö��.�Fñ�Üf5�9Iö�óËø é W å KîW í�Ì�U�Êxà7��xõxö�ù�[<hg û H�þàÙ"�^\^Q!ÔµÔ§á P Ê°à J U§\VS JNL G J E�É[Ê°à J Y LxJ SVU§E O G L°J G O Ô�Ê M U§S J G-Êxà J G·á´G·Ê J X LxJ G°Y/E!\^G JÊ°U§X J ä4aAõ�Bö�ø^ù0ù�ñi��ø/ñ 8'9Vó�+9ºö��°õ+ù�9Iõòyñ�ùjùuôµõ�ø/õ+�D�Tú+ñ��ù�9Iõ8úC&Túyù�õ�ð ö�ø�*ó*!õ�ø^ùjó �D&ù�9Iõ�ó:�óËð\�^ñ���ù�ö�ø��xõ�äNå;à J�LxJ Q LxJ ÊdÌ©E;Y/EFGxG·U§ÓIÔ J Y^Q L ÊxG�Ì�à^U§Îyà�ÎNQ�\�] J Î L°J Q!G J G·á´G·Ê J X�Y JNL ÉÍE L X¼Q!\^Î J ä@»U L GdÊ P Ê°à J Ê L U§Y^G�E�ÉIÊxà J ì L E�Ì�G J�L É L EFX Ê°à J z O G J�L YIÔlQ!Î J�| ÊxE+Êxà J z°G°E�ÉËÊdÌ;Q LxJ YIÔlQ!Î J�| é�Q!\^]Ì:QTá)Ó^Q!ÎyãIí�Uµ\³E L ] J�L Ê°EEFÓ´ÊxQ!Uµ\6\ J ̽ÎNQ�ÊxQ!ÔµE M GNäRÈ J Î(EF\^] P Ê°à J�O G J�LBLxJ � OIJ GdÊyG�ÉÍE L ÎNQ�ÊyQ�Ô§E ML°J �^\ J X J \FÊyG P Ó J ÎNQ O G J Gyæ�à J U§G�\IE�Ê�GxQ�Ê°UlG� J ]ºÌ�UµÊ°à�U�Êwäß�\ E L ] J�L ÊxE GdÊ O ]´á=Ê°à J ÊdÌ:E Y/EFGxG·U§ÓIÔ J Ó[E!Ê·Ê°Ô J \ J Îyã´G P Ì J à[QTS J ] J S J Ô§E!Y J ] QèÊ J G·Ê
ÊxQ�ãVU§\ M Uµ\RÊxEZQFÎ�Î�E O \RÊ;Ê°à J ÉÍEFÔµÔ§E�Ì�U§\ M Y[ERG°G°UµÓ^UµÔ§U�ÊxU J G�Çü!ä=�¶à J \pù:9^õ � �°ñ��ú�õ#�+ø�õxõ+*�ú�ö)ø/õ#d�yö�ù}ö�ôµñ°÷Òé O \[] J�L:L°J � OIJ G·ÊBE�É7Ê°à J+O G JNL í�Ê°à JNL°J Q LxJG J S JNL Q!Ô/Y/EFGxG°UµÓIU§Ô§U�ÊxU J G�Çy å;à J ì L E�Ì�G J�L à^QFG J \IE OIM à³Uµ\´ÉÍE L X¼Q�Ê°U§E!\5ÊxE¼Q!Î�Î�E!XZYIÔ§U§G°à³Ê°à J ÊxQFG·ã6E L U�Ê�\ JNJ ]IGÊ°EîQ!G°ãÒÉÍE L Êxà J U§\´ÉÍE L X¼Q�ÊxUµEF\-ä7ß}ÊZUlGX J QFG O^L°J ]èÓRápÊ°à J�Ñ"È ¾ ²Ñ�Ò�È Ñ�º�º�Ø Ê L Q�\^G°UµâÊ°U§E!\7äª� J à^QTS J Î(EF\^G°U§] JNL°J ]�Q�\�z°Uµ\RÊ J ÔµÔ§U M!J \RÊ8ì L E�Ì�G JNL�| Ì�àIUlÎyàÒ]´E J G8\IE�Ê�\ J�J ]U§\´ÉÍE L X¼Q�Ê°U§E!\³Ê°à J ��3kj¾E�É0Ê°à J ÊxUµX J G�Ê°à^Q�Ê:Êxà J�O G J�L QFG·ã´G:ÉÍE L Q LxJ �^\ J X J \RÊNä
y �¶à J \ Êxà J ì L E�Ì�G J�L \ J�J ]IG)Uµ\´ÉÍE L X¼Q�Ê°U§E!\ ÊxEpY J�L ÉÍE L X Ê°à J ÊyQ!G°ã P UµÊ¼X¼QTá L°J â� OIJ G·Ê�U�Ê�ÓVáÒQ{�°õ�ðZñ�ù}õ ���°ñ��yõ�* 0A�°õ��yö�ôËô+é�ê Ï:W í)é LxJ Y LxJ G J \RÊ J ] U§\pÊ°à J \ J Ê�G·á´G·âÊ J X¾ÓRáÊ°à J;²Ñ�Ò�È Ñ�º�º�Ø ¼ ÈI½�É}¼ Ê L Q!\^G°U�ÊxUµEF\[í0E L UµÊ©X¼QTáÊ L QTS J ÔVÊxà L E OIM àZÊ°à J \ J Ê�ÊxEÊ°à JlSAÈ Ò:¾>¿YÉ À�º m}¼ É�½�º é LxJ Y LxJ G J \RÊ J ]¼U§\6Êxà J \ J Ê8G°á´GdÊ J X ÓVá¼Êxà JÖ²Ñ�Ò�È Ñ"º#º�Ø ¾æÀ:É�Á"º ¼Ê L Q�\[G·UµÊ°U§E!\[í�Ê°E MFJ Ê�Êxà J U§\´ÉÍE L X¼Q�ÊxUµEF\5Q�\^])Êxà J \¼Ê L QTS J ÔIÓ[Q!Îyã�Ê°E�Êxà JCü/Ì ý'¼ É�½�º äß�\5ÊxàIUlG©ÎNQ!G J!P Ì J à[QTS J Î�E!\^G°U§] J�LxJ ])ÊdÌ:EG°Î J \^Q L U§EFGNäq@0U L G·Ê P Q�Y L E!Ó[Q�ÓIU§ÔµUµÊdá J � O Q!ÔÊ°Ek3Iä ?Ê°E)Y JNL ÉÍE L X Q�ê Ï:W+P G°E)Q�Y L E!Ó^Q!ÓIUµÔ§UµÊdá J � O Q�Ô[Ê°E�3Iä ��ÊxEÊ L QTS J Ô[Ê°à L E O^M àÊ°à J \ J ÊwäRÈ J Î(EF\^] P Êxà J E!Y^Y[ERG·UµÊ J G°U�Ê O Q�ÊxUµEF\ P QY L E!Ó[Q�ÓIU§ÔµUµÊdá J � O Q�Ô´ÊxE�3Iä ��ÊxE�Y JNL âÉÍE L X Qºê Ï:W+P Ê°à J�LxJ ÉÍE LxJ Q6Y L E!Ó[Q�ÓIU§ÔµUµÊdá J � O Q!Ô»ÊxEG3^ä ?6Ê°E³Ê L QTS J Ô7Êxà L E OIM à Ê°à J\ J ÊNä
2´ä�å7E5Ê J G·Ê�Êxà J 0Vú�õ��;�xõ)Bø/õ�ðZõ�ø^ù��°õ+·�0^õ(ú�ù P Ì J à^QTS J Î(EF\^G·Ul] JNL°J ]6ÊdÌ:E5]´Uvu JNL°J \RÊ8Y[ERG°G°UµâÓIU§ÔµUµÊ°U J GNä ÿ \äz J�� Y J�L Ê O G J�L+|�LxJ � OIJ GdÊxUµ\ M Q�X J Q!\6E�É�ü�3 LxJ �^\ J X J \RÊxG P Q�\^]5Q�z·\^Q!UµS JO G J�L+|�LxJ � OIJ GdÊxUµ\ M Q)X J Q!\ºE!É�ý13 LxJ �[\ J X J \RÊyG�ä
?Iä ��9Iõ8ú�ó � õñ��ù:9^õ �xö�ù}ö�ôµñx÷EFÓ´ÊxQ!Uµ\ J ]�ÓRáÊ°à J ì L E�Ì�G JNL ÎNQ�\ZQ�ÔlG·E�] J Î LxJ QFG J Ê°à J G°á´GdÊ J XY JNL ÉÍE L X¼Q!\^Î J ä�� J à^QTS J�O G J ]F�[S J ]´U²u J�LxJ \RÊ�G·U�� J G+ÉÍE L Ê°à J Î�Q�ÊxQ!ÔµE M Ç0ü>nÓVáRÊ JFP 2FýnÓVáFÊ J G P ý 3�nÓVáRÊ J G P ��ýLnÓVáRÊ J G�Q!\^]îü�3q3LnÓVáRÊ J G�ä
H^ä ��9Iõú>�^õyõ�*Zñ�+ù�9Iõ�ø�õ(ùBU§G©S JNL á�UµXZY/E L ÊxQ�\RÊ©Ê°EUl] J \FÊxU�ÉÍá¼Ó/E�Ê°Ê°Ô J \ J Îyã´G�äq� J à^QTS J Î(E!\IâG·Ul] JNL°J ]6ÊdÌ:E5Î�QFG J G�ÇIQZ\ J Ê8Ì�UµÊ°àAQ¼G°Y JNJ ]�E�É;ü�3q3�nÓRáRÊ J G�æ�G J Î�ä-é#zdÉ�QFGdÊ | Î�E!\I\ J Î�ÊxUµEF\G·Y J�J ]^í;Q�\[]6Q)\ J Ê�Ì�UµÊ°à�QZG·Y J�J ]6E!É©ü�3>nÓVáRÊ J G�æ�G J Î!ä/é#z°G°ÔµE�Ì | Î(EF\I\ J Î(Ê°U§E!\ºG·Y J�J ]^í�ä@»U M!O^L°J ü��^éuQFí�G°àIE�Ì�GG°á´GdÊ J X L°J G·Y/E!\[G J ÊxUµX J éÍU§\ XZUµ\ O Ê J Gyí P ÉÍE L Ê°à J \ J Ê)Uµ\�@»U M â
OIL°J ü�? P G O YIY[ERG·U§\ M zdÉ�Q!G·Ê | Î(E!\^\ J Î(Ê°U§E!\ G°Y JNJ ] P z J#� Y J�L Ê O G J�L+| Q!\^] Q�\ z°Uµ\RÊ J Ô§ÔµU M!J \FÊ |ì L E�Ì�G J�L äS5+\ J E!É+Êxà J ÔµU§\ J G L°J Y L°J G J \RÊxGZQîY L EFÓ^Q�Ó^UµÔ§U�Êdá J � O Q�Ô;ÊxEã3Iä �AÊxEîÊ L QTS J Ô�Q!\^]3Iä ?)Ê°E5Y J�L ÉÍE L X Q5ê Ï:W+P Êxà J E!Ê°à JNL ÔµU§\ J�LxJ Y L°J G J \FÊyG;Ê°à J E!YIY/EFG°UµÊ J G°U�Ê O Q�ÊxUµEF\-äÔ� J Î�Q!\E!Ó^G J�L S J Ê°à^Q�Ê�Ê°à J�LxJ Q L°J G°X¼Q�Ô§Ô-]´Uvu JNL°J \^Î J G�Ó J ÊdÌ JNJ \ºÊ°à J ê Ï:W Q�\^]³Ê L QTS J Ô¡GdÊ L Q�Ê JNM U J GNäÈ O ÎyàèQ³]´Uvu J�LxJ \^Î J UlG�] OIJ Ê°E³Ê°à J)L E O \^]AÊ L U§YpE!É�Ê°à J Q M!J \FÊwä ÿ G+Ê°à J Q M!J \RÊ�G·U�� J ]´E J G\IE�Ê5Îyà^Q!\ M!JFP ÊxàIU§G¼]IU²u J�LxJ \^Î J UlG)\IE�Ê LxJ Ô J S�Q�\RÊ)ÉÍE L Ê°à J³M ÔµEFÓ^Q�Ô�G°áVG·Ê J X>Y JNL ÉÍE L X¼Q!\^Î J äå;à O G P Ì J G°àIE�̶Êxà^Q�Ê�Êxà JO G J E!É»XZE!Ó^UµÔ J Q M!J \RÊxGBÉÍE L Ê°à^U§G:ÊyQ!G°ã6]´E J G:\IE!Ê�] J Î LxJ QFG J Ê°à JY JNL ÉÍE L X¼Q�\[Î J ä
17
opq rs tu vw xy z
{ | } ~ � | � ~
�� � �� ��� � � � � � � � � �� � � � � �� � � � � � � � ¡¢ £ ¤ ¥ ¦ §¨ © ª « ¬ ® ¯ ° ± ² ³ ´ ® ¯ µ ¶ · ¸ ¹ º » » ¼ ½ ¾ ¿ À Á Â Ã Ä Å Ä Æ Ä Ç È É Ê Ë Ì Í È Î Ï Ð Ï Ï Ï ÑÒ Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ Ø Ù ß à á â ã á à á ä å æ ç è ç é ê ë ì ê í î ï ð ñ ò ó ô õ ö ÷ ø ù ú ú û ü
ý þ ÿ � � � � � � � � � � � � � � � � � � � � � � � �� � � � �
�
!"
#$
%&'(
) *
+ , - . / , 0 .
12 345 67
8 9 : ; < = > ? @ AB C D E F G
H I J K L M N O P QR S T U V W
X Y Z [ \ ] ^ _ ` a b c d ^ _ e f g h i j k f l m n l o l p q r s t u u u v w x y z v y { | } ~ ~ �� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ¡ ¢ £ ¤ ¥ ¦ § ¨
© ª « ¬ ® ¯ ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ À Á Â Ã Ä Å ÅÆ Ç È É ÊËÌ
Í ÎÏ Ð
Ñ ÒÓ ÔÕ Ö× Ø
Ù Ú
Û Ü Ý Þ ß Ü à Þ
áâ ãäå æ
ç
è é ê ë ì í î ï ð ñò ó ô õ ö ÷
ø ù ú û ü ý þ ÿ � �� � � � � �
� � � � � � � � � � � � � � � � � � � � � � � � � � � ! " # $ ! % & ' ( ) * + , - . / 0 12 3 4 5 6 7 8 9 : ; < = > 8 9 ? @ A B C D C C E E F G H E I J K L M N J O P Q R S P Q P T U V W X T
Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u uv w x y z
{|
}~
��
��
� � � � � � � �
�� ��� ��
� � � � � � � � � �� � � � � �
¡ ¢ £ ¤ ¥ ¦ § ¨ ©ª « ¬ ® ¯
° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ¶ · ½ ¾ ¿ À Á Â Ã Ã Ã Ä Å Æ Ç È É Ê É Ë Ì Í Î Ï Ð Î Ñ Ò Ó Ô Ô Õ Ö Ò Ô × Ø Ù × Ú Û Ü ÝÞ ß à á â ã ä å æ ç è é ê ä å ë ì í î ï î ð ð ñ ò ó ô õ õ ò ô ö ÷ ø ù ú ú ù û ü ý þ ÿ � � � ý � � � � � � �
� � � � � � � � � � � � � � � � � � � � ! " # $ % & ' '( ) * + ,
-/.10 24365
7/819 :/;=<
¤`¥�¦ ¦�§E^¦ � gy|�a´cNiR|�g©bdrtn�g�klc�m q f!r?>Ig°mdgyi�b�|�sygyi q mdrtcw|�¨�r�bd® q iA@jrti�bdgyªtªtr�vNgyi�b`ÿ»mdc�¨�|�gxmCB!eED qGF0q iRfDˬ F mdgyaFmdgy|�gxi�b q @uk q |}bCB8sycwiFiRgys°bdr�cNi�|�a´gyg�fI~HDËs F¡q iRfIDÍf F¡q @j|�ªtc�¨JB8sycwiFiRgysxbdrtcNi�|�a´gyg�fLK6D qMF-q iRfDËs F�q iN@ugPO!a´gxm�bB«R|�gxmCB q iVfQDˬ F�q iRfRDÍf F�q @ji q rt�Tg�«R|�g°mCBFe
@»U M!O^L°J ü��[éÍÓ[í:G°àIE�Ì�G;G·á´G·Ê J X LxJ G°Y[EF\^G J Ê°U§X J éÍU§\�X)U§\ O Ê J Gxí P G O YIY/EFG°Uµ\ M z·É�Q!G·Ê�Î(E!\Iâ\ J Î(Ê°U§E!\ |^P z°Uµ\RÊ J ÔµÔ§U M!J \RÊ | ì L E�Ì�G J�LwP z·\[Q�U§S J�O G J�L+| ä/å;à J Ô§U§\ J G+à^QTS J U§] J \RÊ°UlÎ�Q�Ô�X J Q!\IU§\ MÊ°à^Q!\ºU§\~@0U MFOIL°J ü��^é�QRí�ä´å;à J ÊdÌ:E¼G·EFÔ O ÊxUµEF\^G�G·Ê°U§ÔµÔ LxJ X¼Q!Uµ\ºU§] J \RÊ°UlÎ�Q!ÔuäÈVE!X J EF\ J Î�E O Ôl] G O G·Y J Î(Ê8Êxà^Q�Ê+Ê°à JNL°J�J�� U§G·Ê�G°X¼Q�Ô§Ô»]´Uvu J�LxJ \^Î J G+Ó J Î�Q O G J E!É�Ê°à J \ J Ê
G·Y J�J ]¡ä�È´E P Ì J à^QTS J ] J Î LxJ QFG J ]pÊ°à J \ J ÊZG·Y J�J ]èÊ°E=ü�3 nÓRáRÊ J G�æ�G J Î�ä P é�@»U M!O^L°J G5ü��[é�ÎwíQ�\^]pü��[é�]^í°í�äIß}Ê8ÎNQ�\ºÓ J G J�J \ºà^E�̽ʰà J ]´U²u J�LxJ \[Î J G�G·Ê°U§Ô§Ô L°J X¼Q�U§\³\IEF\ºG°U M \IUv�[Î�Q!\RÊNä
@»U§\^Q!ÔµÔ§á P @0U MFOIL°J ü�� L°J Y L°J G J \RÊxGBQ�Ê J GdÊ:ÉÍE L Q�\�z·U§\FÊ J Ô§ÔµU M!J \RÊ:ì L E�Ì�G J�L+|IP Q�\8z J�� Y JNL Ê |O G JNLNP QpY L EFÓ^Q�Ó^UµÔ§U�ÊdápÉÍE L ê Ï;W J � O Q!ÔBÊxEm3^ä � Q�\^] J � O Q�Ô:Ê°Em3Iä ?AÊxEÒÊ L QTS J Ôjä'D�E�Ì P Ì Jà^QTS J Ê J G·Ê J ] Êxà J G°á´GdÊ J X ÉÍE L Q ]´Uvu J�LxJ \RÊ6\ O XÓ J�L E�É L°J � OIJ G·ÊxG L Q�\ M U§\ M É L EFX ü�ÊxEH P Êxà O G�Êxà J Î�E!Ô§E OILxJ ]ºXZE´] J Ô0U§\�@0U MFOIL°J ü"��à^QFG�Ó J�J \ O G J ]¡ä65+Ó^G JNL S J Ê°à^Q�Ê+Ì�à J \AÊ°à J\ O XÓ J�L E�É L°J � O^J G·ÊxG»U§G�U§\^Î LxJ QFG J ] P Ê°à J;LxJ G°Y[EF\^G J Ê°U§X J ÉÍE L�J Q!Îyà L°J � OIJ G·Ê0U§\^Î L°J Q!G J G P Ujä J ä PÊxQ!G°ã´G�Î�Q!\I\IE�Ê J#�´J Î O Ê J Î(EFXZYIÔ J Ê J ÔµápUµ\èY^Q L Q!ÔµÔ J Ôjä ÿ ﵃ L°J ] Q�\^]pÊxà J ÈVE�ÉËÊdÌ;Q LxJ¼K Q�\[Q M!JNLQ LxJ \IE!ÊZ] O YIÔµUlÎ�Q�Ê J ] Ì�UµÊ°à=G°U§X O ÔµÊxQ!\ J E O G LxJ � OIJ GdÊyG�ä�å;à O G P Êxà J á Q L°J Ê°à J Ó[E!Ê·ÊxÔ J \ J ÎyãÉÍE L Êxà J ] J G°U M \ J ] G°á´GdÊ J X Ì�U�Êxà L°J G·Y J Î(Ê�Ê°EÒÊ°à J \ O XÓ J�L E�É�Î(EF\^Î OILxLxJ \RÊ L°J � OIJ G·ÊxGE�ÉÊ°à J G J�L SVU§Î J ä¡å;à J�LxJ ÉÍE L°JFP Ê°à J \ J#� Ê�G·Ê J YèUµ\pÊ°à J Y J�L ÉÍE L X¼Q�\^Î J Q!\^Q�Ô§á´G·UlG�E�É©Ê°à J XZE´] J ÔÌ©E O Ô§]�Ó J ÊxE6Î(EF\^G·Ul] JNL G J S JNL Q!Ô-X¼Q�ïdE L ]´EFX)ERGéÍÌ J ]´E5\IE!Ê8U§\^Î(Ô O ] J à J�LxJ ] OIJ Ê°E6G°Y^Q!Î JÔµU§XZU�ÊyQ�Ê°U§E!\[Gxí(ä
18
STU VWX YZ [\ ]^ _` a
bc def gh
i j k l m no p q r s t u vw x x y z { | } ~
� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ « ® ¯ ° ± ² ³ ´ µ ± ¶ · ¸ ¹ ¹ º · º » º ¼ ¼ ½ ¾ ¿ À Á Â ¿Ã Ä Ä Å Æ Ç È É Ê Ë Ì Í Ë Î Ï Ð Ë Ñ Ò Ó Ô Õ Ö × Ø Ù Ö Ú Û Ü Ý Þ Ý Ú ß à á â á ã ã ä å à
æ ç è é ê è ë ì í î ï ð ñ ï ò ó ô õ ö ÷ ø ö ù ú û ü ý þ ÿ ý � �
¤`¥�¦ ¦�§G^¦ � gy|�a´cwiF|�g�bdrtn�g�klc�m q i @ur�i�bdgyªtªtrtvwgyi�btÿ»mdc�¨�|�gxmCBF~ q i @jgPO!a´gxm�b�«F|�gxmCBF~ q @uk q |}bCB¼sycNiF²iFgysxbdrtcwi q iVf q ªt|�c�fFr >Igxmdgxi�b�i�«Fn�¬´gxm�c�k�mdg�±�«Rgx|}b�e
� lpÚ©×8ÝOV·Ü�nVÞdÚB×�nãP�×8Û _�Ü�Ù´Ø[ZgL-ÙÐaîÚ�Ù��å;à J X¼Q�U§\ M EFQ!ÔIE�É/Ê°à^U§GBY^Q�Y J�L Ì;Q!G�Ê°E�Y LxJ G J \RÊBQ�\5Q!YIY L E � UµX¼Q�ÊxUµEF\�ÊxE J S�Q�Ô O Q�Ê J Y J�L ÉÍE L âXZQ!\^Î J U§\º] J G°U M \6XZE!ÓIU§Ô J Q M!J \FÊ�G°E�ÉËÊdÌ;Q LxJ ä}� J à^QTS J+O G J ]ºQ!G©Ê J G·Ê�QZG°á´GdÊ J X ] J G·U M \ J ]ÉÍE L Y L E�SVUl]´Uµ\ M X)EFÓIU§Ô J Î�E!XZY O Ê J�L+O G JNL G�Ì�U�ÊxàÒQ5G°E�ÉËÊdÌ;Q LxJ�LxJ Ê L U J S�Q!Ô7G JNL SVUlÎ J äÔ� J G O X�âXZQ L UlG J Êxà J Î(EF\RÊ L UµÓ O Ê°U§E!\^G:U§\³Êxà J ÉÍE!Ô§Ô§E�Ì�Uµ\ M UµÊ J XZGNÇy ÿ XZE´] J Ô!Ê°E J S�Q!Ô O Q�Ê J G°E�ÉËÊdÌ;Q LxJ Y JNL ÉÍE L X¼Q�\[Î J à^Q!G-Ó JNJ \�U§\FÊ J�MFL Q�Ê J ]+U§\Ê°à J G°E�ÉËÊdÌ;Q LxJÔµUµÉ J Î(á´Î(Ô J ä�ß}Ê�à^QFG0Ó JNJ \Z]´E!\ J U§\Êxà J;J Q L Ô§á�GdÊyQ M!J G7E!É^Êxà J X)E´] J ÔµÔ§U§\ M Y L E´Î J GxG�äTå;à O G PÌ�à J \ZY J�L ÉÍE L X¼Q�\^Î J E L É O \^Î�ÊxUµEF\^Q�Ô LxJ � O U LxJ X J \RÊxG�Îyà^Q!\ M!JFP U�Ê�Ì�U§ÔµÔ^Ó J�J Q!G°á�Q�\^]�Ô J G°GJ�� Y J \^G°UµS J Ê°E�QFG°G O X J Ê°à J X�ä K E L°J E�S J�LwP Ê°à J Q!YIY L EFQFÎyàÌ�U§ÔµÔ[Y JNL XZUµÊ�Ê°E�EFÓ´ÊxQ!Uµ\)Ê°à JY JNL ÉÍE L X¼Q!\^Î J � M!OILxJ G»U§\)Q!\�Q O Ê°E!X¼Q�Ê°UlÎ�Ì;QTá/Ç�ÈRÊyQ L Ê°U§\ M É L E!X Êxà J Y^Q�â Ð8K Ñ XZE´] J ÔlG PÊ°à J Î(EFX)Y/E!\ J \RÊ Ï�J Ê L U©\ J ÊyGQ L°J G°á´GdÊ J X¼Q�ÊxU§ÎNQ�Ô§ÔµáîQ!ÎyàIU J S J ] P Q�\^]îÉ L E!X%Ê°à J G J Ê°à J\ J Ê8G°á´GdÊ J X P �^\[Q�Ô§Ôµá¼Êxà J \ J Ê8G·á´G·Ê J X Q�Ô§ÔµE�Ì�G:Y J�L ÉÍE L XZQ!\^Î JJ STQ!Ô O Q�Ê°U§E!\7ä
y ß�\ÒE L ] JNL ÊxE³Q!YIYIÔ§á Q�\VáºÊ J Îyà^\IU�� OIJ Ê°E�Q�\[Q�Ô§áVG J�L U M E L E O G°Ô§á³G°áVG·Ê J X Y JNL ÉÍE L X¼Q!\^Î JFPÊ°à JZO G J E�É:Q5ÉÍE L X¼Q�Ô�XZEV] J Ô�UlG�Î L°O Î(UlQ�Ôjä¡È´E P Ì J à^QTS JO G J ] Ï�J Ê L U�\ J ÊyG+Ê°E�] J G°U M \G·E!ÉËÊdÌ:Q L°JFP QTS!E!Ul]´U§\ M Ê°à J�Ð+K Ñ Q�X�ÓIU MFO UµÊdá!ä
y W E!\^Î OILxL°J \^Î(áèUlG�Q!XÓIU M!O E O G°Ôµá J�� Y LxJ GxG J ] U§\ Ð+K Ñ�P Ó O ʼÌ�à J \ Êxà J Ê L Q!\^G°Ô§Q�Ê°U§E!\Ê°E Ï�J Ê L U�\ J ÊxG5UlG5Y J�L ÉÍE L X J ] P Q Î(EF\^Î O^L°LxJ \RÊ¼Ì J ÔµÔµâ�] J �^\ J ] XZE´] J Ô+U§G M Q�U§\ J ] P G°E]´Uvu JNL°J \FÊ�ãVU§\^]IG;E!É�Î�E!\^Î OIL°LxJ \RÊ�G·á´G·Ê J XZG�ÎNQ�\�Ó J Q�\^Q!Ôµá´G J ]¡ä
y å;à J X)E´] J ÔµÔ J ] J�� Q!X)Y^Ô J Y LxJ G J \RÊxG:Q�Î�E!XZYIÔ J�� G°áVG·Ê J X Ì�àIUlÎyà6UlG J#� Y J \^G·U§S J Ê°E)U§X�âYIÔ J X J \RÊNäQ5 OIL Q!YIY L EFQ!Îyà=E u J�L G5Q�\¶Q!\^Q�Ô§áRÊ°UlÎ�Ì:QTá E!É J S�Q�Ô O Q�ÊxUµ\ M G O Îyà ãVUµ\[] E�ÉG·á´G·Ê J XZG+Ì�UµÊ°àIE O Ê�à[QTSRU§\ M Ê°E6U§XZYIÔ J X J \RÊ�G J S JNL Q!Ô-Y L E�Ê°E!ÊdáVY J G�ä�å;à J)L°J G O ÔµÊxG�Î(EFUµ\IâÎ(Ul] J Ì�U�Êxà�Ê°à^EFG J EFÓ´ÊxQ!Uµ\ J ]�ÓVáÊ°à J ÿ D+å ÿ ê W å;ß W ÿ ] J G°U M \ J�L G�äwå;à J U L�L°J G O Ô�ÊyG7Ì J�LxJE!Ó´ÊyQ�U§\ J ]³Ì�UµÊ°àAU§X)Y^Ô J X J \RÊ J ]ºY L E�ÊxE�ÊdáVY J GNä
W E!\^Î J�L \IUµ\ M É O Ê OILxJ Ì©E L ã P Ì J Q L°J U§\FÊ J�LxJ G·Ê J ]³U§\ºÊ°à J ÉÍEFÔµÔ§E�Ì�U§\ M EFÓ´ï J Î(Ê°U§S J G�Çy ÈVE�ÉËÊdÌ;Q LxJ ] J G·U M \ U§G�Q Î�E!XZYIÔ J�� ÊxQFG·ã�ä;ÈVE P Ì J Q!]IS!E´Î�Q�Ê J ÉÍE L Êxà JpLxJ�O G J E!É�Ê°à JãV\IE�Ì�Ô J ] M!J Q!Î�� O U LxJ ]³U§\6Êxà J Q�YIY^ÔµUlÎ�Q�Ê°U§E!\�]´E!X¼Q�U§\-ä´ß�\³Ê°àIUlG�Ì;QTá P Y^Q�Ê·Ê JNL \[G;Ì�UµÔ§Ô-Ó JUµ\RÊ L E´] O Î J ] Ê°Eè] J G°U M \=G°E�ÉËÊdÌ;Q LxJ6O G°U§\ M Q M!J \FÊyG�ä�_BQFÎyà ] J G·U M \=Y^Q�Ê°Ê J�L \ Ì�U§Ô§Ô;] J Q�ÔÌ�U�Êxà UµÊxG�E�Ì�\ Y JNL ÉÍE L X¼Q!\^Î J G°ãVUµÔ§ÔlG�ä�ÈVE P Ì J Ì�UµÔ§Ô:à^QTS J Q Y^Q�Ê°Ê J�L \ ] J G·U M \ Ô§U§Ó L Q L áÌ�U�ÊxàºÊ°à J Y L E!Y J�L�O G J E�É0Ê°à J Y JNL ÉÍE L X¼Q�\[Î J Y^Q L Q�X J Ê J�L G�ä
y ÿ GÌ J à[QTS J G°Q!U§] P»Ð8KÒÑ G J X¼Q�\RÊ°UlÎ�G�UlG�\^E�Ê] J �^\ J ] ÉÍE L XZQ!ÔµÔ§á P G·EAE OIL Q�Y^Y L ERQ!ÎyàÓ L Uµ\ M G8QZÉÍE L X¼Q!Ô»G J X¼Q�\RÊ°UlÎ�G8Ó^Q!G J ] E!\ Ï�J Ê L U»\ J ÊyG�ÊxE5XZE´] J Իʰà J G·á´G·Ê J Xºä/ß�\AÊxàIU§GQ L Ê°UlÎ(Ô J!P Ì J à^QTS J Y L EFY[ERG J ] L°O Ô J GÊxEèE!Ó´ÊyQ�U§\ Ê°à J�Ï�J Ê L U;\ J ÊyG�äS� J Ì�UµÔ§Ô�Ì©E L ãèU§\Ê°àIUlG:ÔµU§\ J Ê°E M!J Ê;Q�ÉÍE L X¼Q�Ô^Ê L Q�\^G°ÔlQ�Ê°U§E!\5É L EFX Êxà J Y[Q�â Ð8K Ñ \IE�ÊyQ�Ê°U§E!\5Ê°E Ï�J Ê L U[\ J ÊxGG J X¼Q�\RÊ°UlÎ�GNä
19
bÐL�_�L7Ù[L7×8Ý�L'n���� û³e#�6�}n�cwiFg'û q md| q i^~�+e�ÿ q ª�¬´c!~ q iVf�+e�$0cNi�bdgw~� �������������������� ��!"�#� $�%&�"'(��)*�+�-,.����)/$0�213��)/!-$
� ��)/�4���&!3)5,6�27.��!5����!-89�&� �-�:��;&��� <6�&)/$0���=�>�38?<@� )/$ 7A!��+�-���-����!B�-C&��)D��8?�d~q�Y$Sû ¯[m q iR| q sxbdrtcwiR|cNi-$0cwn�aF«Fbdgxm©{��F|}bdgxn�| ¸ D � ����E F ~RiRc!e F�~I��GIH � F#F�e
� F � +e1ÿ0c�c�s·®[~�h·e@J q sxcw¬R|�cNi[~ q iRfKJFe � «Fn�¬ q «RvN®[~�L2MONQP��6$ RS�"'TMU�+'��� $V���XWY������<6�����X�07.�"��Z$ R2����)/$0���F~AJw«FiRg � ������~´�Tgxmd|�rtcNi � e G�e
� G � +e1$0®Frtcwª q ~}$©e�`;«!bd®Rgyrtªtªtgxb�~@+e\[Fm q iRsygx|�s°®Fr�iFrt|y~ q iVf�{´e�] q fRf q f^~6^6)*�+�-,.����)/$0�X_`��V��Z ����!-8K�"'���#����<\!"��'a� ��)/������!T��C�8:8K��)/!-$0�989�+'���V� $5�\�a��7b7A� $0����)/$0���.�·~^h>c2cdc ¯[m q iF| q sxbdrtcwiF|�cwi/$0cwn²aF«Fbdgxmd| õ[¸ D � ����G F ~´iFcFe �#� ~ � G&EbG+H � G� ���e
� E � +e"$0®Rrtcwª q ~@+eb[!m q iRsxgy|�s°®FrtiRrt|y~ � e# q gxb q ~ q iVf;û³e � rt¬ q «Vf!cF~eNS!"���&)/^\12fhgbiVj#kYN2lm�-7.,\$0���#�nm'�$V)*��!o�&� '3 o� �#� C�%I��!�����!Xp4$58K�"'X��� '(^.)*�+�-,.����)/$0��1o��)/!�$ f���)/�·~���gxm�k§cNmdn q iRsyg�c-� q ªt« q bdr�cNi¸qõ D � ���#q F ~AE"!+H� ��!e
� q � JFeT`;rtª�ªtgx��~ � eb[Fmdrtg�f!mdrts·®[~�¯:e�Jwrti[~ q iVf9JFe � cwªtr q ~`r=��sB���!-;���!`7.��!5����!-89���A���B89���&�-<\!"��8K���6)���A'K8t�+'��� $V���9)D�"�-,\�.$0u<6���·~A��gxm�klc�mdn q iRsxg:c-� q ªt« q bdr�cNi D � ����� F ~ViRc!eAG�G!~ q+H@F# !e
� � `�eA$0cwªtgyn q i¼gxb£�©ªËet~SLmsVvI�"�)m��!-$*���.)D��'w'���;������7A89���6)Did)5,6�Bx�<\�-$/���U89��)5,.�+'N~^¹:¬ �}gxsxb�¹©mdr�²gyi�bdg�fI~q�-mdgyi�bdrtsygX] q ªtªË~ � ����E!e
� ! � JFe � «Rn�¬ q «Fvw®gxbY�©ªËet~`LmsVv+���)S��!-$*���6)D�"'y8t�+'��� $V���y���A'z'b���-$����R~A�¡mdgyi�bdrtsygx²*] q ªtªÍ~ � ��� � e� � � c�e q n�n q ~ � e6]©gyªtnZ~ � e6Jwcw®FiR|�cwi^~ q iVfaJ!e6{©ª�rt|�|�r�fFgx|y~�|:����$}���w1m��)/)D��!-�6�k4n��}��8K���6)/�X���
!"��<@���bs��}�:�bsVvI�"�)0Z>�&!�$*���.)D�"'w��>��)/_2��!��°~I�:fRf!rt|�cwiF²0~ºgy|�ªtgx��~ � ���#q�e� � � $©e#] q m�mdrt|�cNi[~N`�e�$0®Fgy|�|y~ q iVf ��e&��gxmd|�®Rgyi�¬ q «RnZ~bMU�#s$/�}�o�������6)/�kY��!"�o)5,6��C:�B�b�+�+'�$0'��"�e�d~
û)cN¬Rrtªtg�¹:¬ �}gxsxb:{��!|}bdgyn�|��!¯/c�¨ q m·fF|�bd®RgQ�¡mdcwv�m q n�n q ¬Rªtg�hji�bdgxmdiFgxb�~ � ����!�~´aFa[e@E" +H�E��!e��� � � h·ebJ q sycw¬F|�cwi^~1û³e�$0®!mdrt|}bdgyiR|�cNi[~���e#Jw®RcNiR|�|�cNi[~ q iVf9+e�¹:�Tgxmdv qwq m·fI~�L�sVvI�"�)0Z>��!-$*���.)D��'?�����-)0Z
_2��!"�?���\��$5�e����!�$5�\��k4 �<@��T�-�&���:'�!�$5;������-7b7A!"�+�#�-,�~[�:fFfFrt|�cwi!²0~�gy|�ªtgx��~ � ���bF�e������ c�eY��c(� q sy|y~��e �T�cw®Fmdªtgw~ q iRf°û³e � gxr�s·®[~4MU�#s$/�}�9�+�����6)/�aL`�4p�,6��MU�&;��yZ0$V�6)D�0��!"�&)/$V�\���&�
�+�����.)���C���)D��8�$V�.)*�z)5,6�:8t�bs$/�}��8:$0'b'@�}��_`�&!��°~[�Bsxbd|Qû)cN¬Rrtªtg{�«Rn�n�r�b D � ®Fc�fFcN|y~�©mdgysyg F ~Jw«FiRg � ������e
��� F � c�e�û)gyi q ~6��e�hjªtª q m�m q n�gyiVf!rË~ q iRf~�8e�:cA�iRrË~���<\��)*��8?$}%+�bs��}�K��>��)/_2��!��z!"��)/!�$*��;&������b�$/� $V)/C���&!?89�#s$/�}�9�-�&8B7A<\)D��!-�t<\�-$5�\�=�+�����6)/�d~��-mdc�sygxg�fFrtiRvN|�cNk�bd®Fg;!(bd®6hji�bdgxmdi q bdrtcwi q ª'$0cwi!klgxm�²gyiFsyg7cwi�� q m q ªtªtgyª q iRf�`;rt|}b�mdr�¬F«Fbdg�f8{��F|}bdgxn�| DËhà$f�Ô�B`�{e� F#����� F ~+~�c�md¸!|�®Fcwa�hji�bdgxmdi q bdrtcwi q ª[�ªtgPO!rt¬Rªtg �©gxbj¨0cNmd¸�rtiRv q iVf�$0c�cNa´gxm q bdrt�Tg�`;rt|}b�mdrt¬R«!bdg�f-�©vNgyi�bd| D0[��Q$0`£�T� F������ F DËhu¨ q bdgD0J q a q i F F ~Fh�cdc2cm$0cwn�aR«!bdgxm©{!c�sxr�g°bj��~6Jw«Rª��wF������!e
��� G � ¯:eªû)«!m q b q ~�1o��)/!-$��e��)/�k41S!"��7.��!-)/$*�����3��� �#� C&��$V���m���A'a��7b7 � $/�-�&)/$0���6�d~Ô�¡mdc�sygyg�f!rtiRvw|�c�k»bd®Fgh>c2cdc ��� D � ����� F ~ViFcFe.EF~ q&E � H@q#���!e
��� E � ¹:¬ �}gys°b=û q i q vwgyn�gyi�bB©mdcw«Fa[~`p�,6�:����8:89���U�bsVvI�"�)S!"�"u<A����)os!��I�b��!+k4 o!"�-,\$V)D�"�)/<\!��t�&� '�07.�"�$ R`����)/$/���R~eJN«RiRg � �����!~ � gy��rt|�rtcwi�F�e G�e
��� q � c�e"�-r�bdcw«!m q�q iVf?+e�{ q n q m q |y~�|T��)*�X89���A�+����8K���.)@����!S8t�bs$/�}�o�-�&8B7A<\)/$V���N~b��ªt«�¨�gxm��Bs q ²f!gyn�rtsQ�7«F¬Rªtrt|�®Rgxmd|y~ � �����!e
��� � � e1��c�cwªtgx� q iVfÖ�¡e\��rtiFvF~�p�,6�B<\�6$ R`�"'?89�+'��� $V���t�����\��<.�+������� 'B7.��!5����!-89�&� �-�:������$V�e����!�Z$V���N~Rh>c2c{�-mdc�sxgyg�fFrtiFvw|:{!cNkµbj¨ q mdgw~Rh�cdc�~Iû q mds·® � ������e��� ! � �8e � rtsyc q iVf�+e {8efÿ0c�s·®Rn q i[~`1o��!V���&!�8t��� �-�U'b����!-$ 7A)/$/������� '����A�#� C&�-$5�X����!='�$V��)/!�$/s�Z<\)D�"'w��C���)D��8?�T<\��$V�\�a�z;&�&!�$0�&�6)3���(W�LXpSLS^F~ � �(bd®6hui�bdgxmdi q bdr�cNi q ª¡h�[�hà�è{��!n�a´cw|�rt«Rn cNi�¡mdcNbdc�sycNª-{!a´gxsyr��Vs q bdr�cNi[~R¯/gy|}bdrtiRv q ia{ q ªtr�f q bdr�cNi[~AJw«Rª�� � �����!e��� � � $©e��8e�{�n�rtbd®^~\1o��!V���!�8t��� �-�X������$V�e����!-$V�\�9���m��>��)/_2��!��B��C���)D��8:�·~F¯�®Fg:{�gyrI{�gxmdrtgy|0rti{!c�k§b�²¨ q mdgTc7iFvwrtiRgxgxmdrtiRvF~I�:fFfFrt|�|�cwi\Hb~�gx|�ª�g°��~ � �����!e
��� � � +ee~ q bdgxmd|y~ª��e������6���6�&���#�����:�Ô�3�b���\�@�� ��+��¡��A¢��T��£�¤@¥9�� ��S�d��8:8?<\�6$0����)/$/���6�T������)/_2��!��7.��!5����!-89���A�-��7A!"�"'�$0�)/$0���.� � G&���y¦B�§~¨�����\ "�.�#©K�#�zª4��"«V�&��¥K¡��.¬��(c��6���}�.��������6�:��«4`�#¥t®©.�.����� :¡��6¢�¯Y��°���¬���¥9¥?�6�.��¬+¡&�����#�±£�¤@ �����¥9 D/²>°��\°}��¤ F �4�(��¥9��"���� ��X���6³�¡&�� "�# ?c2¢e����J#�6°�¤��´#´bµ � ©6©��.G#¶b· � H�G#¶b· ´ �
� F&¸ � ûU��~¨���\¢. "�}¢@�#�@3�b]o���� "¬��\�6¬-� �"ÿo�\£@�°}��¬#�b¡��6¢9£e�"ÿS¡�¤\¡&���I³ �@ �_�$0'��os-�&� 't��7#7A!"�+�b�-,y)*��$V�AZ)D�0��!"�&)/$V�\�X7.��!V���&!�8t��� �-�m76!��"'�$0�)/$0�&�¹$5�6)*�9�t������)/_2��!���'�����$}���U���.;+$V!"���.8K���.)/�Aª�����¬����+¢@���6�# �&«4���6� � ��3²D��������A¡I���}���A¡&°�~������\ "�6��©w�#�=£@��«º�>»S¡&����ª4��"«5����¥K¡��.¬�� DV~�¼X£@ªm� ´ ¶ F � �+´#´ ¶@�
20
Testing Petri Nets for Mobile Robots Using Gröbner Bases
Angie Chandler1, Anne Heyworth2, Lynne Blair1, Derek Seward3.1 Lancaster University, Department of Computing
2 University of Wales, Bangor, Department of Mathematics3 Lancaster University, Department of Engineering
Abstract
As autonomous mobile robots grow increasingly complex, the need for a method of modeling andtesting their control systems becomes greater. This paper discusses the use of Petri nets as a means ofmodeling and testing the control of a mobile robot, concentrating specifically on the reachability testingof the Petri net model through the use of Gröbner bases.
The designing and testing of the Petri net models for the mobile robot is done initially in componentform, providing a model which is then automatically converted into a Gröbner basis to provide a simplemeans of reachability testing. Once the testing process is complete, the Petri net modules, whichrepresent each of the components of the mobile robot are connected to form a single Petri net. ThisPetri net is then used for the generation of control code for the robot.
In this paper, the process of testing the modules created to represent the components of theautonomous mobile robot is shown through a case study, Star Track (a tracked autonomous mobilerobot). Details of both ordinary and colored Petri nets representing certain components of Star Trackare discussed, with both the Petri net model and the equivalent Gröbner basis described.
1 Introduction
The dynamic and asynchronous structure of the Petri net is ideally suited to the modeling of anautonomous mobile robot, provided the model can be thoroughly tested prior to code generation orexecution on board the robot. To this end, the reachability test, as one of the most basic means forchecking the accuracy of the model compared to its expected execution, provides a great deal ofreassurance to the designer of the software, which in turn allows the designer to create more complexsystems reliably.
The need for mathematical analysis of the Petri net models created for the mobile robot, provided anideal opportunity for collaboration between mathematics and engineering departments. As a result ofthis co-operation, an approach to Petri net analysis formed, based on the relationship between Petri netsand Gröbner bases. The application of Gröbner bases has been successfully used in fields such asoperational research and statistics, but is as yet less common in engineering.
The subject of this paper is the application of the Gröbner basis to the testing of reachability in aPetri net model, specifically to a Petri net model of a mobile robot. This application is implemented asan automatic testing facility within a Petri net toolkit, TRAMP (Toolkit for Rapid Autonomous Mobilerobot Prototyping) intended to model mobile robots and other mechatronic systems from the stages ofconceptual design to a final executable program. These Petri net models are initially formed asindividual modules, each related to a component of the system, in order to allow easier testing andanalysis prior to creation of the final, global, Petri net model [Chandler 99a].
In section 2 of this paper, some previous Petri net applications will be discussed, providing abackground to the choice of Petri nets as a model for the autonomous mobile robot. Section 3 willdetail the Petri net toolkit, TRAMP, before the Gröbner bases used as a testing method are studied in
21
further detail (section 4). A case study showing the use of the method for the mobile robot, Star Track,will be discussed in section 5, followed by conclusions and future work.
2 Choice of Petri Nets
Petri nets are generic enough to provide the capacity for application to a wide variety ofapplications, although due to their asynchronous nature they are more commonly used for distributedsystems [Buchholz 92] and other similar processes. However, their uses in distributed systems by nomeans exclude applications to the field of robotics. In fact, robots can themselves form part of adistributed system, as can be seen through the example of an orange-picking robot with point-to-pointcommunications [Cavalieri 97]. Other areas of robotics can also find use for Petri net modelling as amethod of eliminating deadlock and other temporal inconsistencies [Simon 98] [Caloini 98], althoughthese properties require testing through timed Petri nets, an extension which has yet to be made to theanalysis system used here. Alternatively, Petri nets can be used to allow co-operation between multiplerobots [Suh 96], or between a human and a robot [Mascaro 98]. The range of applications for Petri netsis enormously diverse, and limited only by the range of tools available to implement these possibilities.
Our use of Petri nets as a modeling tool in the field of mobile robotics, was initially inspired by theirability to represent both the data flowing in the system and the state of the system, simultaneously.This initial interest was then furthered by the ease with which the model could be translated intoexecutable code, as required by the TRAMP toolkit discussed in the section 3, below, without the needto alter any of the components modeled. These factors, combined with the mathematical backgroundwhich supported the testing of any models used, and examples of previous applications to the field ledto the eventual use of Petri nets within the TRAMP toolkit.
3 TRAMP
The TRAMP toolkit provides a simple means of modeling, testing and generating code for a mobilerobot. This is initially done in the form of modules, or objects based on the separate components of themobile robot, and divided into five categories in an overall object diagram in order to allow the toolkituser to connect the objects as desired. These five categories, sensors, filters, navigation, low levelcontrol, and actuators are also used to provide certain attributes to each object which may only berelevant to that category.
Sensors Filters Navigation Control Actuators
Figure 1 Object Diagram Layout
As the arcs in Figure 1 suggest, the flow of information in the system leads from sensors to actuatorsvia various processing alternatives. Once data has been read in from a sensor, such as a compass, thedata may then be filtered to remove any noise from the readings, before the navigation uses the data tomake a decision on the next move of the robot. With the commands to be issued to the actuatorsdecided, the navigation module will then pass the information either directly to the actuator (forexample a motor) or via a low level controller, which will translate the information into a formreadable by the actuator and ensure that it behaves exactly as it should.
Once the modules are defined and linked in the object diagram, as shown in Figure 1, the user maythen access the Petri net modules of each of the separate components. These components remain
22
completely unconnected whilst they are tested, which may include testing on board the robot as aseparate module, after which the modules may be linked according to a precise protocol. This isdiscussed below.
Linking
Once all testing of the Petri net is complete, the user may then link the individual componentsaccording to the connections defined in the object diagram, and a specific hierarchy. This hierarchymakes the navigation module the highest level element, and works outwards in the object diagrammaking the sensors and actuators the lowest. The navigation module (or modules) is designed so thatwhilst it can be tested in simulation as it stands, several of its transitions actually represent groups oftransitions for use when the Petri net is finally connected. As the Petri nets are linked, the navigationmodule (Figure 2) fully expands its complex transitions.
start
initialise
initdone
define map/behaviour
ready
end
statusknown
ready to move
sensors decision actuators
Figure 2 Navigation Module
The transitions “initialize”, “end”, “sensors” and “actuators” are all substitution transitions [Jensen96], each expanding into several transitions, providing connections to the other modules. Theremaining “define” and “decision” modules represent the actual method of navigation required of therobot, and can easily be exchanged for a number of standard defaults, or left for the user to fullyimplement.
Initialization and End Expansion
The “initialize” and “end” transitions connect directly to every other module in the system, ensuringthat every initialize routine is called before the main program starts, and that the program shuts downcorrectly when it finishes. Each initialize place shown here will be connected to a transition within therelevant module which is defined as an “initialize” transition and marked for connection outside themodule in a method similar to that used in [Caloini 98]. The expansion of these is shown below, withan expanded view of the low level section of the motors Petri net.
initialise enter
Compassinitialise
GPSinitialise
DC Motorinitialise
endinitialise
initialiseexit
3
Low level components
Compass module
GPSmodule
init.complete
initialisesend speedanddirection
Figure 3 Initialize Transition Expansion
23
Figure 3 shows the expansion of the initialise transition to connect to two sensors (the compass andthe GPS – Global Positioning System) and one actuator (the DC motor). Here, there were no filters orcontrollers in the system.
Sensor and Actuator Expansion
Similarly, the “sensors” and “actuators” transitions can be expanded. However, here the linkscreated in the object diagram come into play, as the only connections made are those which are directlyconnected to the navigation module. For the expansion of a “sensors” transition, this includes anyfilters which are connected to the navigation module, but not any sensors connected only to the filter asthey must be connected through a similar process in the filter module.
Compasssensors in
sensorsin
sensorsdirect
GPSsensors in
Compasssensors out
GPSsensors out
sensorscollec t
sensorsall
sensorsout
Compasssensors in
sensorsin
sensorsdirect
GPSsensors in
Compasssensors out
GPSsensors out
sensorscollec t
sensorsall
sensorsout
Compasssensors in
sensorsin
sensorsdirect
GPSsensors in
Compasssensors out
GPSsensors out
sensorscollec t
sensorsall
sensorsout
Compassmodule
GPSmodule
Low level components
Figure 4 Sensor Transition Expansion
The configuration for sensor transition expansion (Figure 4) is slightly different to allow for thepossibility that there many be no sensors or filters connected, but the transition must still operate. Theplaces which link to the lower level modules behave as they do in the “initialize” transition expansion,connecting in place of the test driver initially provided with each module, to transitions which aredefined from the start as an externally connecting. In this case, the connecting transitions of thecompass can be seen in Figure 7, transitions “request data” and “send data”.
There are also special standardized tokens, which allow this operation to be performed moresmoothly. These tokens contain all possible elements of any expected sensor readings or instructionsto actuators respectively. These readings or instructions can then be easily converted to or from thetokens created for specific sensor and actuator modules. Here, there were two sensors directlyconnected to the navigation module and no filters.
Control from Navigation
The method of expansion described in the previous sub-sections is designed specifically to allow thenavigation module to maintain control over the system as a whole. The bipartite nature of the Petri netgives the two types of nodes, places and transitions, specific meanings that must be taken into accountwithin the model. Clearly, the transitions perform the actions, whereas the places merely maintainstate, but there are further implications which can be put into use here. The nature of the places is suchthat they have authority over transitions. Transitions cannot fire without, in a sense, instructions from aplace as each input place must contain a token in order to enable the transition. It is analogous to thehanding out of instructions by a superior, and prior to the receipt of permission the task may not beperformed.
Whenever a link is formed between two modules, the module which is further up the hierarchycontains the place which is linked, whilst the lower level module contains the transition. The lowerlevel module knows only that an instruction has been received, whilst the higher level modulecontinues to be aware of its state, despite the departure of the active tokens into a separate module.
24
This predictable method of linking also ensures that the reachability test results performed whilst themodules were still separated will still be accurate once the modules are reconnected, as the individualmodules remain essentially separate whilst the pre-tested navigation module and connectors form linksto them.
4 Testing through Gröbner Bases
Gröbner basis theory is a branch of computer algebra which provides methods for solving problemsof equivalence in various types of algebraic structure. In the commutative case, computational Gröbnerbasis methods have been successfully applied in theorem proving, robotics, image processing, codingtheory and signal processing, amongst others [Buchberger 98] [Holt 96]. All major computer algebrapackages now include implementations of these procedures and there are also pocket calculatorimplementations. A formal definition of the Gröbner basis is included as an appendix to this paper.We also refer the reader to [Fröberg 97] for further details.
In this paper, the application of Gröbner basis procedures to the problem of reachability testing isdiscussed for reversible Petri nets and demonstrated with a practical case study.
The generation of the Gröbner basis of a set of polynomials, as is used for the Petri net analysis inlater sections, is done with the use of Buchberger’s algorithm [Buchberger 98]. The algorithmcalculates a Gröbner basis for a set of polynomials by repeatedly testing and appending it with furtherpolynomials until the appended set satisfies the properties of a Gröbner basis with respect to a chosenwell-ordering of the variables. This method is more formally defined in the appendix.
Once created, the Gröbner basis may be used to find any reachable marking, provided the initialmarking is a home marking, or alternatively determine whether the Petri net is reversible based onresults of reachability testing (see section 5).
5 Case Study – Star Track
Figure 5 Star Track
The Petri nets discussed here are based on real life models, created for use on board the mobilerobot, Star Track (Figure 5), intended to perform navigation with the use of satellite GPS [Yavuz 99].This robot’s major components consisted of a compass, a GPS receiver, a PC 104 computer, and fourDC motors. These four components formed the main objects within the object diagram, two of whichare considered in the following examples. It should be noted that the Petri nets shown represent thesoftware interface to the hardware components named, not the hardware components themselves, as theintention of TRAMP is the generation of control software for use with specific hardware.
25
Motors
start
ready
restart
allcomplete
finish
init.complete
initialise
done
speed anddirection
changevectorrequestvector
changerequested
senddone
send speedand direction
interpret speedand direction
interpreteddata
writeto port
1
t1
t2
3
t34
t45
t56
t6
t8
8 t7
7
2
Figure 6 Motors Petri net
As can be seen in the Petri net shown in Figure 6, once the motors have been initialised (t1) the usermay input the required speed and direction (t2) for each motor. The speed and direction information isthen interpreted (t3) and written to the relevant port (t4), provided the system is “ready” (place 3) which,combined with the user input token, will enable transition t3.
The Gröbner basis for this Petri net is generated from the polynomials of the transitions listed below,where x represents a token in a given place.
For example, a token at place 1 allows the firing of transition t1 and results in a token in places 2 and 3.This can be represented by the polynomial:
pol(t1) = x1 - x2x3
And seen in the diagram below:
x1
t11
2
3
x2
x3
t11
2
3goes to
Polynomials for the other transitions can be similarly generated:pol(t2) = x2 – x7
pol(t3) = x3x6 – x4
pol(t4) = x4 – x5
pol(t5) = x7 – x6
pol(t6) = x5 – x3x8
pol(t7) = x3x8 – x1
pol(t8) = x8 – x7
These polynomials are then used to form the Gröbner basis:{x 4 – x1, x5 – x1, x6 – x2, x7 – x2, x8 – x2, x2x3 – x1}
26
This Gröbner basis can be calculated automatically, either through TRAMP or through a standardpackage such as Maple.
This gives a catalogue of markings (reachable places) from an initial marking x1 (i.e., starting with atoken in the place “start”) to be:
{x 1, x4, x5, x2x3, x3, x6, x3x7, x3x8}
These reachable markings are found based on their equivalence to the defined initial markingmodulo the transitions, which can be determined algorithmically, using polynomial reduction withrespect to the Gröbner basis (see appendix).
As the Gröbner basis is only useable when the Petri net is reversible, an undesirable, or unexpectedstate within this list would indicate either that the Petri net was not reversible, or that there was an errorin the Petri net itself, allowing the unexpected state. Once the possibility of either an undesirablereachable place (or alternatively a desirable place which wasn’t reached) or a non-reversible Petri net iseliminated, the chance of a serious error occurring on board the mobile robot during execution isgreatly reduced.
Should an undesirable state be reachable from the initial marking, it must first be decided whetherthe error is in the reversibility of the Petri net or in the reachability. This is best done by checking forerrors in very simple, and obvious, reachability calculations. If the tester claims that a clearlyunreachable state is reachable then it is likely that the Petri net is in fact not reversible, and that iswhere the error lies. Should the Petri net appear to be reversible, the user can seek further assistance byusing the “step through” method, which gives a visual representation of the movement of the tokensthrough the Petri net, and allows the user to see the error as it occurs.
27
Compass
start
comsopen
raw dataready
asciidata
checksum
testeddata
dataavailable
dataready
return data
initialise
data request
return data
store data
finish
opencomport
sendready
read in calculatechecksum test
findbearing
dead reckoningmodule
ready
datarequested
requestdata require
data
restart
allcomplete
dataarrived
finish
senddata
printdata
init.complete
predictrequested
mainprocessexited
Input
Continue
P P
PP
P
P
PP P P P P
P
P
P P
P
P
P P
PP PP
P
PP
P
P
P
P
P
PP
P
P
P
PP
FFF
FFF
F
F F
F
F
F
F F
t11
t254
2
3
18
t3
t4 t5 t6
t15
t16
t17
t18
t19
t7
t8
t14
t10
t12
t13Halt
Discard
t9
6 7 8
9
10
11
13 12
19
14
15
exiting17
16
t20
t21 t22 t23
t24
t25
P P P
PP
P
PP
F
P
P
PPP
P
P
P
P
Figure 7 Compass Petri Net
28
Before analyzing the Petri net shown in Figure 7, it is necessary to consider a further extension tothe Petri net theory described in section 2. The compass Petri net is a coloured Petri net with a finiteset of colors.
The extension of an ordinary Petri net to a coloured Petri net provides the ability to representdifferent types of token and treat them differently. In a coloured Petri net, the transition is only enabledby an incoming token if the token’s colour matches the colours allowed by the transition. A colouredPetri net can always be converted to an ordinary Petri net through additional places and transitions foreach different colour.
The compass Petri net contains a number of different token types in order to represent theinformation types required within the compass program, such as the ASCII characters read in from thecompass itself, or the final format of the data when a bearing has been established. However, theseadditional token types do not affect the choices made in this Petri net, and are therefore irrelevant to itsanalysis. In the case of the compass Petri net shown in Figure 7, there are essentially only two colorsrequired in the Petri net, “pass” and “fail”, as these are the only two colours relevant to the testing ofthe Petri net in simulation. Any other variations in token type serve no purpose in simulation but toincrease the complexity of the analysis.
For the purposes of the calculations to be performed using Gröbner bases, the “pass” tokens havebeen labelled x, and the “fail” tokens y. The initial marking of the Petri net is described by a single“pass” token in the “start” place (1), and “pass” and “fail” tokens in each of the places “input” (18) and“continue” (19). The additional tokens at places 18 and 19 allow the user to perform the more rigoroustesting of the coloured Petri net.
The “pass” and “fail” tokens are primarily used as a distinction between data received with a correctchecksum and data received with a failed checksum. This colouring is used to ensure that onlyuncorrupted data is used to calculate the bearing, which will later be output to the main navigationmodule of the mobile robot. Any failed data is instead sent to the “data request” transition, which canthen provide a connection to the “dead reckoning plug-in module” not shown in this diagram. This canbe seen through tracing the route of a “pass” and then a “fail” token through the transitions “read in” (t4
or t21), “calculate checksum” (t5 or t22) and “test” (t6 or t23) to the conclusion of the decision at thetransitions “find bearing” (t7) or “data request” (t16).
As shown in the previous example, the first step in the analysis of the Petri net and generation of theGrobner basis is to establish the polynomial for each transition. These polynomials are listed below,with a pass token represented by an x, and a fail token represented by a y.
For example, the polynomial:pol(t10) = x14x19 – x15x19
represents the following possible transition.
P
14 15
19
t10
P
goes to
14 15
19
t10
P
P
29
Note that pol(t24) is identical to pol(t10) apart from coloring.pol(t24) = x14y19 – y15y19
14 15
19
t24
P
F
F
14 15
19
t24
F
goes to
Polynomials can be generated for the other transitions as follows.pol(t3) = x2x18 – x3x18,
pol(t20) = y2y18 – y3y18
pol(t4) = x3x13 – x6
pol(t21) = y3y13 – y6
pol(t5) = x6 – x7
pol(t22) = y6 – y7
pol(t6) = x7 – x8
pol(t23) = y7 – y8
pol(t1) = x1 - x2x4
pol(t2) = x5 – x12
pol(t7) = x8 – x10
pol(t8) = x12 – x13
pol(t9) = x11 – x2x14
pol(t11) = y15 – x17
pol(t12) = x3x17 – x16,pol(t25) = y3x17 – x16
pol(t13) = x2x17 – x16
pol(t14) = x15 – x12
pol(t15) = x4 – x5
pol(t16) = y8 – x9
pol(t17) = x9 – x11
pol(t18) = x10 – x11
pol(t19) = x16 – x1
The complex Gröbner basis automatically generated from these polynomials is shown below. Someof the resulting expressions are shown graphically to clarify the meaning of the generated polynomials.The polynomials shown in bold represent expressions which would require tokens to pass through theentire Petri net more than once in order for one marking to be reachable from the other.
y3y15y19 – y8y19
y18y3y15 – y8y18
x14x19 – x15x19
x16 – y3y15
y3x15 – y8
y19x15x19 – x19y15y19
x14y8y18 – y15y8y18
x14y8x18 – x18y15y8
x14y3y15 – y15y8
x13 – x15
x12 – x15
x11 – y8
x9 – y8
x5 – x15
x4 – x15
x2y18 – y3y18
x2y15 – y3y15
x2x18 – x3x18
y7 – y8
y6 – y8
x17 – y15
x14y19 – y15y19
x2x15 – y3y15
x2x14 – y8
x1 – y3y15
x2y8 – y32y15
x3y15 – y3y15
x3y8 – y3y8
y18x3x18 – x18y3y18
x3x15 – y8
x14x3x18 – y8x18
x8 – y8
x7 – y8
x6 – y8
x10 – y8
x15y8 – y15y8
x14y15y8 – y152y8
x14y82 – y15y8
2
x14y3y18 – y8y18
y3y152 – y15y8
y3y15y8 – y82
y3y15y19 – x19y8
x18y3y15 – y8x18x17
As can be seen through the graphical representation of these first two polynomials, the polynomialswhich form the basis are not necessary in their simplest form, they show combinations of thepolynomials formed by the transitions, with P representing a pass token, and F representing a failtoken.
y7 – y8
testeddata
checksum
testeddata
test
t237 8
F checksum
test
t237 8
Fgoes to
30
y6 – y8
testeddata
asciidata
checksum
t22 t236 7 8
F testeddata F
checksum
t22 t236 7 8asciidata
checksum goes to
testeddata
x17 – y15
exitingallcomplete
t11
exiting
t11
exiting allcomplete
F P
t11
goes to
This diagram shows the change between a “fail” token and a “pass” token, possible only at specifiedtransitions.
x14y19 – y15y19
dataarrived
continuecontinue
allcomplete
t10
allcomplete
t10
dataarrived
F
PP
F
goes to
This diagram shows the token in the “continue” place (19) affecting the output of the transition. Theequivalent polynomials for changes made through the “input” place (18) are shown in the first twopolynomials below.
The remainder of the polynomials forming the Grobner basis for the compass Petri net (shown inbold) are more difficult to trace through the Petri net diagram, as they require tokens to pass around thePetri net more than once. This is perfectly acceptable, as the Petri net is expected to be reversible, butit does lead to polynomials which are misleading at first glance, and similarly to reachable markingswhere the path taken is unclear.
The shown completed Gröbner basis, once generated, can be used to find every reachable markingof the compass Petri net is represents. However, due to the length of this example, these results are notlisted here.
Testing the reachability of this Petri net, given a certain type of token, will confirm that the choicesmade by colouring of a given token will behave as the user would expect, beyond the simple testing ofa Petri net with no colourings. This will enable the user to determine errors of this nature prior to thefinal generation of executable code for the mobile robot and decrease the necessary debugging time.
6 Conclusions and Future Work
The method for Petri net analysis described here has proved highly reliable and accurate. It isparticularly successful in the detection of Petri nets which have falsely been assumed to be reversible,and in finding badly designated initial markings of the Petri net which may also stop it from beingreversible.
However, the time taken for performance of these calculations remained, as with many previousmethods, unacceptably long despite the modularity of the model. The motors example shown insection 5 was completed successfully within a few minutes, but once a colouring was added alongside anumber of places and transitions for the compass example (section 5) the time taken increased beyondthat which could be considered reasonable for the user to wait, Gröbner basis generation takingapproximately an hour.
31
The primary concern of any further work on this technique must be the reduction of the time takenfor results of reachability testing to become available to the user. There are three possible avenues ofresearch available, which may lead to an appropriate reduction in complexity. The first may considerthe reduction of the Petri net itself. Whilst the TRAMP method of separating objects into individualcomponents has already greatly decreased the Petri net complexity [Pezze 95] [Caloini 98], it is clearthat further effort must be put into this in order to provide a usable analysis service. This may beimplemented through the use of standard Petri net reduction techniques [Murata 89].
The processing time may then be further reduced through the improved implementation of theGrobner basis techniques [Fröberg 97], which themselves have a number of efficiency algorithmswhich have yet to be utilised in these initial testing procedures.
A further alternative to the Petri net reduction and Gröbner basis efficiency techniques is theintroduction of on-the-fly matrix generation method commonly applied to automata in order to improvethe efficiency of the equivalent of reachability testing [Larsen 97]. If this method were to be applied tothe Gröbner basis reachability test for the Petri net, then the overheads from large Petri nets woulddecrease dramatically.
A further desirable development may arise from the introduction of timings to the Petri net, whichare already a widely used tool, and provide a valuable additional level of analysis to the Petri net.
References
[Buchberger 98] An Algorithmic Criterion for the Solvability of a System of Algebraic Equations,Buchberger B (translation Abramson M and Lumbert R). Grobner Bases and Applications.Proc. London Math Soc. Vol 251. 1998.
[Buchholz 92] A hierarchical View on GCSPNs and its Impact on Qualitative and QuantitativeAnalysis. Buchholz P. Journal of Distributed Computing, 1992, Vol 15, pp 207 – 224
[Caloini 98] A Technique for Designing Robotic Control Systems Based on Petri Nets. Caloini A,Magnani G, Pezze M. IEEE Transactions on Control Systems Technology, Vol 6, No 1, pp72-87. 1998.
[Cavalieri 97] Impact of Fieldbus on Communication in Robotic Systems. Cavalieri S, DiStefano A,Mirabella O. IEEE Transactions on Robotics and Automation, 1997, Vol 13, No. 1, pp 30-48
[Chandler 99] Gröbner Basis Procedures for Testing Petri Nets. Chandler A, Heyworth A. UWB Mathpreprint 99.11. 1999
[Chandler 99a] An Object-Oriented Petri Net Toolkit for Mechatronic System Design. Chandler A.PhD Thesis, Lancaster University, Engineering Department, 1999.
[Fröberg 97] An Introduction to Gröbner Bases. Fröberg R. John Wiley and Sons, 1997.
[Holt 96] Algebraic Methods for Image Processing and Computer Vision. Holt RJ, Huang TS,Netravali AN. IEEE Transactions on Image Processing, Vol 5, No 6, pp 976-986. 1996.
[Jensen 97] Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use Volume 1.Jensen K. Spring-Verlag. 1997.
[Larsen 97] Efficient Verification of Real-Time Systems: compact data structure and state-spacereduction. Larsen KG, Larsson F, Pettersson P, Yi W. Proceedings – Real-Time SystemsSymposium, 1997.
[Mascaro 98] Hand-in-Glove Human-Machine Interface and Interactive Control: Task ProcessModelling Using Dual Petri Nets. Mascaro S, Asada HH. Proceedings - IEEE InternationalConference on Robotics and Automation, 1998, Vol 2, pp 1289-1295
32
[Murata 89] Petri Nets: Properties, Analysis and Applications. Murata T. Proceedings of the IEEE,1989, Vol 77, No. 4, pp 541 – 580
[Pezze 95] Graph Models for Reachability Analysis of Concurrent Programs. Pezze M, Taylor RN,Young M. ACM Transactions on Software Engineering, Vol 4, No 2, pp 171-213. 1995.
[Simon 98] Design and Analysis of Synchronisation for Real-Time Closed-Loops Control in Robotics.Simon D, Castaneda EC, Freedman P. IEEE Transactions on Control Systems Technology,1998, Vol 6, No. 4, pp 445-461
[Suh 96] Design of a Supervisory Control System for Multiple Robotic Systems. Suh IH, Yeo HJ, KimJH, Ryoo JS, Oh SR, Lee CW, Lee BH. IEEE International Conference on Intelligent Robotsand Systems, 1996, Vol 1, pp 332-339
[Yavuz 99] Conceptual Design and Development of a Navigation System for a Mobile Robot. YavuzH, Chandler AK, Bradshaw A, Seward DW. Proceedings of CACD 99 (InternationalWorkshop on Engineering Design), 1999, pp 65 - 80
Appendix A: Gröbner Bases Definitions [Chandler 99]
Let X be a set. Then the elements of X¨ are all power products of the elements of X, including anidentity 1, with multiplication defined in the usual way. The commutativity condition is summarizedby xy=yx for all x, y ∈ X. Let K be a field. Then the elements of K[X¨] are sums of K-multiples ofelements of X¨, with the operations of addition and multiplication defined in the natural way:
∑i ki mi ∑j lj nj = ∑i,j ki mi nj , for ki, lj ∈ K and mi, nj ∈ X¨
Let P ⊆ K[X¨]. Equivalence modulo P is denoted = P. We say that two polynomials are equivalentmodulo P if their difference can be expressed in terms of P, i.e.
f =P g ⇔ f – g = u1p1 + … + unpn for some p1, … , pn ∈ P, u1, … , un ∈ K[X ¨].
An admissible ordering on X¨ is a relation > such that m>1 for all 1≠m ∈X¨, and such that if m>nthen um>un for all u ∈ X¨. We will also require the well-ordering property: that there is no infinitesequence m1>m2>… of power products m1, m2, … of X¨.
Let > be admissible well-ordering on X¨. The leading term of a polynomial p is the power productoccurring in p that is largest with respect to >, and is denoted LT(p). The leading coefficient of p isthe coefficient of LT(p) and is denoted LC(p). A term t is said to occur in a polynomial p withcoefficient k if t is a term of p. Reduction modulo P with respect to > is written →P and defined as
f →P h ⇔ = f - kmp
where mLT(p) occurs in f with coefficient k′ and k = k′(LC(p))-1 for p ∈ P.A repeated sequence of reductions (the reflexive, transitive closure of →P) is denoted →*
P. Thesymmetric closure of this is denoted ↔*
P coincide.
The Buchberger Algorithm
In 1965 Buchberger invented the concept of a Gröbner basis [Buchberger 98]. If a set ofpolynomials Q is a Gröbner basis for P then we can use Q to determine whether two polynomials areequivalent modulo P. Formally:
i. f =P g ⇔ f =Q g for all f, g ∈ K[X ¨].
33
ii. For all f ∈ K[X¨] there exist f1, … fn ∈ K[X ¨] such that f →P f1 →Q … →Q fn where n ∈ Nand fn is irreducible.
iii. f =P g ⇔ there exists h ∈ K[X ¨]: f →*Q h and g →*
Q h.
Theorem (Reachability and Equivalence of a Polynomial)
Let N be a reversible Petri net with initial marking M0. Define P:={pol(t): t∈T}. Then a marking M isreachable in N if and only if pol(M0)=P pol(M).
Proof
First suppose that M is reachable. Then there is a firing sequence M0 →t1 M1 →t2 … →tn-1 Mn-1 →tn
M. Therefore there exist u1, … , un ∈ X¨ such thatpol(M0) – u1pol(t1) = pol(M1), pol(M1) – u2pol(t2) = pol(M2), … , pol(Mn-1) – unpol(tn) = pol(M).Therefore pol(M0) – pol(M) = u1pol(t1) + … + unpol(tn). Hence pol(M0) =P pol(M).
For the converse, suppose pol(M0) =P pol(M). Then there is a sequencepol(M0) = u1l1, u1r1 = u2l2, … , un-1rn-1 = unln, unrn = pol(M).
Where pol(t1) = l1 – r1, … , pol(tn) = ln – rn ∈ P, and u1, … , un ∈ X¨. Note that l1, r1, … , ln, rn ∈ X¨.Now recall that M0 is a marking. Since pol(M0) = u1l1, we can deduce that t1 is enabled. Thereforethere is a marking M1 such that M0 →t1 M1 and pol(M1) = pol(M0) – u1pol(t1). By induction thisimplies that there are markings M2, … , Mn such that there is a firing sequence M0 →t1 M1 →t2 … →tn
Mn = M. Hence M is reachable in N.
Corollary (Gröbner Bases Determine Reachability)
Reachability in a reversible Petri net can be determined using a Gröbner basis.
Remark (Catalogue of Reachable Markings)
Recall that Gröbner bases techniques use an ordering on the power products. There is a one-onecorrespondence between power products and markings. We can begin to catalogue the markings inincreasing order. Given a Gröbner basis for the polynomials of the transitions of a Petri net it can bedetermined whether each marking is reachable: if the power product reduces to the same irreduciblepower product as the initial marking then it is reachable. In this way the Gröbner basis can be used tobuild up reachable markings.
34
������������ ����������������������� ������ �� �!�"���$#%��&'�)(*,+�-.��#/101*'�2������ ���435�6 �2�879�6 &
:�; <>=@?BACED AFHG =JILK�<>=NMO; P�QR S%T =@?JUNV AF D G IO=@?WM"X.UNPYQ= AF KU@Z[?W= S\6]�^L_�`ba[c$]�deaf gihifjc$^lkNa[]m`/n@o�p ]�dlo�]%_ dLqsr1dltjp dl]�]m`[p dltNuOv.`[dlfxw/dlp yz]m`[{bp a}|)f g1~�]�oH�ldlfj� fjt |
vifl�� ]ma��]�oH�lf�yj_��euOh�l�@�@���x�j�$v.`[dlfNuOh � ]�oH�s�E]�^lkl�l� p o]m��c�_ p ���O��o�]�{b�j_@uj�b_ dlfjkl{b]��Oulyzf���dL_�`�� �6qNo�{b]j� g>]�]j� y@kNa[�N`�� o �
�����������L�j�j� ~ �l]_�`ba[p o�� ]EqN]�{bom`[p �O]�{1{b]�yz]m`H_ �No�fjdlo�]�^Na[{�]�{�aH_ �l� p {b�lp dlt�_/�L_ {bp {�g>f `tj]�dl]m`H_�a[p dlts_ dLq�]m N^l� fjp a[p dlt�{�aH_�a[]�{b^L_ o�]�{6f gia[�l]�fj�@��]�omab��f `[p ]�dea[]�q"¡¢]mab`[p�dl]ma[{£�¤%¤ ¡1¥/{H¦E_ {b{bfeo�p _�a[]�q§a[f�a[�l]�a[fefj�1o�_ � � ]�q§¡1¥EaH_ � �O�W~ �l]�p dN¨Lkl]�dlo�]�f gip qN]�dea[p �© ]m`[{1f gJq@|NdL_ c$p o�_ � � |�_ ^l^O]�_�`[p dlt%_ dLq�qNp {[_ ^l^O]�_�`[p dlt%p dl{�aH_ dlo�]�{1kl^Ofjd�a[�l] {�aH_�a[]{b^L_ o�]$]m N^l� fj{bp fjd�^N`[fj�l� ]�cªp {�]m N^l� _ p dl]�qJ��«�]ma[�lf@qN{�f g ¬ f `[�@p dlt�¬2p a[��p qN]�dea[p �© ]m`[{/�L_ {b]�qsfjd{bfj^l�lp {�a[p o�_�a[]�q�dL_ c$p dltx`[kl� ]�{6_ dLqsc$]�oH�L_ dlp {bc${g>f `%_ �l{�ab`H_ omab�p dltdL_ c$]�{x_�`[]�qN]�{bom`[p �O]�q®_ dLq�o�fjc$^L_�`[]�qJ�1n@]�yz]m`H_ � fj^Na[p c$p � _�a[p fjdl{�f g/{�aH_�a[]{b^L_ o�]Etj]�dl]m`H_�a[p dlt�_ � tjf `[p a[�lc${.g>f `.a[�l]2o�fjdea[]m @a.f g ¤%¤ ¡1¥/{._�`[]2c$]�dea[p fjdl]�qJuz_ {¬ ]�� ���O¯¢p dL_ � � |euL{bfjc$]6^Ofj{b{bp �lp � p a[p ]�{/f g�{b^O]�o�p g |Np dlt$^N`[fj^O]m`ba[p ]�{2f g1{�|N{�a[]�c${ a[fx�O]oH�l]�oH�z]�q�f�yz]m`1a[�l] {�aH_�a[]{b^L_ o�]�{.f gLa[�l]�p ` ¤%¤ ¡1¥E���L_ {b]�q�c$f@qN]�� {._�`[]2qNp {bo�kl{b{b]�qJ�
° ±l²E³O´Jµ%¶�·�¸�³J¹[µE²
C V SmS D ?lº/»�UNPs¼J< D�½ MO; F º S ; ¾JVOº D M§=@¼J¼J< ;>» =eºm; UN? F S Dj¿ VJ; S D M D =@< ; ?JÀ�Á%; ºmÂ"MOÃL?W=@Ps;>» =@< < Ãs= S ; F[Ä; ?JÀ)=@?WM�MO; F =@¼J¼ D = S ; ?JÀ$UN¾OZ D »�º F Á%ÂJ;>»�§» =@?�»�UNPsP)VJ?J;>» =eº D I F ÃL?W»� S UN?J; Å D ºm D ; S =N»�ºm; UN? F I=@?WM$Ps; À S =eº D =@PsUN?JÀ�¼W= S ºm;>»�VJ<>= S ?JUOM D F U@ÆOºm D MO; F º S ; ¾JVOº D M D ?LÇL; S UN?JP D ?lº1ºm D Ã$= S D S VJ? Ä?J; ?JÀ"; ?1È¢É= S ºm;>»�VJ<>= S < ÃNI�MO; F º S ; ¾JVOº D M®UN¼ D S =eºm; ?JÀ F à F º D P F I¢À S UNVJ¼LÁ6= S D =@< < UeÁ%; ?JÀ"=§»�UN? Ä»�V SmS D ?lº�Á/U S G U@Æ F D Ç D S =@<¼ D UN¼J< D UN?ʺm D F =@P D ¼ S U@Z D »�ºjI1U S =@¼J¼J< ;>» =eºm; UN? F D�½ ¼J< UN; ºm; ?JÀºm D º D »�ÂJ?JUN< UNÀNÃ$U@Æ¢=@À D ?lº F U S PsUN¾J; < D =@À D ?lº F » =@?�¾ D < ; F º D Ms= F D�½ =@Ps¼J< D F U@ÆWºm D =@¾�UeÇ D ÄP D ?lºm; UN? D M�=@¼J¼J< ;>» =eºm; UN? F ÈË <>=@?JÀNVW=@À D » =@< < D MBÉEÌ%º�=@< G ¾W= F D MÍUN?ÎUN¾OZ D »�º Ä U S ; D ?lº D MÍÉ D º S ;)? D º FÐÏ�Ñ$Ñ ÉEÌ F�ÒÓ T =@?WÔNÕjÖLÂW= F ¾ D D ?)M D Ç D < UN¼ D Mx=eº1ºm D/×$C6ØOÙ IjX%ÚÜÛ S ?JU%; ?�U S M D S ºmU F VJ¼J¼�U S º.PsUOM D < < ; ?JÀWI; ?LÇ D F ºm; Àl=eºm; ?JÀWI@=@?WMs¼ S U@ºmU@º[ÃL¼J; ?JÀ$»�UNPs¼J< D�½ MO; F º S ; ¾JVOº D MsUN¾OZ D »�º Ä U S ; D ?lº D M F U@Æ�º[Á6= S D F à F[ĺ D P F ÈJÉEÌ%º�=@< GF VJ¼J¼�U S º F ; ?lºmVJ; ºm; Ç D PsUOM D < < ; ?JÀ�=@< <�ºm D G D Ã�Æ D =eºmV S D F U@Æ.ºm D F D F à F º D P F IF VW»�®= F UN¾OZ D »�º Ä U S ; D ?lº D MO? D FmF IJP D FmF =@À D F D ?WMO; ?JÀWIW¼W= S =@< < D < ; F P�IW=@?WM F ÃL?W»� S UN?J; F =eºm; UN?1ÈX6ÂJ; F ; F =N»�ÂJ; D Ç D Mºm S UNVJÀNÂ�Á/U S G ; ?JÀsÁ%; ºmÂ�=N»�ºm; Ç D UN¾OZ D »�º F D ?W» =@¼ F VJ<>=eºm; ?JÀ F D º F U@Æ ¼ S U Ä» D FmF D F M D F » S ; ¾ D MоLÃYÉ D º S ;�? D º F È/É S UO» D FmF D F ; ? F ;>M D ºm D UN¾OZ D »�º F »�UNPsP)VJ?J;>» =eº D ÇL;>== F ÂW= S D M§P D PsU S ÃNIOÁ%ÂJ; < D UN¾OZ D »�º F ºm D P F D < Ç D F »�UNPsP)VJ?J;>» =eº D ¾LÃP D FmF =@À D ¼W= FmF ; ?JÀWÈØ ; P)VJ<>=eºm; UN?s; F UN? D U@Æ¢ºm D Á6=zà F U@Æ D�½ =@Ps; ?J; ?JÀ F à F º D P F PsUOM D < < D Ms¾Là Ñ$Ñ ÉEÌ F =@?WM; º�; F =@< S D =NMOà F VJ¼J¼�U S º D M"¾LÃ"=�¼ S U@ºmU@º[ÃL¼ D Ç D S F ; UN?"U@Æ2=�ºmULUN<.» =@< < D M�ÉEÌ%º�=@< G Ó AC T K�ÔLÝ Ö�È:�UOM D < F U@Æ F U@Æ�º[Á6= S D F à F º D P F » S D =eº D MÊ; ?8ÉEÌ%º�=@< GÞF ÂJUNVJ<>MÞ¾ D V F =@¾J< D = F ¼ S U@ºmU@º[ÃL¼ D FU@Æ�ºm D F D F à F º D P F I2= F Á D < <}È C V SmS D ?lºm< ÃÜÁ D = S D Á/U S G ; ?JÀÞUN?Ð? D Á'; Ps¼J< D P D ?lº�=eºm; UN? FU@Æ%ÉEÌ%º�=@< G ; ?ßÉ S UN< UNÀ"=@?WMÊ; ? Ø P�=@< < º�=@< G Á%ÂJ;>»� F ÂJUNVJ<>MÊ=@< < UeÁBºmU S VJ? Ñ$Ñ ÉEÌ Ä ¾W= F D M¼ S U@ºmU@º[ÃL¼ D F ; ?�=�º S VJ< çMO; F º S ; ¾JVOº D M"Á6=zÃNÈ
35
Ë < ºmÂJUNVJÀNÂ"Á D ÂW=zÇ D F º�= S º D M§Á%; ºm F ; P)VJ<>=eºm; UN?"=@?WM§¼ S U@ºmU@º[ÃL¼J; ?JÀWIlºmÂJ; F = S ºm;>»�< D »�UN? Ä» D ?lº S =eº D F UN?®ºm D)à S F º F º D ¼ F P�=NM D ºmUeÁ6= S M F D�½ ¼J< UN; ºm; ?JÀÆáU S P�=@< =@?W=@< à F ; F =@?WM�Ç D S ; à Ä» =eºm; UN?®P D ºmÂJUOM F ; ?�ºm D »�UN?lº D�½ º�U@Æ Ñ$Ñ ÉEÌ F È�X6ÂJ; F =@¼J¼ S Ul=N»�Â�» =@?®¾ D »�UN? F ;>M D S D M�=@?=@< º D S ?W=eºm; Ç D ºmU F ; P)VJ<>=eºm; UN?�¾ D » =@V F D =@< ºmÂJUNVJÀNÂ�Á D = S D ?JU@º6=@< Á6=zà F =@¾J< D ºmU�ÆáVJ< < ÃsÇ D S ; ÆáÃU S =@?W=@< à F D ºm D ¾ D ÂW=zÇL; UNV S U@Æ�= F à F º D P�I D Ç D ?ß¼W= S ºm;>=@<2=@?W=@< à F ; F U S Ç D S ; à » =eºm; UN?Þ» =@?S D Ç D =@< F UNP D�D SmS U S F Á%ÂJ;>»�º D ?WM�ºmU�¾ D MO; â D S D ?lº/Æ S UNPªºm D UN? D F ÆáUNVJ?WM§¾Là F ; P)VJ<>=eºm; UN?Ó K2=@<>ÔNÕzÖ�ÈEã D ¾ D < ; D Ç D ºmÂW=eºUN¾OZ D »�º Ä U S ; D ?lº�=eºm; UN? F ÂJUNVJ<>MY=@< < UeÁäV F ºmU S D <>=eºm; Ç D < à D = F ÃD�½ º S =N»�º6ºm D F VJ¾ F à F º D P F ºmUs¾ D Ç D S ; àWD M"=@?WM§ºmU�=@¾ F º S =N»�º6ºm D ; S F V SmS UNVJ?WMO; ?JÀ F ÈË PsUN?JÀ�ºm D MO; â D S D ?lºx=eºHºm; ºmVWM D F ºmU§¼ D S ÆáU S Ps; ?JÀ�ÆáU S P�=@< =@?W=@< à F ; F U S Ç D S ; à » =eºm; UN?1IV F ; ?JÀ F º�=eº D F ¼W=N» D F =@¼J¼ D = S F ºmU�¾ D ºm D PsU F º F º S =@; ÀNÂlºHÆáU S Á6= S M®Á6=zÃ�ÆáU S ºm D » = F D U@ÆÑ$Ñ ÉEÌ F ÈL: D ºmÂJUOM F ¾W= F D MUN? F º�=eº D F ¼W=N» D F = S Dx¿ VJ; º D VJ?J; Ç D S F =@<}IO» =@?§¾ D =@< PsU F ºEÆáVJ< < Ã=@VOºmUNP�=eº D M�I.=@?WMß=@< < UeÁª= S D <>=eºm; Ç D < à D = F Ãå; Ps¼J< D P D ?lº�=eºm; UN?1ÈiX6 D S D ÂW=zÇ D ¾ D D ?ß¼ S U ļ�U F D M®P�=@?LîMO; â D S D ?lºxÁ6=zà F U@Æ/=@< < D ÇL;>=eºm; ?JÀºm D ; S P�=@; ?ÊM D�à »�; D ?W»�Ã�æçºm D F º�=eº D�D�½ ļJ< U F ; UN?�¼ S UN¾J< D P Ó K2=@<>ÔNÕzÖ�È Ø UNP D U@Æ ºm D F D P D ºmÂJUOM F » =@?�¾ D =NMJ=@¼Oº D M�=@?WM�UN¼Oºm; Ps; Å D MÆáU S ºm D »�UN?lº D�½ º6U@Æ Ñ$Ñ ÉEÌ F IL= F Á D < <}È Ë ¼W= S º/Æ S UNPªºmÂW=eºjIL; º%; F =@< F U)? D » D FmF = S Ã)ºmU F UN< Ç DF UNP D ? D Áμ S UN¾J< D P F =N» »�UNPs¼W=@?LÃL; ?JÀ F º�=eº D F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F = F =�ÆáU S P�=@< ; F P'Á%; ºmÂMOÃL?W=@Ps;>»2; ? F º�=@?lºm;>=eºm; UN?1I F VW»�Â)= F ºm D ¼ S UN¾J< D P5ÂJUeÁʺmU D�è »�; D ?lºm< Ã$M D =@<lÁ%; ºmÂ�;>M D ?lºm; àWD S FU@ÆMOÃL?W=@Ps;>» =@< < Ã=@¼J¼ D = S ; ?JÀ�=@?WM"MO; F =@¼J¼ D = S ; ?JÀs; ? F º�=@?W» D F È
ãé D ?sÁ/U S G ; ?JÀ�Á%; ºm F º�=eº D F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F%Ï U S PsU S D À D ? D S =@< < Ã$U@Æ�=@?LÃ$ÆáU S P�=@< Ä; F PêÁ%; ºmÂÊMOÃL?W=@Ps;>»); ? F º�=@?lºm;>=eºm; UN?®U@Æ F UNP D G ; ?WM®U@Æ/»�UNPs¼�UN? D ?lº F�Ò ; º$; F ? D » D FmF = S çºmU¼W=zÃ"» = S D ÆáVJ<1=eºHº D ?lºm; UN?"ºmUsº S D =eºm; ?JÀ�;>M D ?lºm; àWD S F U@Æ UN¾OZ D »�º F�Ï U S ; ?�À D ? D S =@< F UNP D U@ºm D SG ; ?WM8U@ÆxMOÃL?W=@Ps;>» =@< < ÃÜ=@¼J¼ D = S ; ?JÀÞ=@?WMÐMO; F =@¼J¼ D = S ; ?JÀÊ; ? F º�=@?W» D F�Ò È Ñ ºm D S Á%; F D IP�=@?LÃVJ?J? D » D FmF = S à F º�=eº D F » =@?s¾ D À D ? D S =eº D Ms=@?WM)ºm D F º�=eº D F ¼W=N» D F » =@? D Ç D ?sVJ?J? D » D FmF = S ; < ÃÀ S UeÁкmU�; ? à ?J; º[ÃNÈJX6ÂJ; F ?W=@Ps; ?JÀ)¼ S UN¾J< D Pë» =@?¾ D F UN< Ç D M D ; ºm D S ¾LÃ�; ?lº S UOMOVW»�; ?JÀ F UNP DF UN¼JÂJ; F ºm;>» =eº D M S VJ< D F ÆáU S = FmF ; ÀN?J; ?JÀÊ;>M D ?lºm; àWD S F ºmUÊ; ? F º�=@?W» D F U S ¾LÃÜ?JU@º�»�UN? F ;>M D S ; ?JÀ»�UN?W» S D º D ?W=@P D F U@Æi; ? F º�=@?W» D F ºmUs¾ D ; Ps¼�U S º�=@?lº%Á% D ?"º D F ºm; ?JÀ F º�=eº D F ºmUs¾ D$Dj¿ VW=@<}È
X6 D Á/U S G Á%; ºmÂs; ? F º�=@?W» D ;>M D ?lºm; àWD S F ; ?OìWV D ?W» D F ?JU@ºUN?J< Ã$À D ? D S =eºm; ?JÀ F º�=eº D F ¼W=N» D FU@Æ Ñ$Ñ ÉEÌ F I2¾JVOº�=@< F U8=@?W=@< ÃLÅ ; ?JÀÞºm D P�È%X6ÂJ; F ; F ¾ D » =@V F D Á D ? D D MYºmUܾ D =@¾J< D ºmUM D F » S ; ¾ D§D�½ ¼ D »�º D Mß¼ S UN¼ D S ºm; D F U@Æ%ºm D F à F º D P F ¾ D ; ?JÀ D�½ =@Ps; ? D MßÁ%; ºmÂJUNVOº S D Æ D SmS ; ?JÀºmUʺm D »�UN?W» S D º D ?W=@P D F U@Æ�ºm D ; ? F º�=@?W» D F ; ?LÇNUN< Ç D MÜ; ? F º�=eº D F =@?WM D Ç D ?lº F U@Æ�ºm D ; SF º�=eº D F ¼W=N» D F È.X6 D F D ?W=@P D F = S D F D P�=@?lºm;>» =@< < Ãå?JU@º); Ps¼�U S º�=@?lº�=@?WM�I.Á%ÂW=eº�; F PsU S D IPsUOM D < < D S F » =@?"ÂW= S MO< ÃÁ/U S G UNVOº�Á%ÂW=eº%;>M D ?lºm; àWD S F Á%; < <�¾ D V F D M"; ?�MO; â D S D ?lº F º�=eº D F È
íb?�ºm D = S ºm;>»�< D IWÁ D$à S F º�¼ S D F D ?lº%ºm D P�=@; ?�;>M D = F ¾ D ÂJ; ?WM�ºm D Ñ$Ñ ÉEÌ5ÆáU S P�=@< ; F P�ÈØ VJ¾ F Dj¿ V D ?lºm< ÃYÁ D MO; F »�V FmF ¼�U FmF ; ¾J< D F UN< VOºm; UN? F U@Æ$ºm D ?W=@Ps; ?JÀ8¼ S UN¾J< D Pî= S ; F ; ?JÀÜ; ?F º�=eº D F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F I.ºmUNÀ D ºm D S Á%; ºm F UNP D ÆáV S ºm D S UN¼Oºm; Ps; Åj=eºm; UN? F ºmUÞ¾ D V F D MÁ% D ?)À D ? D S =eºm; ?JÀ6ºm D F D F º�=eº D F ¼W=N» D F Èzïi; ?W=@< < ÃNIjÁ D F VJÀNÀ D F ºi=@?)=@¼J¼ S Ul=N»�ÂxºmU F ¼ D »�; ÆáÃL; ?JÀ¼ S UN¼ D S ºm; D F ºmUs¾ D$D Çe=@< VW=eº D M§UeÇ D S F º�=eº D F%F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F È
ð ñóò�ôöõʵE²�¸¢ò1÷�³Jøßµ2ù�úYúÜûÊü5ø
X6 D Ñ$Ñ ÉEÌ'ÆáU S P�=@< ; F P Ó AC T K�ÔLÝ Ö�; F »�ÂW= S =N»�º D S ; Å D M8¾LÃY= Ø P�=@< < º�=@< GlÄ ¾W= F D MÐUN¾OZ D »�º ÄU S ; D ?lº�=eºm; UN? D ? S ;>»� D MéÁ%; ºmÂ5»�UN?W»�V SmS D ?W»�ÃY=@?WMé¼�UN< ÃLPsU S ¼JÂJ;>»�º S =@? F ; ºm; UN? D�½OD »�VOºm; UN?1IÁ%ÂJ;>»�Â"=@< < UeÁéP D FmF =@À D F D ?WMO; ?JÀWILÁ6=@; ºm; ?JÀ)ÆáU S =@?WM§=N» » D ¼Oºm; ?JÀ S D F ¼�UN? F D F IL» S D =eºm; ?JÀ)? D ÁUN¾OZ D »�º F IN=@?WM�¼ D S ÆáU S Ps; ?JÀ$¼ S ; Ps; ºm; Ç D »�UNPs¼JVOº�=eºm; UN? F È Ë ? D�½ =@Ps¼J< D M D PsUN? F º S =eºm; ?JÀxºm D?JU@º�=eºm; UN?"U@Æ Ñ$Ñ ÉEÌ F ; F%F ÂJUeÁ%?"; ? à ÀNV S Dsý È
36
Stack is_a PN
push: xx
return
x
.()
t
(x|t)
..
return
xt
(x|t)
pop
Main is_a PN
(x|t)t
..5‘ .
s := Stack news
s s
5‘...
.
s syncpop: #wantedToken
s
synchronous portreturn place
class name class ascendant initial markingmessage pattern
object nettransition action
testing arc
transition guard
parameter place
method net
syncpop: x
x := self produce.s push: x
y := s pop.self consume: y
st
3‘.
þ2ÿ � ���L��� d ¤%¤ ¡1¥Ð]m l_ c$^l� ] £������� {Ec$]ma[�lf@qN{��������������_ dLq���� ��� ������_�`[]%dlf aE{b�lf�¬2dO¦H�
X6ÂJ; F�F D »�ºm; UN? S D ¼J S = F D F ºm D ¾W= F ;>»$;>M D = F U@Æ ºm D M D�à ?J; ºm; UN?®U@Æ Ñ$Ñ ÉEÌ F IJÂJUeÁ D Ç D S IMOV D ºmU F ¼W=N» D < ; Ps; º�=eºm; UN? F I�Á%; ºmÂJUNVOº�P�= G ; ?JÀºm D M D F » S ; ¼Oºm; UN?�ÆáU S P�=@<i=@?WM®»�UNPs¼J< D º D Èã D$D�½ ¼J<>=@; ?§ºm D ? D » D FmF = S Ã�?JU@ºm; UN? F UN?J< ÃNÈ Ë ¾J; º�M D D ¼ D S ; ?lº S UOMOVW»�ºm; UN?§ºmU�ºm D Ñ$Ñ ÉEÌÆáU S P�=@< ; F P5» =@?$¾ D ÆáUNVJ?WMx; ? Ó AC T K�ÔLÝ ÖL=@?WM�ºm DED ?lºm; S D M D�à ?J; ºm; UN?�U@Æ Ñ$Ñ ÉEÌ F ; ? Ó T =@?WÔNÕzÖ�È
� �"!$#&%('*) +�,-(.�+�-/,'10�243537698;:Ë ?=<�>@?�ACBEDGFH<I�J"AEKLDMACNPOQAEDGI�JRKSAED�; F =ߺ S ; ¼J< D ÏUT5VXW�Y�VXZ�[M\�YzÒ Á% D S D T ; F = F à F º D PîU@Æ»�<>= FmF D F I W�Y =@?�; ?J; ºm;>=@<1»�<>= FmF IJ=@?WM Z�[M\�Y ºm D ?W=@P D U@Æ =@?�; ?J; ºm;>=@<1UN¾OZ D »�º6Æ S UNP W�Y È
T »�UN?lº�=@; ? F�F D º F U@Æ Ñ$Ñ ÉEÌ D < D P D ?lº F Á%ÂJ;>»�Â�»�UN? F ºm; ºmVOº D »�<>= FmF D F Èí�º"»�UNPs¼ S ; F D F»�UN? F º�=@?lº FR]9^`_1a�b I.Çe= S ;>=@¾J< D F&c&d4e I.? D º D < D P D ?lº FÏ�F VW»�ÂÜ= F ¼J<>=N» D F&f =@?WMʺ S =@? ÄF ; ºm; UN? FRb�Ò I »�<>= FmF D < D P D ?lº F�Ï�F VW»�Â8= F UN¾OZ D »�º�? D º F7^`_hg9b IiP D ºmÂJUOMÜ? D º Fjik_hg9b IF ÃL?W»� S UN?JUNV F ¼�U S º F&amlR_1] I.=@?WMÊP D FmF =@À D F D < D »�ºmU S F&inamo�Ò I.»�<>= FmF D F9]`pqdrasa I1UN¾ ÄZ D »�ºå;>M D ?lºm; àWD S F*^`t�u Ix=@?WM5P D ºmÂJUOMÎ? D ºå; ? F º�=@?W» D ;>M D ?lºm; àWD S F1ikt�u È�ã D M D ?JU@º D_hg9bwvx^`_hg9bnyzik_hg9b =@?WM t�u{vx^`t�u|yzikt�u È6X6 D VJ?J; Ç D S F D~} U@Æ)=@?Ñ$Ñ ÉEÌÍ»�UN?lº�=@; ? F$Ï ? D F º D M Ò ºmVJ¼J< D F U@Æ»�UN? F º�=@?lº F IJ»�<>= FmF D F IO=@?WM"UN¾OZ D »�º%;>M D ?lºm; àWD S F ÈL� D º� t�_hu�vk��r���4�s�������S� }R� ¾ D ºm D F D º�U@Æ =@< <1¾J; ?WMO; ?JÀ F U@Æ Çe= S ;>=@¾J< D F È
� >@?�ACBED9KSAED"�"»�UN? F ; F ºsU@Æ�¼J<>=N» D F =@?WMߺ S =@? F ; ºm; UN? F È Ù Ç D S ÃʼJ<>=N» D ÂW= F�F UNP D ; ?J; ºm;>=@<P�= S G ; ?JÀWÈ Ù Ç D S Ãʺ S =@? F ; ºm; UN?8ÂW= F »�UN?WMO; ºm; UN? F�Ï ;}È D È; ? F » S ; ¾ D Mܺ D F ºm; ?JÀß= S » F�Ò I ¼ S D »�UN? ÄMO; ºm; UN? F§Ï ;}È D Èi; ? F » S ; ¾ D Mß; ?J¼JVOºs= S » F�Ò I.=�ÀNVW= S M�I.=@?8=N»�ºm; UN?1I.=@?WMß¼�U F º�»�UN?WMO; ºm; UN? F§Ï ;}È D È; ? F » S ; ¾ D M�UNVOºm¼JVOºx= S » F�Ò È��1AED@��<�N5KSAED"�)= S D F ; Ps; <>= S ºmUUN¾OZ D »�º�? D º F ¾JVOºjI�; ?å=NMJMO; ºm; UN?1ID =N»�ÂU@Æ1ºm D PëÂW= F = F D º6U@Æ.¼W= S =@P D º D S ¼J<>=N» D F =@?WM§= S D ºmV S ?¼J<>=N» D ÈO: D ºmÂJUOM? D º F » =@?=N» » D FmF ¼J<>=N» D F U@ƺm D =@¼J¼ S UN¼ S ;>=eº D UN¾OZ D »�º�? D º F ; ?®U S M D S ºmU�=@< < UeÁ S VJ?J?J; ?JÀ§P D ºmÂJUOM FºmU�PsUOMO; Æáà F º�=eº D F U@ÆiUN¾OZ D »�º F Á%ÂJ;>»�Â"ºm D Ã"= S D S VJ?J?J; ?JÀ�; ?1È
��� KSBC��IX<KS<���r�L<I�D"�§= S D F ¼ D »�;>=@<2º S =@? F ; ºm; UN? F Á%ÂJ;>»�ÂÜ» =@?J?JU@º à S D =@< UN? D ¾JVOº)UN?J< ÃMOÃL?W=@Ps;>» =@< < Ã�ÆáV F D MåºmU F UNP D U@ºm D S º S =@? F ; ºm; UN? F Á%ÂJ;>»�Âk�m=N»�ºm; Çe=eº D�� ºm D P Æ S UNPêºm D ; SÀNVW= S M F ÇL;>=�P D FmF =@À D F D ?WMO; ?JÀWÈ Ù Ç D S à F ÃL?W»� S UN?JUNV F ¼�U S º D P)¾�UOMO; D F = F D º�U@Æ�»�UN?WMO; ĺm; UN? F I ¼ S D »�UN?WMO; ºm; UN? F I =@?WMß¼�U F º�»�UN?WMO; ºm; UN? F UeÇ D S ¼J<>=N» D F U@Æ�ºm D =@¼J¼ S UN¼ S ;>=eº D UN¾OZ D »�º? D ºjI.=@?WM®ÆáV S ºm D S ="ÀNVW= S M�I1=@?WMÊ= F D º$U@Æ/¼W= S =@P D º D S F È�É= S =@P D º D S F U@Æ6=@?Þ=N»�ºm; Çe=eº D M¼�U S º9�)» =@?®¾ D ¾�UNVJ?WM�ºmU§»�UN? F º�=@?lº F U S VJ?J; àWD M�Á%; ºm®Çe= S ;>=@¾J< D F M D�à ? D M�UN?�ºm D < D Ç D <U@Æiºm D º S =@? F ; ºm; UN?§U S ¼�U S º%ºmÂW=eº�=N»�ºm; Çe=eº D M;�NÈ
37
Ë BE� ���C��; F/F ¼ D »�; àWD Ms¾LÃ�=@?�UN¾OZ D »�ºE? D º Ï =@? D < D P D ?lº/U@Æ ^`_hg9b�Ò IL= F D ºEU@Æ�P D ºmÂJUOM? D º F®Ï = F VJ¾ F D ºU@Æ ik_hg9b�Ò I= F D ºU@Æ F ÃL?W»� S UN?JUNV F ¼�U S º F�Ï = F VJ¾ F D ºU@Æ amlR_1]$Ò I=@?WM®= F D º�U@ÆP D FmF =@À D F D < D »�ºmU S F�Ï = F VJ¾ F D º�U@Æ inamo�Ò »�U SmS D F ¼�UN?WMO; ?JÀsºmU§; º F P D ºmÂJUOM? D º F =@?WM)¼�U S º F È Ñ ¾OZ D »�º? D º F M D F » S ; ¾ D ¼�U FmF ; ¾J< D ; ?WM D ¼ D ?WM D ?lº/=N»�ºm; ÇL; ºm; D F U@Æ�¼W= S ºm;>»�VJ<>= SUN¾OZ D »�º F I@P D ºmÂJUOMs? D º F S D =N»�ºm; UN? F U@Æ¢UN¾OZ D »�º F ºmU$P D FmF =@À D FF D ?lººmUxºm D P Æ S UNP UNVOº F ;>M D I=@?WM�¼�U S º F =@< < UeÁ,ºmU S D PsU@º D < Ãк D F º®=@?WMó»�ÂW=@?JÀ D F º�=eº D F U@Æ�UN¾OZ D »�º F ; ?Í=@?ó=eºmUNPs;>»Á6=zÃNÈWX6 D ; ?J D S ; º�=@?W» D P D »�ÂW=@?J; F PäU@Æ Ñ$Ñ ÉEÌ F =@< < UeÁ F =@?�; ?W» S D P D ?lº�=@< F ¼ D »�; à » =eºm; UN?U@Æ/»�<>= FmF D F ÈWíb?J D S ; º D M®P D ºmÂJUOM F =@?WM F ÃL?W»� S UN?JUNV F ¼�U S º F » =@?å¾ D S D M D�à ? D M®=@?WM®? D ÁP D ºmÂJUOM F =@?WM F ÃL?W»� S UN?JUNV F ¼�U S º F » =@?"¾ D =NMJM D M�È Ë F ; Ps; <>= S P D »�ÂW=@?J; F Pä=@¼J¼J< ; D F ÆáU SUN¾OZ D »�º%? D º�¼J<>=N» D F =@?WM§º S =@? F ; ºm; UN? F È
� ����#&%('h�5 �¡(¢�£P¤".¦¥§'�%(¢�¨�¤"0�-/,50�2r3537698;:X6 D MOÃL?W=@Ps;>»�¾ D ÂW=zÇL; UNV S U@Æ Ñ$Ñ ÉEÌ F »�U SmS D F ¼�UN?WM F ºmUÞºm D®D ÇNUN< VOºm; UN?ÐU@Æ$= F à F º D PU@Æ�UN¾OZ D »�º F È Ë ?n<�>@?�ACBED); F = F à F º D P9U@Æ�? D ºs; ? F º�=@?W» D F Á%ÂJ;>»�Âл�UN?lº�=@; ? F D�½ =N»�ºm< ÃÞUN? D; ? F º�=@?W» D U@ƺm D =@¼J¼ S UN¼ S ;>=eº D UN¾OZ D »�º�? D ºx=@?WM®= F D º�U@Æ/»�V SmS D ?lºm< à S VJ?J?J; ?JÀ§; ? F º�=@?W» D FU@Æ P D ºmÂJUOM�? D º F È Ù Ç D S Ã;KSAED©J�K���DM�KSBCA D ?lº�=@; < F ; º F ;>M D ?lºm; àWD S [M\�ª;t�u =@?WM"=sP�= S G ; ?JÀU@Æ/; º F ¼J<>=N» D F =@?WM�º S =@? F ; ºm; UN? F È Ë¬« �IXJ�K�®1<°¯��R�S� ��BCA�; F ="P)VJ< ºm; F D º$U@Æ D < D P D ?lº F U@ƺm D VJ?J; Ç D S F D5} È Ë DGIX�K���J�DGJ"<K « �IXJ�K�®å; F = F D º�U@Æ6; ?LÇNUO» =eºm; UN? F È Ù Ç D S ñJ�KL²<�BC�DGJ"<K»�UN?lº�=@; ? F =@?);>M D ?lºm; àWD S [M\7ª;ikt�u U@ÆJºm D ; ?LÇNU G D M�? D º; ? F º�=@?W» D =@?WM�= F ºmU S D M�¾J; ?WMO; ?JÀ�4ª � t�_hu U@Æ.ºm D ; ?J¼JVOº�Çe= S ;>=@¾J< D F U@Æiºm D =@¼J¼ S UN¼ S ;>=eº D º S =@? F ; ºm; UN?1ÈË F º�=eº D U@Æ%= S VJ?J?J; ?JÀ Ñ$Ñ ÉEÌ ÂW= F ºm D ÆáU S P U@Æ%= « �IXJ�K�®@ÈiX.U�=@< < UeÁBºm D »�<>= F[ÄF ;>» =@<1É D º S ;�? D º Ä Á6=zÃ�U@Æ P�=@?J; ¼JVJ<>=eºm; ?JÀsP�= S G ; ?JÀ F ILºm D Ã"= S D S D ¼ S D F D ?lº D M"= F P)VJ< ºm; F D º FU@ÆEºmU G D ? D < D P D ?lº F È�íb?åºm D » = F D U@Æ6=º S =@? F ; ºm; UN?åP�= S G ; ?JÀWI�ºm D ;>M D ?lºm; àWD S U@ÆEºm D ; ? ÄÇNU G D M�P D ºmÂJUOM§? D º%; ? F º�=@?W» D ; F%F ºmU S D MÁ%; ºmÂJ; ?§ºm D =@¼J¼ S UN¼ S ;>=eº D ¾J; ?WMO; ?JÀ�; ?�= F ¼ D »�;>=@<Ï V F D S Ä ; ?LÇL; F ; ¾J< D Ò Çe= S ;>=@¾J< Ds³/´µ ÈNX6ÂLV F =�ÆáU S P�=@<W»�UNPs¼W=eºm; ¾J; < ; º[Ã)U@Æ�¼J<>=N» D =@?WM�º S =@? F ; ºm; UN?P�= S G ; ?JÀ F ; F =N»�ÂJ; D Ç D M=@?WM�; º%; F ¼�U FmF ; ¾J< D ºmUsM D�à ? D =�ºmU G D ? D < D P D ?lº%= F =�º S ; ¼J< D »�UN? ÄF ; F ºm; ?JÀ"U@ÆEºm D ;>M D ?lºm; àWD S U@ÆEºm D ? D º$; ? F º�=@?W» D ; º$¾ D < UN?JÀ F ºmUWI¢ºm D =@¼J¼ S UN¼ S ;>=eº D ¼J<>=N» DU S º S =@? F ; ºm; UN?1IJ=@?WM�=@? D < D P D ?lº�U@Æiºm D VJ?J; Ç D S F D U S =s¾J; ?WMO; ?JÀWÈWX6 D ?�Á D » =@? F =zÃ�ÆáU S=�P�= S G ; ?JÀ i ºmÂW=eº �
i¶ª Ó Ï"t�u¬·;f¸· } Ò yÊÏ"t�u¹·¦bº· � t�_hu§Ò Ö@»j¼/½Ë F º D ¼�Æ S UNP'=sP�= S G ; ?JÀ�U@Æ=@? Ñ$Ñ ÉEÌÍ; ?lºmU=@?JU@ºm D S P�= S G ; ?JÀ�» =@?�¾ D M D F » S ; ¾ D M= F ºm D F U Ä » =@< < D M*AE²AEKLD}È Ø VW»�Â�=@? D Ç D ?lº%; F =§¾ Ä ºmVJ¼J< D
g¿vBÏ"À�VH[M\LVHÁ�VC��Ò; ?W»�< VWMO; ?JÀ Ï ý Ò ; º F º[ÃL¼ D À I ÏGÂNÒ ºm D ;>M D ?lºm; àWD S [M\*ªzt�u U@ÆEºm D ? D º�; ? F º�=@?W» D ; º$º�= G D F¼J<>=N» D ; ?1I Ï"ÃlÒ ºm D º S =@? F ; ºm; UN? Á;ª¿b ; º§; F�F º�=eºm;>» =@< < à S D ¼ S D F D ?lº D MܾLÃNIE=@?WM Ï ¾ Ò ºm D¾J; ?WMO; ?JÀ$º S D D � »�UN?lº�=@; ?J; ?JÀ�ºm D ¾J; ?WMO; ?JÀ F V F D MsUN?�ºm D < D Ç D <JU@Æ�ºm D ; ?LÇNU G D M�º S =@? F ; ºm; UN?= F Á D < < = F Á%; ºmÂJ; ?Ê=@< <1ºm D F ÃL?W»� S UN?JUNV F ¼�U S º F�Ï ¼�U FmF ; ¾J< Ã�; ?WMO; S D »�ºm< Ã Ò =N»�ºm; Çe=eº D M"Æ S UNPºmÂW=eºº S =@? F ; ºm; UN?1ÈeX6 D S D = S D ÆáUNV S G ; ?WM F U@Æ D Ç D ?lº F =N» »�U S MO; ?JÀ�ºmU�ºm D Á6=zÃxU@Æ D Çe=@< VW=eºm; ?JÀºm D =N»�ºm; UN?ÊU@Æ2ºm D =@¼J¼ S UN¼ S ;>=eº D º S =@? F ; ºm; UN? �SĦŠ=@?Ê=eºmUNPs;>»s=N»�ºm; UN?å; ?LÇNUN< ÇL; ?JÀ§º S ; ÇL;>=@<»�UNPs¼JVOº�=eºm; UN? F UN?J< ÃNI�Æ Å =? D ÁBUN¾OZ D »�º�; ? F º�=@?lºm;>=eºm; UN?®ÇL;>=�ºm D P D FmF =@À D9ÇLÈ�É I�Ê Å =@?; ? F º�=@?lºm;>=eºm; UN?ÜU@Æ�=ÊÉ D º S ; Ä ? D ºsM D F » S ; ¾ D MßP D ºmÂJUOM�I2=@?WMÌË Å º D S Ps; ?W=eºm; ?JÀÞ=®P D ºmÂJUOM
38
? D º�; ? F º�=@?W» D ÈWí�Æ2=@? D ?W=@¾J< D M D Ç D ?lº g UO» »�V S F ; ?®=�P�= S G ; ?JÀ i =@?WM�»�ÂW=@?JÀ D F ; º�; ?lºmU=�P�= S G ; ?JÀ ikÍ IOÁ D » =@< <�ºmÂJ; F =5��DMAU�Ê=@?WM"M D ?JU@º D ; º�¾LÃ
i Ó gRÎHi Í ½ïJU S =ÀN; Ç D ? Ñ$Ñ ÉEÌ�IW; º F J�KLJ�DGJ"�� « �IXJ�K�® i~Y »�U SmS D F ¼�UN?WM F ºmU§= F ; ?JÀN< D I�; ?J; ºm;>=@< < ÃP�= S G D MsUN¾OZ D »�ºE? D º6; ? F º�=@?W» D Æ S UNP ºm D ; ?J; ºm;>=@<¢»�<>= FmFqW�Y ;>M D ?lºm; àWD M§= FqZ�[M\�Y ÈLX6 D ��AEDq<°¯
���� « �IXJ�K�®�$U@Æ=@? Ñ$Ñ ÉEÌ5; F M D ?JU@º D M�= F�ikd =@?WM§ºm D ��AEDÏ<°¯R����(AE²AEKLD"��= FQgRc Èïi; ?W=@< < ÃNILÁ D ; ?lº S UOMOVW» D ºm D ÆáUN< < UeÁ%; ?JÀ)?JU@º�=eºm; UN?1ÈÑÐ�; Ç D ? [M\7ªÒt�u I�Ó À�Á�Ï@[M\LÒ M D ?JU@º D Fºm D ? D º9Ó ªP_hg9b F VW»�Â�ºmÂW=eº [M\ ;>M D ?lºm; àWD F =@?®; ? F º�=@?W» D U@ÆqÓI�=@?WM Z�[M\�Ï@[M\LÒ M D ?JU@º D F
Z�[M\7ªh^`t�uBF VW»�ÂxºmÂW=eº [M\ ;>M D ?lºm; àWD F =%? D ºi; ? F º�=@?W» D ¾ D < UN?JÀN; ?JÀ%ºmU%ºm D UN¾OZ D »�ºi;>M D ?lºm; àWD M¾Là Z�[M\ ÈzÌ�U@º D ºmÂW=eº =@?$UN¾OZ D »�ºi; F ;>M D ?lºm; àWD M$¾LÃ�ºm D ;>M D ?lºm; àWD S U@ÆJ; º F UN¾OZ D »�º.? D ºi; ? F º�=@?W» D È
Ô Õ*Ö�òØ×YµqÙ[ò µ2ù®±l²�øN³ÑÚ²�¸¢ò ±l¶�ò.²E³J¹MÛ�ò1´Wøé¹H²ÝÜ/³ÑÚi³OòÞÜ6÷4Ú¸¢ò.ø�µ2ùúYúÜûÊü5ø
íb?sºmÂJ; FEF D »�ºm; UN?�ºm D S D ; F ;>M D ?lºm; àWD M�= F ¼ D »�;>=@<J¼ S UN¾J< D P = S ; F ; ?JÀx; ?sºm D »�UN?lº D�½ ºEU@Æ F º�=eº DF ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F I�?W=@P D < Ãåºm D F U Ä » =@< < D Må?W=@Ps; ?JÀ�¼ S UN¾J< D P�= FmF UO»�;>=eº D M®ºmUåM D =@< ; ?JÀÁ%; ºmÂó;>M D ?lºm; àWD S F U@Æ); ? F º�=@?W» D F ºmÂW=eº�» =@?ó¾ D MOÃL?W=@Ps;>» =@< < Ãé» S D =eº D M�=@?WMóMO; F » = S M D M�ÈX6 D S D = S D F VJÀNÀ D F º D M"=@?WM"»�UNPs¼W= S D Mº[Á/UsP D ºmÂJUOM F º S ÃL; ?JÀ�ºmUsPs; ?J; Ps; Å D ºm D ; Ps¼W=N»�ºU@Æ/ºm D ¼ S D F D ?W» D U@Æ/?W=@P D F U@Æ/; ? F º�=@?W» D F ; ? F º�=eº D F VJ¼�UN?ʺm D F º�=eº D F ¼W=N» DsD�½ ¼J< U F ; UN?¼ S UN¾J< D P�È1ï S UNPöºm D ¼�UN; ?lº�U@Æ6ÇL; D Á U@Æ/ºm D ?W=@Ps; ?JÀ�¼ S UN¾J< D P�I Ñ$Ñ ÉEÌ F » =@?Þ¾ D »�UN? ÄF ;>M D S D M�Z[V F º$= S D ¼ S D F D ?lº�=eºm; Ç D U@Æ2ÆáU S P�=@< ; F P F Á%; ºmÂÊMOÃL?W=@Ps;>»); ? F º�=@?lºm;>=eºm; UN?åU@Æ F UNP DG ; ?WM"U@Æ »�UNPs¼�UN? D ?lº F I F VW»�Â�= F UN¾OZ D »�º F U S ¼ S UO» D FmF D F È
ß��"!$#&%('h8;¢�£P¤"¡(à16`,0Lá�â"'�£Ø º�=eº D F ¼W=N» D F » =@?ÞÀ D ? D S =@< < Ã�¾ D M D�à ? D M Ó K2=@<>ÔNÕzÖ/= F ¾ Ä ºmVJ¼J< D F »�UN? F ; F ºm; ?JÀ�U@Æ%= F D º�U@ÆF º�=eº D F IE= F D ºU@Æ F º S VW»�ºmV S =@<6º S =@? F ; ºm; UN? F IE= F D ºU@Æ F D P�=@?lºm;>»§º S =@? F ; ºm; UN? F�Ï ;}È D ÈE< ; ? GOF¾ D º[Á D D ? F º�=eº D F =@?WM F º S VW»�ºmV S =@<Lº S =@? F ; ºm; UN? F�Ò IN=@?WMs=@?s; ?J; ºm;>=@< F º�=eº D ÈNX6ÂJ; F »�UN?W» D ¼OºE» =@?¾ D V F D M�Á% D ?"M D =@< ; ?JÀ)Á%; ºm F º�=eº D F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F�Ï U S =@?LÃsU@ºm D S ÆáU S P�=@< ; F P Á%; ºmÂMOÃL?W=@Ps;>»E; ? F º�=@?lºm;>=eºm; UN? Ò I@= F Á D < <}Èã�UeÁ D Ç D S Ij; ?)ºm D »�UN?lº D�½ º U@Æ F VW»�Â)ÆáU S P�=@< ; F P F ºm D S D= S ; F D F UN? D ? D Áé¼J D ?JUNP D ?JUN?sºmU)¾ D »�UN? F ;>M D S D M�ÈlÉ= S ºm;>»�VJ<>= S < ÃNIe; º/; F ? D » D FmF = S Ã�ºmU)¼W=zû = S D ÆáVJ<W=eºHº D ?lºm; UN?�ºmU D�è »�; D ?lºm< Ã)ÂW=@?WMO< ; ?JÀxºm D ?W=@Ps; ?JÀ$; ?OÆáU S P�=eºm; UN?s¼ S D F D ?lº; ? F º�=eº D F; ?ßU S M D S ?JU@º$ºmU�Á/U S F D ?ÊU S D Ç D ?ʺmU®M D » S D = F D ºm D F º�=eº D F ¼W=N» DsD�½ ¼J< U F ; UN?ʼ S UN¾J< D P�È� D º�V F M D ?JU@º D ºmÂJ; F ¼J D ?JUNP D ?JUN?�= F ºm D KS� « J�K�®`�SIX<�>E� A « È
X6 D ?W=@Ps; ?JÀ�; ?OÆáU S P�=eºm; UN?"¼ S D F D ?lº�; ? F º�=eº D F U@ÆMOÃL?W=@Ps;>» =@< < à F º S VW»�ºmV S D M"PsUOM D < FF D S Ç D F ÆáU S VJ?J; ¿ V D < Ã);>M D ?lºm; ÆáÃL; ?JÀxºm D Z[V F º D�½ ; F ºm; ?JÀ$; ? F º�=@?W» D F U@Æ�MO; â D S D ?lº2PsUOM D <�»�UNP ļ�UN? D ?lº F Á%ÂJ;>»�Â=@< < UeÁ F ºmU F D ¼W= S =eº D ºm D ; S < UO» =@< F º�=eº D F =@?WM D�½ ¼ S D FmF S D Æ D S D ?W» D F =@PsUN?JÀºm D P�ÈjãÊU S G ; ?JÀ%Á%; ºmÂ$; ? F º�=@?W» D ;>M D ?lºm; àWD S F I D È ÀWÈ ; ?xºm D ÆáU S P5U@ÆJ=NMJM S D FmF D F U@ÆOUN¾OZ D »�º F I ; F»�UNPsPsUN?ÊÁ% D ? S VJ?J?J; ?JÀ�UN¾OZ D »�º Ä U S ; D ?lº D M®¼ S UNÀ S =@P F U S F ; P)VJ<>=eºm; ?JÀ�UN¾OZ D »�º Ä U S ; D ?lº D MPsUOM D < F Èqã�UeÁ D Ç D S I; ?Yºm D »�UN?lº D�½ ºU@Æ F º�=eº D F ¼W=N» D F Iºm D ¼ S D F D ?W» D U@Æxºm D ?W=@Ps; ?JÀ; ?OÆáU S P�=eºm; UN?Ü; ? F º�=eº D F » =@? F ; ÀN?J; à » =@?lºm< Ãß»�UN?lº S ; ¾JVOº D ºmU®ºm D F º�=eº D F ¼W=N» D§D�½ ¼J< U F ; UN?¼ S UN¾J< D P�È�X6ÂJ; F ; F MOV D ºmUºm D ¼�U FmF ; ¾J; < ; º[Ã�U@ÆVJ?J? D » D FmF = S ; < Ã"À D ? D S =eºm; ?JÀ�P�=@?Là F º�=eº D FMO; â D S ; ?JÀ�UN?J< Ã�; ?åºm D ?W=@P D F U@Æ2ºm D ; ?LÇNUN< Ç D M�; ? F º�=@?W» D F D Ç D ?Ê; ÆEºm D ?W=@P D F » =@?J?JU@º
39
; ?OìWV D ?W» D ºm D ÆáVOºmV S D ¾ D ÂW=zÇL; UNV S U@Æiºm D F à F º D Pä¾ D ; ?JÀ D�½ =@Ps; ? D M§; ?®=@?LÃÁ6=zÃ Ï VJ¼"ºmUS D ?W=@Ps; ?JÀ Ò È1ãéÂW=eº); F Á/U S F D I F UNP D ºm; P D F ºm D ?W=@Ps; ?JÀ�; ?OÆáU S P�=eºm; UN?ß» =@?ÞP�= G D F º�=eº DF ¼W=N» D F U@Æ D ÇL;>M D ?lºm< à à ?J; º D ÄbF º�=eº D F à F º D P F À S UeÁ ºmUß; ? à ?J; º[ÃÜæ ; º F V è » D F ºmU G D D ¼» S D =eºm; ?JÀß=@?WMÐM D F º S UeÃL; ?JÀåºm D F =@P D ; ? F º�=@?W» D Ï Æ S UNP = F D P�=@?lºm;>» =@<%¼�UN; ?lºU@ÆxÇL; D Á Ò;>M D ?lºm; ÆáÃL; ?JÀ�; º�V F ; ?JÀ F ºm; < <1? D Á5;>M D ?lºm; àWD S F È
Ø º�=eº D F ¼W=N» D S D MOVJ?WMJ=@?W»�; D F = FmF UO»�;>=eº D M$ºmU$Á/U S G ; ?JÀxÁ%; ºmÂ�ºm D ?W=@Ps; ?JÀ$; ?OÆáU S P�=eºm; UN?ÂW=zÇ D º[Á/Uå¼�U FmF ; ¾J< D F UNV S » D F È X6 D§à S F ºsUN? D ; F = F ¼ D »�;>=@< º[ÃßU@Æ�ÆáU S P�=@< ; F P F�F VJ¼J¼�U S º Ä; ?JÀsMOÃL?W=@Ps;>» F º S VW»�ºmV S ; ?JÀ�U@Æ F UNP D G ; ?WM"=@?WM F º D P F Æ S UNPªºm D Á6=zÃsºm D F D ÆáU S P�=@< ; F P F���C��J ®�KÒJ"N�AEKLDGJ ä©AEIC�4DM<RKSAEåÏ� � �I�J���J�K�®jJ�K���DM�KSBCA���È�æ D MOVJ?WMJ=@?lº F º�=eº D F = S ; F D Á% D ?=@?�; ? ÄF º�=@?W» D ¼J<>=zÃL; ?JÀ)=�» D S º�=@; ? S UN< D ; ?�ºm D PsUOM D < < D M F à F º D P Ï ÀN; Ç D ?�¾LÃs; º F º[ÃL¼ D INºm D < UO» =@<F º�=eº D F ; º�» =@? S D =N»�Â1I�U S ºm D Á6=zÃ�; º$; F S D Æ D SmS D M�ºmU Ò » =@?®¾ D » S D =eº D M®VJ?WM D S MO; â D S D ?lº?W=@P D F Á% D ?�ÀNUN; ?JÀxºm S UNVJÀNÂ�MO; â D S D ?lº F º�=eº D F ¼W=N» D ¼W=eºm F < D =NMO; ?JÀxºmU�; º F » S D =eºm; UN?1ÈNX.U; < < V F º S =eº D F VW»�Âß=�» = F D I1Á D » =@?ß»�UN? F ;>M D S ÆáU S D�½ =@Ps¼J< D =�PsUOM D <2U@Æ�=§ì D�½ ; ¾J< D P�=@? ÄVOÆ�=N»�ºmV S ; ?JÀ F à F º D P Ó T K�ÔNÕzÖ6Á%; ºm F D Ç D S =@<2¼ S UOMOVW»�ºm; UN?8» D < < F S D ¼ S D F D ?lº D MÞ¾LÃÊUN¾OZ D »�º FVJ?J; ¿ V D < çMO; F ºm; ?JÀNVJ; F  D M§¾LÃsºm D P�=N»�ÂJ; ? D F ºm D à D ?W» =@¼ F VJ<>=eº D ÈÑæ D MOVJ?WMJ=@?lº F º�=eº D F = S DÀ D ? D S =eº D M$Á% D ?$ºm D F D UN¾OZ D »�º F » =@?�¾ D » S D =eº D M�=@?WM�;>M D ?lºm; àWD M�V F ; ?JÀ�MO; â D S D ?lº»�UNP)¾J; Ä?W=eºm; UN? F U@Æ�?W=@P D F I@¼�U FmF ; ¾J< à S D ì D »�ºm; ?JÀ$ºm D U S M D S ; ?�Á%ÂJ;>»�Âsºm D Ã�Á D S D ; ?WM D ¼ D ?WM D ?lºm< ÃU@Æ D =N»�ÂßU@ºm D S » S D =eº D M�È Ë F ; Ps; <>= S F ; ºmVW=eºm; UN?ÜU@Æ�º D ?Ð= S ; F D F Á% D ?Ð=�P D ºmÂJUOM8» =@?ܾ D; ?LÇNU G D MÁ%; ºm§ºm D F =@P D = S ÀNVJP D ?lº F UeÇ D S ºm D F =@P D UN¾OZ D »�º%ÇL;>=sMO; â D S D ?lº F º�=eº D F ¼W=N» D¼W=eºm F < D =NMO; ?JÀ)ºmUMO; â D S D ?lº�; ?lº D S ?W=@<�;>M D ?lºm; àWD S F U@Æ.ºm D S D F VJ< ºm; ?JÀs; ? F º�=@?W» D È
X6 D F D »�UN?WM$¼�U FmF ; ¾J< D F UNV S » D U@Æ S D MOVJ?WMJ=@?W»�; D F = FmF UO»�;>=eº D M�ºmU�;>M D ?lºm; àWD S F ; F »�UN?W»�V S ÄS D ?lºjI F ÃLPsP D º S ;>» =@<�Á/U S G Á%; ºm F D Ç D S =@<W; ? F º�=@?W» D F ÈLíb?ºmÂJ; F » = F D I F UNP D U@Æ1ºm D F ÃLPsP D ĺ S ; D F D�½ ; F ºm; ?JÀs=@< S D =NMOÃsUN?ºm D < D Ç D <¢U@Æ.ºm D F à F º D P VJ?WM D S ; ?LÇ D F ºm; Àl=eºm; UN?§= S D P�=@¼J¼ D MUN?lºmU§º S D =eºm; ?JÀ�» D S º�=@; ?Ê; ? F º�=@?W» D F ÇL;>=§ºm D ; S ;>M D ?lºm; àWD S F ; ?ß= F ÃLPsP D º S ;>» =@<Á6=zÃNÈ�X6ÂJ; F» =@?®» =@V F D ºmÂW=eº�Á D Á/UNVJ<>M�?JU@º�< ULU F D =@?LÃ"; ?OÆáU S P�=eºm; UN?�=@?WM�Á/UNVJ<>M F =zÇ D F UNP D F ¼W=N» D; Æ/Á D »�UNVJ<>M®; ÀN?JU S D ºm D MO; â D S D ?lºx;>M D ?lºm; àWD S F U@ÆEºm D F D ; ? F º�=@?W» D F =@?WM F Á6=@¼®ºm D Pö; ?F UNP D ¼�UN; ?lº F U@Æ¢ºm D�D ÇNUN< VOºm; UN?sU@Æ¢ºm D PsUOM D < D M F à F º D P�È Ë F =@? D�½ =@Ps¼J< D INÁ D » =@?sº�= G Dºm D F ÃLPsP D º S ;>» =@<6Á/U S G Á%; ºmÂYMO; ?J; ?JÀ Ï MO; F º S ; ¾JVOº D M Ò ¼JÂJ; < U F UN¼J D S F ; ? à ÀNV S D  È2X6 D¼�U FmF ; ¾J; < ; º[ÃsU@Æ D�½ ¼J< UN; ºm; ?JÀ F à F º D P Ä < D Ç D < F ÃLPsP D º S ; D F ÆáU S6S D MOVW»�; ?JÀ F º�=eº D F ¼W=N» D F ; F ?JU@º= F ¼ D »�;>=@< º[Ã�U@ÆWÆáU S P�=@< ; F P F Á%; ºmÂ�MOÃL?W=@Ps;>»/; ? F º�=@?lºm;>=eºm; UN?1Ie¾JVOº2; º F D D P F ºmUx¾ D ; ?lº D S D F º Ä; ?JÀ)ºmÂW=eº�=eº6< D = F º F UNP D U@Æ.ºm D F D F ÃLPsP D º S ; D F P�=@?J; Æ D F º6ºm D P F D < Ç D F ; ?�= F ; Ps; <>= S Á6=zúmU S D MOVJ?WMJ=@?W»�; D F�F º D PsPs; ?JÀʼJV S D < ÃÊÆ S UNP F UNP D ; ?lº D S ?W=@</P D »�ÂW=@?J; F P F U@Æ�MOÃL?W=@Ps;>»F º S VW»�ºmV S ; ?JÀ�=@?WM§Ps; ÀNÂlº%ºmÂLV F ÂJUN¼ D ÆáVJ< < ç¾ D F UN< Ç D M�ºmUNÀ D ºm D S È
X6 D ?W=@Ps; ?JÀß¼ S UN¾J< D P » =@?Y¾ D F UN< Ç D M D ; ºm D S ¾Là S D F º S ;>»�ºm; ?JÀÞºm D F D P�=@?lºm;>» F U@ƺm D =@¼J¼J< ; D M§PsUOM D < < ; ?JÀ�<>=@?JÀNVW=@À D U S ¾Là S D MOVW»�; ?JÀ)ºm D S D F VJ< ºm; ?JÀ F º�=eº D F ¼W=N» D F =@¼J¼ S U ļ S ;>=eº D < ÃNÈ¢ã D ¼ S D Æ D S ºm D F D »�UN?WMå=@¼J¼ S Ul=N»�®Á%ÂJ;>»�ÂÞ=@< < UeÁ F ºmU"V F D MO; â D S D ?lº$P D ºmÂJUOM FÆáU S F UN< ÇL; ?JÀ�ºm D ?W=@Ps; ?JÀs¼ S UN¾J< D Pë; ?�MO; â D S D ?lº�»�UN?lº D�½ º F =@?WM§ºmU�»�UNP)¾J; ? D ºm D PäÁ%; ºmÂP D ºmÂJUOM F º S ÃL; ?JÀ�ºmU S D PsUeÇ D U@ºm D S F UNV S » D F U@Æ F º�=eº D F ¼W=N» D S D MOVJ?WMJ=@?W»�; D F È�ãé D ? S D ÄMOVW»�; ?JÀ F º�=eº D F ¼W=N» D F ºmU�¼ S U@Z D »�º6=zÁ6=zÃ�Á%ÂW=eº/Á D »�UN? F ;>M D S ºmU)¾ D VJ?J? D » D FmF = S Ã)?W=@Ps; ?JÀ; ?OÆáU S P�=eºm; UN?�Á D ÂW=zÇ D ºmU)¼ S UeÇ D ºmÂW=eº6MOUN; ?JÀ$ºmÂJ; F Á D MOU�?JU@º/< U F D =@?LÃlºmÂJ; ?JÀ�U S =eº/< D = F º=@?LÃlºmÂJ; ?JÀ); Ps¼�U S º�=@?lºjÈ Ø VW»�§=�¼ S ULU@Æ1; F ºmU)¾ D ¾W= F D M�UN? F ¼ D »�; ÆáÃL; ?JÀ)Á%ÂW=eº6; ?OÆáU S P�=eºm; UN?; F »�UN? F ;>M D S D M"; Ps¼�U S º�=@?lº�Æ S UNPäºm D ¼�UN; ?lº�U@Æ2ÇL; D ÁÍU@Æ2V F ; ?JÀ F º�=eº D F ¼W=N» D F ÆáU S ÆáU S P�=@<=@?W=@< à F ; F =@?WM"Ç D S ; à » =eºm; UN?1ÈJãéÂW=eº�; F PsU S D I D Ç D ?�; ÆÁ D MOU�?JU@º�< U F D =@?Lç; ?OÆáU S P�=eºm; UN?Á% D ? F UN< ÇL; ?JÀ�ºm D ?W=@Ps; ?JÀ§¼ S UN¾J< D P�IJºm D ?JU@ºm; UN?�U@Æ2; Ps¼�U S º�=@?lº�; ?OÆáU S P�=eºm; UN?®» =@?®¾ DV F D MsÆáU S F ÂJUeÁ%; ?JÀ$ºmÂW=eº F VW»�Â; ?OÆáU S P�=eºm; UN?§» =@?�¾ D�D�½ º S =N»�º D M�Æ S UNP ºm D =@¼J¼ S UN¼ S ;>=eº D < Ã
40
S D MOVW» D M F º�=eº D F ¼W=N» D F ; ?s=@? D�è »�; D ?lº2Á6=zÃNÈ Ï íb?)ºm D »�UN?lº D�½ º U@Æ Ñ$Ñ ÉEÌ F Iz; º; F ?JU S P�=@< < Ã; Ps¼�U S º�=@?lºiºmU�¾ D =@¾J< D ºmU�MO; F ºm; ?JÀNVJ; F Â)¼W= S ºm;>»�VJ<>= S ; ? F º�=@?W» D F ; ? F º�=eº D F I ºmU D�½ ¼ S D FmF ºm D ; SUeÁ%? D S F ÂJ; ¼ S D <>=eºm; UN? F IN=@?WM)ºmU G ?JUeÁÐÂJUeÁ8ºm D Ãs= S D P�=@?J; ¼JVJ<>=eº D Ms¾Là D Ç D ?lº FF V SmS UNVJ?WM Ä; ?JÀܼW= S ºm;>»�VJ<>= S F º�=eº D F È©ã�UeÁ D Ç D S I2Á D = S D V F VW=@< < ÃÐ?JU@º§; ?lº D S D F º D MY; ?éºm D »�UN?W» S D º DÇe=@< V D F U@Æ ;>M D ?lºm; àWD S F V F D M§ÆáU S ; Ps¼J< D P D ?lºm; ?JÀsºm D Z[V F º�P D ?lºm; UN? D M§P D »�ÂW=@?J; F P F È Òíb?)ºmÂJ; FF D »�ºm; UN?)ºm D S D = S D F VJÀNÀ D F º D M)=@?WM�»�UNPs¼W= S D M$º[Á/U�P D ºmÂJUOM F ÆáU S F UN< ÇL; ?JÀ�ºm D?W=@Ps; ?JÀ®¼ S UN¾J< D P �/Ï ý Ò V F ; ?JÀ F UN¼JÂJ; F ºm;>» =eº D MÞ?W=@Ps; ?JÀ S VJ< D F ÆáU S = FmF ; ÀN?J; ?JÀ�;>M D ?lºm; àWD S FºmU�? D Á%< ç= S ; F ; ?JÀs; ? F º�=@?W» D F ; ? F ¼J; S D M§¾Lúm D Á6=zÃU@ÆiÂW=@?WMO< ; ?JÀ�¼ S UO» D FmF ;>M D ?lºm; àWD S F ; ?Ø ¼J; ? Ó ã�UN<>ÔLÝ Ö%=@?WM ÏGÂNÒ ºm D F U Ä » =@< < D MÊ?W=@P D =@¾ F º S =N»�ºm; UN?ß= F = F ¼ D »�;>=@< ; Åj=eºm; UN?ÞU@Æ%ºm D
F ÃLPsP D º S Ã$P D ºmÂJUOM�ÆáU SS D MOVW»�; ?JÀ F º�=eº D F ¼W=N» D F Ó T D ?WÔ�¾JI C/× ï�ã�ÔLÝjÖ�ÈeX6 D <>=eºHº D S P D ºmÂJUOM; F ¾W= F D M®UN?®?JU@º$»�UN? F ;>M D S ; ?JÀ"»�UN?W» S D º D ?W=@P D F U@ÆE; ? F º�=@?W» D F ºmU"¾ D ; Ps¼�U S º�=@?lºxÁ% D ?»� D » G ; ?JÀ F º�=eº D F ºmU§¾ D�Dj¿ VW=@<}I�Á%ÂJ;>»�®< D =NM F ºmU§Á/U S G ; ?JÀ�Á%; ºm S D ?W=@Ps; ?JÀ Dj¿ VJ; Çe=@< D ?W» D»�<>= FmF D F U@Æ F º�=eº D F S =eºm D S ºmÂW=@?åÁ%; ºm®ºm D ; ?WMO; ÇL;>MOVW=@< F º�=eº D F È�Û/U@ºmÂåU@Æ2ºm D F D P D ºmÂJUOM FºmUNÀ D ºm D S Á%; ºm®ºm D ; S ¼ S U F =@?WMå»�UN? F = S D MO; F »�V FmF D M�; ?®ºm D ÆáUN< < UeÁ%; ?JÀ§; ?®ºm D »�UN?lº D�½ ºU@Æ Ñ$Ñ ÉEÌ F ÈSã�UeÁ D Ç D S I à S F º�U@Æ/=@< <}I�Á D M D�à ? D ÆáVJ< < F º�=eº D F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F ; ?®U S M D SºmU�UN¾Oº�=@; ?�=�¾W= F ; F ºmUs¾ D S D MOVW» D M"V F ; ?JÀsUN? D U@Æiºm D P D ?lºm; UN? D M§P D ºmÂJUOM F ÈØ ºm; < <�¾ D ÆáU S D MO; F »�V FmF ; ?JÀ�ºm D º[Á/U)P D ?lºm; UN? D M�¼ S ; ?W»�; ¼J< D F ; ?PsU S D M D º�=@; <�Á D F ÂJUNVJ<>M?JU@º D ºmÂW=eº2ºm D ¼ S UN¾J< D PBºm D à F ÂJUNVJ<>M F UN< Ç D » =@?J?JU@ºE¾ D =zÇNUN;>M D M�¾Là F ; Ps¼J< Ã�¼ S D F D ?lºm; ?JÀ=@?å=@< ÀNU S ; ºmÂJPäÆáU S º S =@? F ÆáU S Ps; ?JÀ�ºm D ÆáU S P�=@< ; F P'Á%; ºmÂÊMOÃL?W=@Ps;>»�; ? F º�=@?lºm;>=eºm; UN?�VJ?WM D S¿ V D F ºm; UN?§; ?lºmU F UNP D G ; ?WM§U@Æ.< UeÁ Ä < D Ç D <WÆáU S P�=@< ; F P Á%ÂJ;>»� F ÂJUNVJ<>M F D S Ç D = F =)¾W= F ; F ÆáU SÆáU S P�=@<L=@?W=@< à F ; F È ãé D ?)Á D ÆáU S D�½ =@Ps¼J< D º S Ã�ºmU�º S =@? F ÆáU S P5UN¾OZ D »�º Ä U S ; D ?lº D M$É D º S ;l? D º F; ?lºmU F UNP D G ; ?WM�U@ÆR�H¼J<>=@; ? � ÂJ; ÀNÂ Ä < D Ç D <.? D º F I�= F ÆáU S D�½ =@Ps¼J< D ; ? Ó Ø Û6Ô�¾eÖ�I�ºm D S D P)V F º=@¼J¼ D = S =)»�UN? F º S VW»�ºm; UN?�À D ? D S =eºm; ?JÀ�;>M D ?lºm; àWD S F Á%ÂJ;>»�Â�ºm D ?¾ D »�UNP D =�MO; F ºm; ?JÀNVJ; F ÂJ; ?JÀ¼W= S º"U@Æ$ºmVJ¼J< D F S D ¼ S D F D ?lºm; ?JÀߺmU G D ? F U@Æ�U S ; ÀN; ?W=@< < ÃYMO; â D S D ?lº"? D º�; ? F º�=@?W» D F ÆáUN<>M D MºmUNÀ D ºm D S ÈWX6ÂLV F ºm D ¼ S UN¾J< D PäU@Æ?W=@Ps; ?JÀ; F » = SmS ; D M"; ?lºmU�ºm D MOUNP�=@; ?�U@Æ?JUN? Ä UN¾OZ D »�º? D º F =@?WM§P)V F º�¾ D F UN< Ç D MÁ%; ºmÂJ; ?�ºm D ; S =@?W=@< à F ; F ¼ S UO» D FmF È
ß�����ç/-(â"âQ) +�¢Ñ+�'*) è�¢�.�'�:70�2r3537698;:ïJVJ< < F º�=eº D F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F » =@?ß¾ D M D�à ? D MÞV F ; ?JÀ�ºm D À D ? D S =@<E»�UN?W» D ¼Oº�U@Æ F º�=eº DF ¼W=N» D F P D ?lºm; UN? D M§=@¾�UeÇ D ÈlïJU S =�ÀN; Ç D ? Ñ$Ñ ÉEÌ�I F º�=eº D F Á%; < <�»�U SmS D F ¼�UN?WM)ºmU S D =N»�ÂW=@¾J< DP�= S G ; ?JÀ F =@?WM F º S VW»�ºmV S =@<2º S =@? F ; ºm; UN? F ºmUå=@¼J¼J< ;>» =@¾J< DD Ç D ?lº F È ØLD P�=@?lºm;>»�º S =@? F ; ºm; UN? FÁ%; < <2¾ D M D�à ? D MÊ; ?ß=N» »�U S MJ=@?W» D ºmU"ºm Dsà S ; ?JÀ S VJ< D F U@Æ Ñ$Ñ ÉEÌ F È�ïi; ?W=@< < ÃNI�ºm D ; ?J; ºm;>=@<F º�=eº D Á%; < <1¾ D ºm D ; ?J; ºm;>=@<1P�= S G ; ?JÀWIOU@Æ »�UNV S F D È�¦'�é�¡(¤@+�¤"0�¡º!¿ê°ç/-(â"âQ) +�¢Ñ+�'~) è�¢�.�'�:70�243537698;:ë��
ì/AEDj�Kk<�>@?�ACBEDGFH<I�J"AEKLDMACN~OQAEDGI�J&KSAED ^9^`f9_ åmJ�D@�íJ�D"�Ò��AED7<°¯ « �IXJ�K�®�Ò� �rî J�D"�J�KLJ�DGJ"�� « �IXJ�K�® i~Yî �KSNRJ�D"����AEDs<°¯`AE²AEKLD"� gRc >CAQ®�J�²AEKSï�ð;A`N�A"äsKSArD@��A Ï ÆáVJ< < Ò2F º�=eº DF ¼W=N» D <°¯ ^9^`f9_ DM<5>CA&D@��A4ñ�FMDG���S� A a�ÁHaSò¦vÎÏGa�VHb�VCó5VCi~YzÒ ���LBC�¦D@���DMôõ ï a±v Ó i~Y�Î ïö ï b÷vk�LÏGizø�VXg7VCi±ù ÒϪ;az·ÒgRcØ·haÌ��izø Ó gRÎHi±ù � ïú ï©û izø�VCi±ù`ª;ikd û g¸ªÒgRc Ó ÏGizøVXg7VCi±ù ÒϪ¦bíü ÏGizø�VjÏGizø�VXg7VCi±ùjÒ�VCi±ùjÒ©ªhó Ö°ïË »�UN? F Dj¿ V D ?W» D U@ÆEºm D M D�à ?J; ºm; UN?ÞU@ÆEÆáVJ< < F º�=eº D F ¼W=N» D F U@Æ Ñ$Ñ ÉEÌ F ; ÀN?JU S ; ?JÀ§ºm D?W=@Ps; ?JÀ�¼ S UN¾J< D P5; F ºmÂW=eºiÁ% D ?�Á D º S Ã�ºmU�» S D =eº D ºm D2à S F º.; ? F º�=@?W» D U@Æ F UNP D ? D ºiÁ%ÂJU F D
41
MOUNP�=@; ?$U@ÆO; º F ; ? F º�=@?W» D ;>M D ?lºm; àWD S F ; F ; ? à ?J; º D Á D ; PsP D MO;>=eº D < Ã�UN¾Oº�=@; ?$; ? à ?J; º D < ÃxP�=@?Lü�U FmF ; ¾J< D º�= S À D º�P�= S G ; ?JÀ F ÈJ:�U S D UeÇ D S I S Dj¿ VJ; S ; ?JÀ F D º F U@Ƽ�U FmF ; ¾J< D ;>M D ?lºm; àWD S F U@Æ? D º FºmU�¾ D%à ?J; º D Á%; < <�?JU@º F UN< Ç D ºm D ¼ S UN¾J< D P ¾ D » =@V F D Ï ý Ò ; º6» =@?�»�ÂW=@?JÀ D ºm D F D P�=@?lºm;>» F U@ƺm D PsUOM D <L¾LÃ$= S ºm; à »�;>=@< < à S D F º S ;>»�ºm; ?JÀ�ºm D ?LVJP)¾ D S U@ÆW»�UN?W»�V SmS D ?lºm< à D�½ ; F ºm; ?JÀ�; ? F º�=@?W» D F=@?WM ÏGÂNÒ ºm D S D » =@? F ºm; < <1¾ D À D ? D S =eº D MVJ?J? D » D FmF = S ; < Ã�P�=@?LÃ�º�= S À D º%P�= S G ; ?JÀ F È
ß���ßþý¦:�¤"¡(àP)�0Lè�%(¤":�+�¤".�¢Ñ+�'�ÿí8;¢�£P¤"¡(à��5-(â"'�:Ø UN¼JÂJ; F ºm;>» =eº D M S VJ< D F ÆáU S = FmF ; ÀN?J; ?JÀ�;>M D ?lºm; àWD S F ºmU$? D Á%< Ã)= S ; F ; ?JÀx; ? F º�=@?W» D F =eºHº D Ps¼OººmUM D » S D = F D ºm D M D À S D D U@Æ/?JUN?WM D º D S Ps; ?J; F P ¼�U@º D ?lºm;>=@< < î¼ S D F D ?lº$; ?åºm D P�=@?W=@À D P D ?lºU@Æ¢?W=@P D F U@Æ1MOÃL?W=@Ps;>» =@< < Ã)= S ; F ; ?JÀ$=@?WM�MO; F =@¼J¼ D = S ; ?JÀx; ? F º�=@?W» D F =@?WM�ºmÂLV F ºmU�M D » S D = F Dºm D ?LVJP)¾ D S U@Æ S D =N»�ÂW=@¾J< D F º�=eº D F ÈX6 D F ; Ps¼J< D F º�?JUN?lº S ; ÇL;>=@< S VJ< D ÆáU S ?W=@Ps; ?JÀ; ? F º�=@?W» D F ; F = FmF ; ÀN?J; ?JÀs;>M D ?lºm; àWD S F =N» Ä»�U S MO; ?JÀ�ºmU F UNP D U S M D S ; ?JÀUeÇ D S ºm D P�È Ë M D�à »�; D ?W»�Ã�U@Æ2ºmÂJ; F =eºHºm; ºmVWM D ; F ºmÂW=eºxÁ% D ?Á D = S D »�ÃO»�< ;>» =@< < Ã)» S D =eºm; ?JÀ$=@?WM�M D F º S UeÃL; ?JÀ F UNP D ; ? F º�=@?W» D Á D Á%; < <JUN¾Oº�=@; ?�=@?�; ? à ?J; º DF º�=eº D F ¼W=N» D ÈzX6ÂJ; F » =@?)¾ D F UN< Ç D Mx¾Là S D »�ÃO»�< ; ?JÀ�;>M D ?lºm; àWD S F ; PsP D MO;>=eº D < Ã�=eÆ�º D S ºm D Ã�= S DS D < D = F D M�Ie;}È D ÈN¾LÃ);>M D ?lºm; ÆáÃL; ?JÀ�? D Á%< Ã�= S ; F ; ?JÀx; ? F º�=@?W» D F ¾LÃ�ºm D F P�=@< < D F ºE=@?WMs»�V SmS D ?lºm< Ã?JU@º�V F D M�;>M D ?lºm; àWD S F ÈSã�UeÁ D Ç D S I D Ç D ?�ºm D ?®ºm D S D » =@?�¾ D À D ? D S =eº D M�P�=@?LÃ�MO; â D S D ?lºF º�=eº D F Á%ÂJ;>»�Â�= S D UN¾LÇL; UNV F < à F D P�=@?lºm;>» =@< < à Dj¿ VW=@<}È Ø VW»�Âs= F ; ºmVW=eºm; UN?�= S ; F D F Á% D ? F UNP D»�UN? à ÀNV S =eºm; UN?)U@Æ�; ? F º�=@?W» D F »�ÂW= S =N»�º D S ; Å D M$¾LÃ$ºm D ?LVJP)¾ D S U@Æ�ºm D ; ?LÇNUN< Ç D M�; ? F º�=@?W» D F Iºm D ; S º[ÃL¼ D F Ilºm D ; S º S ; ÇL;>=@<¢P�= S G ; ?JÀWIO=@?WMºm D ; S P)VOºmVW=@< S D <>=eºm; UN? F » =@?§¾ D S D =N»� D MÇL;>=F D Ç D S =@< F º�=eº D F ¼W=N» D ¼W=eºm F ; ?ÊÁ%ÂJ;>»�Âåºm D ; ? F º�=@?W» D F = S D » S D =eº D M®; ?ÞMO; â D S D ?lº$U S M D S F=@?WMsV F ; ?JÀ�Çe= S ; UNV F =@V ½ ; < ;>= S Ã); ? F º�=@?W» D F Á%; ºm§MO; â D S D ?lºm< Ã�UeÇ D S <>=@¼J¼ D M�< ; Æ D ºm; P D F ÈLX6 D ?ºm D S D » =@?ʾ D À D ? D S =eº D M F D Ç D S =@< F º�=eº D F »�UN?lº�=@; ?J; ?JÀ"ºm D ÀN; Ç D ?Þ»�UN? à ÀNV S =eºm; UN?åU@Æ6; ? ÄF º�=@?W» D F =@?WM�MO; â D S ; ?JÀ�UN?J< Ã�; ?�ºm D ?W=@P D F U@Æ F UNP D U@ÆOºm D ; ?LÇNUN< Ç D MxVJ?J; ?lº D S »�ÂW=@?JÀ D =@¾J< D; ? F º�=@?W» D F$Ï MO; F ºm; ?JÀNVJ; F  D M"¾LÃ�ºm D ; S »�UN?lº D ?lº F U S ¾LÃ�ºm D Á6=zÃsºm D Ã"= S D S D Æ D SmS D M�ºmU Ò ÈX6 D Z[V F º M D F » S ; ¾ D M$¼ S UN¾J< D P5U@ÆJÀ D ? D S =eºm; ?JÀ�VJ?J? D » D FmF = S à F º�=eº D F » =@?�¾ D M D » S D = F D M¾LÃ�V F ; ?JÀ�P)VOºmVW=@< < Ã�; ?WM D ¼ D ?WM D ?lº F Dj¿ V D ?W» D F U@Æ�;>M D ?lºm; àWD S F ÆáU S D =N»�Âsº[ÃL¼ D U@Æ�; ? F º�=@?W» D ÈX6 D F D F Dj¿ V D ?W» D F P)V F ºjILU@Æ.»�UNV S F D IN¾ D MO; F Z[UN; ?lºjIlÁ%ÂJ;>»�Â"» =@?�¾ D =N»�ÂJ; D Ç D M�ÆáU S D�½ =@Ps¼J< DÇL;>=)P�= G ; ?JÀ�º[ÃL¼ D F U@Æ.; ? F º�=@?W» D F =�¼W= S º6U@Æ1ºm D ; S ; ? F º�=@?W» D ;>M D ?lºm; àWD S F ÈLíb? F VW»�Â"=�» = F D I; ÆiÁ D » S D =eº D ºm D�à S F º6; ? F º�=@?W» D U@Æi=)? D ºQÓ ø =@?WM�ºm D ?§ºm D�à S F º6; ? F º�=@?W» D U@Æi=)? D ºQÓ ù Iºm D ÃÊÁ%; < <2?JU@º)¾ D ;>M D ?lºm; àWD M ý =@?WM ÂÞÏ Á%ÂJ;>»�ÂßÁ/UNVJ<>MÊVJ?WM D F ; S =@¾J< à S D ì D »�º�ºm D U S M D S; ?�Á%ÂJ;>»�Â�ºm D ; ? F º�=@?W» D F Á D S D » S D =eº D M Ò IW¾JVOº�ÆáU S D�½ =@Ps¼J< D Ï Ó øV ý Ò =@?WM Ï Ó ù�V ý Ò È Ë Æ�º D SF VW»�Âß=@?ßUN¼Oºm; Ps; Åj=eºm; UN?Þ?W=@Ps; ?JÀ S D MOVJ?WMJ=@?W»�; D F = S ; F D UN?J< Ãå; Æ%ºm D S D =@¼J¼ D = S MO; â D S D ?lºU S M D S F U@Æ» S D =eºm; ?JÀ�; ? F º�=@?W» D F U@Æiºm D F =@P D º[ÃL¼ D IJÁ%ÂJ;>»�Â�» =@?"¾ D < D FmF Æ S Dj¿ V D ?lºjÈË F ; Ps; <>= S ¼ S ; ?W»�; ¼J< D ºmUºm D =@¾�UeÇ D » =@?å¾ D V F D M�ºmU�=N»�ÂJ; D Ç D =�ÆáV S ºm D S�S D MOVW»�ºm; UN?U@Æ/?W=@Ps; ?JÀ S D MOVJ?WMJ=@?W»�; D F ; ?ʺm D = S D =§U@Æ/;>M D ?lºm; ÆáÃL; ?JÀ�P D ºmÂJUOMÊ? D º�; ? F º�=@?W» D F È ã D S D IÁ D » =@? G D D ¼�= FmF ; ÀN?J; ?JÀx;>M D ?lºm; àWD S F ºmU�P D ºmÂJUOMs? D ºE; ? F º�=@?W» D F ; ?WM D ¼ D ?WM D ?lºm< Ã)ÆáU S D =N»�º S =@? F ; ºm; UN?�=@?WM§; º F ; ?J¼JVOº�¼W= S º%¾J; ?WMO; ?JÀsV F D M"Á%; ºmÂJ; ? F UNP D Ê D Ç D ?lºjÈJX6ÂJ; F ; F ¼�U FmF ; ¾J< DMOV D ºmU D =N»�ÂÐP D ºmÂJUOMÐ? D º§; ? F º�=@?W» D ; F S D Æ D S D ?W» D M8UN?J< ÃßÆ S UNP ºm D P�= S G ; ?JÀÞU@Æ�ºm Dº S =@? F ; ºm; UN?ßÁ%ÂJ;>»� F º�= S º D Mß; º�=@?WMÞºm D =@¼J¼ S UN¼ S ;>=eº D P�= S G ; ?JÀ D < D P D ?lºs»�UN?lº�=@; ? F ºm D¾J; ?WMO; ?JÀ�U@Æ/ºm D º S =@? F ; ºm; UN?ÊV F D MÊÁ% D ? F º�= S ºm; ?JÀ"ºm D P D ºmÂJUOM�È/ã�UeÁ D Ç D S I¢; º�; F =@Àl=@; ?? D » D FmF = S à F U�ºmÂW=eº%ºm D MO; â D S D ?lº F Dj¿ V D ?W» D F U@Æ ¼�U@º D ?lºm;>=@<�;>M D ?lºm; àWD S F = S D MO; F Z[UN; ?lºjÈX.U�; < < V F º S =eº D À D ? D S =eºm; ?JÀ�ÂJUeÁ5P�=@?LÃ"VJ?J? D » D FmF = S à F º�=eº D F Á D » =@?�=zÇNUN;>M)Z[V F º�ÇL;>==NMJMO; ?JÀ�ºm D <>= F ºUN¼Oºm; Ps; Åj=eºm; UN?�=@¾�UeÇ D ºmU�ºm D ¼ S D ÇL; UNV F UN? D F IzÁ D » =@?)V F D ºm D ÆáUN< < UeÁ%; ?JÀMJ=eº�=JÈ¢íb?åºm D » = F D U@Æ2ºm D F à F º D PêU@Æ Ã MO; F º S ; ¾JVOº D Må¼JÂJ; < U F UN¼J D S F Æ S UNP à ÀNV S D  I¢Á D
42
UN¾Oº�=@; ?éÕ ý Â Ý F º�=eº D F ; ? F º D =NMÐU@Æ)ÝeÔ Â Ô Â UN? D F È Ø ; Ps; <>= S < ÃNI ÆáU S = F ; Ps¼J< D F à F º D P U@Æ ÃS D F º�= S º�=@¾J< D »�ÃO»�< ;>»6»�UNVJ?lº D S F Æ S UNP Ó KU@Z����jÖ�I@Á D UN¾Oº�=@; ? à ¾ Â�Ã Ý F º�=eº D F ; ? F º D =NM)U@Æ���� ý��Oý Èã�UeÁ D Ç D S I�Á D F ÂW=@< <?JU@º D ºmÂW=eº D Ç D ?ÊÁ% D ?Þ=@¼J¼J< ÃL; ?JÀ�=@< <iºm D =@¾�UeÇ D  D V S ; F ºm;>» F ºm D S D» =@? F ºm; < < S D P�=@; ? F UNP D S D MOVJ?WMJ=@?W»�; D F ÈqÐ D ? D S =@< < ÃNIiºm D F D S D MOVJ?WMJ=@?W»�; D F�F º D P9Æ S UNPÏ ý Ò ºm D P D »�ÂW=@?J; F P F U@Æ= FmF ; ÀN?J; ?JÀ�?W=@P D F ºmU�UN¾OZ D »�º F Æ S UNPëºm D F =@P D »�<>= FmF D F =@?WM§ºmUP D ºmÂJUOMs? D ºE; ? F º�=@?W» D FEF º�= S º D M�VJ?WM D S ºm D F =@P D ¾J; ?WMO; ?JÀ�U@Æ¢ºm D F =@P D º S =@? F ; ºm; UN?�=@?WMÆ S UNP ÏGÂNÒ P�=@¼J¼J; ?JÀ F à F º D P Ä < D Ç D < F ÃLPsP D º S ; D F)Ï ;}È D È F ÃLPsP D º S ; D F D�½ ; F ºm; ?JÀ§=@< S D =NMOçUN?ºm D < D Ç D <�U@Æ PsUOM D < D M F à F º D P F�Ò UN?lºmUsÁ/U S G ; ?JÀ�Á%; ºmÂ�; ? F º�=@?W» D ;>M D ?lºm; àWD S F ÈX6 D ¼ S UN¾J< D PëU@ÆÀ D ? D S =eºm; ?JÀ�VJ?J? D » D FmF = S à F º�=eº D F IJÁ%ÂJ;>»�Â�» =@?�ÂW= S MO< þ D =zÇNUN;>M D MD Ç D ?ÞVJ?WM D S =NMOÇe=@?W» D MÊ?W=@Ps; ?JÀ F »� D P D F I.» =@?Þ¾ D =@< < D ÇL;>=eº D MåºmU F UNP D M D À S D D Á% D ?V F ; ?JÀÞ¼W= S ºm;>=@<%U S M D SsS D MOVW»�ºm; UN?8º D »�ÂJ?J; ¿ V D F�Ï =@< F U G ?JUeÁ%?Y= F »�UNPsP)VOº�=eºm; ÇL; º[Ã Ä ¾W= F D MP D ºmÂJUOM F�Ò Ó K2=@<>ÔNÕzÖ�È6X6ÂJ; F ; F ¾ D » =@V F D ºm D F D º D »�ÂJ?J; ¿ V D F S D MOVW» D ?LVJP)¾ D S F U@Æ�¼W=eºm F< D =NMO; ?JÀ$ºmU)¼W= S ºm;>»�VJ<>= S F º�=eº D F =@?WMsºmÂLV F =@< F U�¼�U FmF ; ¾J; < ; ºm; D F ºmU)UN¾Oº�=@; ?MO; â D S D ?lº/¼ D S P)V ĺ�=eºm; UN? F U@Æ%;>M D ?lºm; àWD S F U@Æ6ºm D ; ?LÇNUN< Ç D MÊ»�ÂW= S =N»�º D S ; F ºm;>»s; ? F º�=@?W» D F È.Ì D Ç D S ºm D < D FmF I1ºm D¼ S UN¾J< D PÍ; F ?JU@ºiÆáVJ< < à F UN< Ç D MxºmÂJ; F Á6=zÃx= F ; º ; F ?JU@º=@< Á6=zà F ¼�U FmF ; ¾J< D ºmUx»�ÂJULU F D UN?J< ÃxUN? D; ?lº D S < D =zÇL; ?JÀ$UNVOºEU@Æ.= F D º/U@Æ¢ºm D ¼�U FmF ; ¾J< D UN? D F ÈlÉ= S ºm;>=@<JU S M D S º D »�ÂJ?J; ¿ V D F » =@?�; ÀN?JU S DMO; â D S D ?lº6U S M D S F U@Æ.=N»�ºm; UN? F UN?J< Ãs; ?ºm D » = F D ºm D Ã= S D ; ?LÇL; F ; ¾J< D Ï Á$È S È ºjÈlºm D ¼ S UN¼ D S º[þ D ; ?JÀ�»� D » G D M Ò =@?WMåMOU�?JU@º�»�UN< < ;>M D È�ïJV S ºm D S PsU S D I à ?WMO; ?JÀ�UN¼Oºm; P�=@< F ºmVJ¾J¾�U S ? F D º F» =@?å¾ D ºmULU§ºm; P D Ä »�UN? F VJPs; ?JÀ"=@?WM F U"=@?Ê=@¼J¼ S U ½ ; P�=eºm; UN?®; F U@Æ�º D ?åº�= G D ? Ï D F ¼ D »�;>=@< < Ã; ?ºm D » = F D U@Æ.ÂJ; ÀNÂ Ä < D Ç D <WÆáU S P�=@< ; F P F�Ò ÈLïi; ?W=@< < ÃNI F U�Æ�= S Á D ÂW=zÇ D UN?J< û�UN? F ;>M D S D Msºm Dà S F º/¼�U FmF ; ¾J< D F UNV S » D U@Æ S D MOVJ?WMJ=@?W»�; D F = FmF UO»�;>=eº D M�ºmU�; ? F º�=@?W» D ;>M D ?lºm; àWD S F æ!?W=@P D < Ã= FmF ; ÀN?J; ?JÀ§;>M D ?lºm; àWD S F ºmU"; ? F º�=@?W» D F ¾ D ; ?JÀ�» S D =eº D M�È ã�UeÁ D Ç D S IJºm D S D ; FxF ºm; < < ºm D ¼�U F[ÄF ; ¾J; < ; º[îU@Æ6P�=@¼J¼J; ?JÀ F à F º D P Ä < D Ç D < F ÃLPsP D º S ; D F UN?lºmU F ÃLPsP D º S ;>» =@<Á/U S G Á%; ºm F UNP D; ? F º�=@?W» D F ÇL;>=�ºm D ; S ;>M D ?lºm; àWD S F IOÁ%ÂJ;>»�Â"P�= G D F ; º�¼�U FmF ; ¾J< D ºmU S D MOVW» D F º�=eº D F ¼W=N» D F ¾LÃF Á6=@¼J¼J; ?JÀåºm D S UN< D F U@Æ F VW»�ÂÐ; ? F º�=@?W» D F�Ï ºmÂLV F ; ÀN?JU S ; ?JÀ®ºm D ; S MO; â D S D ?lº�;>M D ?lºm; àWD S F�Ò; ? F UNP D ¼�UN; ?lº F U@ÆEºm D�D ÇNUN< VOºm; UN?åU@Æ2ºm D F à F º D P F ¾ D ; ?JÀ D�½ =@Ps; ? D M�È�Ú�?OÆáU S ºmVJ?W=eº D < ÃNIF UN¼JÂJ; F ºm;>» =eº D MÜ?W=@Ps; ?JÀ S VJ< D F I D Ç D ?8Á% D ?Y»�UNP)¾J; ? D MÜÁ%; ºmÂмW= S ºm;>=@< Ä U S M D S)S D MOVW»�ºm; UN?P D ºmÂJUOM F IW» =@?J?JU@º%¼ S UeÇL;>M D F VW»�Â�= S D MOVW»�ºm; UN?1ÈË » D S º�=@; ? G ; ?WM�U@Æ F UN¼JÂJ; F ºm;>» =eº D M�?W=@Ps; ?JÀ S VJ< D F�F ; Ps; <>= S ºmUºm D =@¾�UeÇ D ÂW= F U S ; ÀN; Ä?W=@< < ç¾ D D ?�V F D M"ÆáU S F UN< ÇL; ?JÀ�ºm D ?W=@Ps; ?JÀ�¼ S UN¾J< D Pä; ?�ºm D =@< S D =NMOÃP D ?lºm; UN? D M F º�=eº DF ¼W=N» D ºmULUN< Ø ¼J; ? Ó ã�UN<>ÔLÝ Ö�È Ø ¼J; ?�Á/U S GOF Á%; ºmÂ�MOÃL?W=@Ps;>» =@< < Ã; ? F º�=@?lºm;>=@¾J< D ¼ S UO» D FmF D F M D ÄF » S ; ¾ D M); ?�= F ¼ D »�;>=@< ; Å D M)<>=@?JÀNVW=@À D É S UNP D <>=JÈjí�º F ¼ S UO» D FmF D F = S D ;>M D ?lºm; àWD M�¾LÃ�; ?lº D À D S F=@?WMß» =@?ß¾ D º D S Ps; ?W=eº D Mß=@?WMʺm D ; S ;>M D ?lºm; àWD S F S D »�ÃO»�< D MÊUN?J< ÃÊ; ?Þºm D S D Ç D S F D U S M D SºmU�ºm D ; S » S D =eºm; UN? F º�= S ºm; ?JÀ�Á%; ºmÂÞºm D �HÃNUNVJ?JÀ D F º � »�V SmS D ?lºm< à S VJ?J?J; ?JÀ�¼ S UO» D FmF È1X6ÂJ; F¼ S ; ?W»�; ¼J< D » =@?"¾ D�D = F ; < Ã; Ps¼J< D P D ?lº D M�IJ¾JVOºjIWUN?§ºm D U@ºm D S ÂW=@?WM�IJ; Æiºm D S D ; F =s¼�U FmF ; ľJ; < ; º[ÃU@Æi»�ÃO»�< ;>»�; ? F º�=@?lºm;>=eºm; UN?§U@Æi¼ S UO» D FmF D F Á%; ºmÂ"¼W= S ºm;>=@< < Ã�UeÇ D S <>=@¼J¼ D Ms< ; Æ D ºm; P D F IOºm DP D ºmÂJUOM�Á%; < <.?JU@º�¼ S D Ç D ?lº%ºm D F º�=eº D F ¼W=N» D Æ S UNPäÀ S UeÁ%; ?JÀsºmU; ? à ?J; º[ÃNÈ Ï�Ñ Æ2»�UNV S F D IJ; ÆÁ D MOU)?JU@º6=@¼J¼J< Ã�= S ºm; à »�;>=@<W< ; Ps; º F UN?sºm D ?LVJP)¾ D S U@Æ S VJ?J?J; ?JÀ)¼ S UO» D FmF D F È Ò :�U S D UeÇ D S Iºm D Æ�=N»�º/ºmÂW=eº6;>M D ?lºm; àWD S F » =@?§¾ D S D »�ÃO»�< D M�UN?J< Ãs; ?ºm D S D Ç D S F D U S M D S ºmU)ºm D ; S =@< < UO» = ĺm; UN?"; F =N» » D ¼Oº�=@¾J< D ; ?§ºm D »�UN?lº D�½ º%U@Æi¼ S UO» D FmF D F Il¾JVOº�; º%; F < D FmF6F VJ; º D M"Á% D ?"Á/U S G ; ?JÀÁ%; ºmÂ�UN¾OZ D »�º F Á%ÂJU F D < ; Æ D ; F U@Æ�º D ?�; ?WM D ¼ D ?WM D ?lº�U@Æiºm D ; S » S D =eºmU S F È
ß�� ��á�:�+�,¢�.�+�¤"¡(à�� R¢� Ì+�%('h8;¢�£P¤"¡(à��E¡(2U0L,£P¢Ñ+�¤"0�¡ãé; ºm S D F ¼ D »�º.ºmU�ºm D ¼ S D ÇL; UNV F MO; F »�V FmF ; UN?1I Á D ?JUeÁ F VJÀNÀ D F ºi=@?JU@ºm D S ¼�U FmF ; ¾J< D P D ºmÂJUOMÆáU S F UN< ÇL; ?JÀܺm D ?W=@Ps; ?JÀ8¼ S UN¾J< D Pî¾W= F D M�UN?�?JU@º�»�UN? F ;>M D S ; ?JÀ8»�UN?W» S D º D Çe=@< V D F U@Æ
43
?W=@P D F U@Æ2; ? F º�=@?W» D F ºmU"¾ D ; Ps¼�U S º�=@?lº�Á% D ?å»� D » G ; ?JÀ F º�=eº D F ºmU§¾ D�Dj¿ VW=@<}ÈWíb?åU@ºm D SÁ/U S M F IlÁ D = S D ÀNUN; ?JÀ�ºmUsM D�à ? D º[Á/U)P�= S G ; ?JÀ F ºmU�¾ DxDj¿ VW=@<¢; Æ1ºm D S D�D�½ ; F º F = F VJ; º�=@¾J< D¼ D S P)VOº�=eºm; UN?8UeÇ D S ºm D F D ºsU@Æ�=@< <6;>M D ?lºm; àWD S F Á%ÂJU F D =@¼J¼J< ;>» =eºm; UN?8P�= G D F ºm D F º�=eº D F;>M D ?lºm;>» =@<}È Ë F =®»�UN? F Dj¿ V D ?W» D I1Á D Á%; < < S D ¼J<>=N» D Á/U S G ; ?JÀ�Á%; ºmÂß¼W= S ºm;>»�VJ<>= S F º�=eº D F ¾LÃÁ/U S G ; ?JÀÊÁ%; ºm S D ?W=@Ps; ?JÀ Dj¿ VJ; Çe=@< D ?W» D »�<>= FmF D F U@Æ�ºm D P�È2íb?кm D ÆáUN< < UeÁ%; ?JÀWIÁ D Á%; < <º S Ã�ºmU"M D F » S ; ¾ D ºm D P D ºmÂJUOMÊ=eºx< D = F º�¼W= S ºm;>=@< < Ã�; ?Ê=ÆáU S P�=@<iÁ6=zçæ =�ÆáVJ< < Ã�ÆáU S P�=@<M D F » S ; ¼Oºm; UN?1ILºmUNÀ D ºm D S Á%; ºmÂ�¼ S ULU@Æ F U@Æ.ºm D ¼ S UN¼�U F ; ºm; UN? F IJ» =@?"¾ D ÆáUNVJ?WM"; ? Ó KU@Z����zÖ�Èí�º F ÂJUNVJ<>Mʾ D ?JU@º D MÞ D S D ºmÂW=eº�ºm D »�UN?W» D ¼Oº)U@Æ%?W=@P D =@¾ F º S =N»�ºm; UN?Þ; F = F ¼ D »�;>=@< Ä; Åj=eºm; UN?ÜU@Æ%ºm D À D ? D S =@<E?JU@ºm; UN?ÜU@Æ F ÃLPsP D º S ; D F Ó T D ?WÔ�¾eÖ%=@¼J¼J< ; D MÞÆáU S�S D MOVW»�; ?JÀ F º�=eº DD�½ ¼J< U F ; UN?å» =@V F D M�¾LÃ�ºm D ¼ S D F D ?W» D U@Æ/»�UN?W» S D º D ?W=@P D F U@ÆE; ? F º�=@?W» D F ; ? F º�=eº D F È�Ú�? Ä< ; G D À D ? D S =@< F ÃLPsP D º S ; D F I2ÂJ; ÀNÂJ< à F ¼ D »�;>=@< ; F D M S D ?W=@Ps; ?JÀ F ÃLPsP D º S ; D F » =@?Y¾ D V F D MÁ%; ºmÂJ; ?=@< < Ñ$Ñ ÉEÌ Ä ¾W= F D M�PsUOM D < F =@?WMs=@< < UeÁßÆáVJ< < Ãs=@VOºmUNP�=eº D M)Á6=zà F U@Æ�º S D =eºm; ?JÀ�ºm D PÁ%; ºmÂJ; ?�À D ? D S =eºm; ?JÀ F º�=eº D F ¼W=N» D F È@Ì�=@P D Ä =@¾ F º S =N»�º D M F º�=eº D F ¼W=N» D F »�UNVJ<>M�¾ D M D F » S ; ¾ D M= F = F ¼ D »�;>=@<1» = F D U@Æ F ÃLPsP D º S ;>» =@< < à S D MOVW» D M F º�=eº D F ¼W=N» D F IL¾JVOº%Á D Á%; < <�M D�à ? D ºm D PF º S =@; ÀNÂlº6 D S D ºmU F =zÇ D F UNP D F ¼W=N» D =@?WM§À D º�»�< U F D S ºmUsºm D ; S ; Ps¼J< D P D ?lº�=eºm; UN?1ÈX6 D ;>M D =�U@Æ�=@¾ F º S =N»�ºm; ?JÀ®=zÁ6=zîºm D ?W=@Ps; ?JÀ®; ?OÆáU S P�=eºm; UN?Ü» =@?ßUN?J< Ãʾ D =@¼J¼J< ; D MMOV D ºmU�ºm D Æ�=N»�º�ºmÂW=eº�ºm D ¾ D ÂW=zÇL; UNV S U@Æ Ñ$Ñ ÉEÌ Ä ¾W= F D M§PsUOM D < F MOU D F ?JU@º�M D ¼ D ?WM�UN?»�UN?W» S D º D Çe=@< V D F U@Æ%;>M D ?lºm; àWD S F È�ã D S D Ii; º�; F » S VW»�;>=@<2ºmÂW=eº)ºm D M D�à ?J; ºm; UN?ÜU@Æ Ñ$Ñ ÉEÌ FMOU D F ?JU@ºE=@< < UeÁܺmU$V F D ; ? F º�=@?W» D ;>M D ?lºm; àWD S F ; ? D�½ ¼ S D FmF ; UN? F =@?WM)ºmÂW=eººm D S D » =@?J?JU@º2¾ D¼ D S ÆáU S P D M)º S ; ÇL;>=@<W»�UNPs¼JVOº�=eºm; UN? F M D ¼ D ?WMO; ?JÀ�UN?»�UN?W» S D º D Çe=@< V D F U@Æ�; ? F º�=@?W» D ?W=@P D F ÈX6 D S D ÆáU S D ; º�» =@?é¾ D ¼ S UeÇ D M8ºmÂW=eº F º�= S ºm; ?JÀßÆ S UNP F UNP D F º�=eº D »�UN?W» S D º D ?W=@P D F U@Æ; ? F º�=@?W» D F MOU�?JU@º6; ?OìWV D ?W» D ºm D ÆáVOºmV S D�D ÇNUN< VOºm; UN?U@Æ1ºm D =@¼J¼ S UN¼ S ;>=eº D Ñ$Ñ ÉEÌ�; ?"=@?LÃÁ6=zÃ Ï VJ¼ºmU S D ?W=@Ps; ?JÀ Ò ÈLX6ÂLV F ; º6; F ?JU@º6? D » D FmF = S Ã)ºmUsMO; F ºm; ?JÀNVJ; F  F º�=eº D F Dj¿ VW=@<¢VJ¼ºmUS D ?W=@Ps; ?JÀs¾ D » =@V F D U@Æ.ºm D ÆáVOºmV S D ¾ D ÂW=zÇL; UNV S ºm D Ã"» =@?"< D =NMºmUWÈã D ÂW=zÇ D F =@;>M�ºmÂW=eº2Á D Á6=@?lº º[Á/UxP�= S G ; ?JÀ F ºmUx¾ D�Dj¿ VW=@<O; Æ�ºm D S D%D�½ ; F º F = F VJ; º�=@¾J< D¼ D S P)VOº�=eºm; UN?"UeÇ D S ºm D F D º%U@Æ =@< <�ºm D ;>M D ?lºm; àWD S F =@< < UeÁ D M�; ?"ºm D =@¼J¼ S UN¼ S ;>=eº D Ñ$Ñ ÉEÌÁ%ÂJU F D =@¼J¼J< ;>» =eºm; UN?éP�= G D F ºm D F º�=eº D F ;>M D ?lºm;>» =@<}ÈÏã�UeÁ D Ç D S IÁ D MOUÜ?JU@º�=N» » D ¼Oº"=@< <¼ D S P)VOº�=eºm; UN? F È Ë ?®=N» » D ¼Oº�=@¾J< D ¼ D S P)VOº�=eºm; UN?"P)V F º�¼ S D F D S Ç D ºm D ; ?OÆáU S P�=eºm; UN?�=@¾�UNVOºÏ ý Ò ºmU�Á%ÂJ;>»�ÂÞUN¾OZ D »�º)="ÀN; Ç D ?Ê; ? F º�=@?W» D ¾ D < UN?JÀ F ºmUWI ÏGÂNÒ ºmU�Á%ÂJ;>»�ÂÞ? D º$ºm D ; ? F º�=@?W» D¾ D < UN?JÀ F Il=@?WM Ï"ÃlÒ ; º6» =@?J?JU@ºE»�ÂW=@?JÀ D ºm D ;>M D ?lºm; àWD S U@Æ¢ºm D ; ?J; ºm;>=@<�UN¾OZ D »�ºjINÁ%ÂJ;>»�Â�; F ; P ļ�U S º�=@?lº2ÆáU S ºm D Àl= S ¾W=@À D »�UN< < D »�ºm; ?JÀ$P D »�ÂW=@?J; F P�ÈlÉ D S P)VOº�=eºm; UN? F »�UN?OÆáU S PBºmU�ºm D Z[V F ºM D F » S ; ¾ D M S Dj¿ VJ; S D P D ?lº F Á%; < <1¾ D » =@< < D M1IXAEKS� « J�K�®`�LAEI « �ÑDM�DGJ"<K��x; ?"ºm D ÆáUN< < UeÁ%; ?JÀWÈ�¦'�é�¡(¤@+�¤"0�¡÷�Øê��5'�¡(¢�£P¤"¡(à*64'�,£*-/+�¢Ñ+�¤"0�¡(:ë��
� �����L<���A`åqA4���²AR�K1<�>@?�ACBEDGFH<I�J"AEKLDMACNROQAEDGI�J(KSAED ^9^`f9_ åmJ�D@�5J�D"�4��AEDq<°¯rJ�K���DM�KSBCAJ"N�AEKLDGJ ä©AEIC� t�u �KSN5J�D"�&J�KLJ�DGJ"��s<�>@?�ACBEDQJ"N�AEKLDGJ ä©AEI Z�[M\�Y ï`ð;A7N�A"äsKSA§IXAEKS� « J�K�®9�LAEI « �ÑFDM�DGJ"<K��R<²AEI ^9^`f9_ DM<5>CA9D@��A§>EJ ?�ACBEDGJ"<K���� ��t�u�� t�u ���LBC�ÒD@���DMôõ ï�� Ï"Z�[M\�YeÒsv÷Z�[M\�Y ïö ï©û [M\jª;t�u Ó Ó À�Á�Ï@[M\LÒsv Ó À�Á�Ï � Ï@[M\LÒHÒ Ö°ïú ï©û [M\jª;t�u Ó � Ï"Z�[M\�Ï@[M\LÒHÒ©v�Z�[M\�Ï � Ï@[M\LÒHÒ Ö°ïX6 D »�UN?W» D ¼Oº�U@Æ S D ?W=@Ps; ?JÀ¼ D S P)VOº�=eºm; UN? F ¼ S UeÇL;>M D F =¾W= F ; F ÆáU S M D�à ?J; ?JÀºm D F U Ä» =@< < D M�IXAEKS� « J�K�®r� � «§« AEDGI�J"A���Ie;}È D Èz¾J; Z D »�ºm; UN? F UN? F D º F U@ÆWP�= S G ; ?JÀ F =@?WM F D º F U@Æ D Ç D ?lº F ÈX6 D ÆáU S P�=@<1M D�à ?J; ºm; UN?�U@Æ S D ?W=@Ps; ?JÀ F ÃLPsP D º S ; D F » =@?�¾ D UN¾Oº�=@; ? D M"¾LÃ�= F ; Ps¼J< D ¾JVOº=< ; ºHºm< D < UN?JÀ D S D�½ º D ? F ; UN?®U@ÆE¾J; Z D »�ºm; UN? F Á/U S G ; ?JÀUeÇ D S ;>M D ?lºm; àWD S F ºmU"¾J; Z D »�ºm; UN? F UeÇ D SP�= S G ; ?JÀ F =@?WM D Ç D ?lº F æ Á D Á%; < < FHG ; ¼�ºm D M D�à ?J; ºm; UN?s D S D È@ã D M D ?JU@º D ºm D S D ?W=@Ps; ?JÀ
44
F ÃLPsP D º S Ãé; ?WMOVW» D Mó¾LÃ�= S D ?W=@Ps; ?JÀ8¼ D S P)VOº�=eºm; UN?�� = F���� È�Ì�UeÁöÁ D » =@?5M D�à ? Dº[Á/U®P�= S G ; ?JÀ FRizø I i±ù ºmUå¾ D A��E�L��©����DM<hIXAEKS� « J�K�®Ê; âкm D S DD�½ ; F º F = S D ?W=@Ps; ?JÀ¼ D S P)VOº�=eºm; UN?�� F VW»�ÂÞºmÂW=eº � � ÏGizø�ÒRv�i±ù ÈiX6 D F =@P D » =@?ß¾ D MOUN? D ÆáU S D Ç D ?lº F È1íb?ºm D ÆáUN< < UeÁ%; ?JÀWIOÁ D Á%; < <.M D ?JU@º D ºm D S D ?W=@Ps; ?JÀ Dj¿ VJ; Çe=@< D ?W» D S D <>=eºm; UN?�¾LÃ��)ÈW: D P)¾ D S FU@Æ ; º F Dj¿ VJ; Çe=@< D ?W» D »�<>= FmF D F Á%; < <1¾ D S D Æ D SmS D MºmUsV F ; ?JÀsºm D ¾J<>=N» G ¾�Ul= S M"=@< ¼JÂW=@¾ D ºjIJ;}È D È U S"! I1U S ÇL;>=)ºm D ; S%S D ¼ S D F D ?lº�=eºm; Ç D F IL;}È D È Ó i Ö.U S Ó g Ö�ÈWïi; ?W=@< < ÃNI ¿ VJU@ºm; D ?lº F D º F Á$È S È ºjÈ�ÍÁ%; < <1¾ D M D ?JU@º D M"V F ; ?JÀ#�Î= F = F VJ¾ F » S ; ¼Oºm; UN?1IJ= F D È ÀWÈ ikd%$ È
X6 D ?JU@ºm; UN?"U@Æ S D ?W=@Ps; ?JÀ F ÃLPsP D º S ; D F =@< < UeÁ F V F ºmU�ÆáU S P�=@< ; Å D ºm D =@< S D =NMOÃ�P D ? ĺm; UN? D Må¼ S UN¼�U F ; ºm; UN?åºmÂW=eº�»�UN?W» S D º D ?W=@P D F U@Æ/; ? F º�=@?W» D F » =@?J?JU@º$; ?OìWV D ?W» D =@?LÃlºmÂJ; ?JÀD < F D ºmÂW=@?§=@Àl=@; ?s?W=@P D F U@Æ�; ? F º�=@?W» D F ¼ S D F D ?lºE; ?sºm D ÆáVOºmV S D ¾ D ÂW=zÇL; UNV S U@Æ1=@? Ñ$Ñ ÉEÌ ÄM D F » S ; ¾ D M F à F º D P F º�= S ºm; ?JÀ§Æ S UNPö=ÀN; Ç D ? F º�=eº D È Ø VW»�ÂÊ=§¼ S UN¼ D S º[Ã�; F » S VW»�;>=@<i; ?åºm Dºm D U S ÃU@Æ F ÃLPsP D º S ;>» =@< < à S D MOVW» D M F º�=eº D F ¼W=N» D F È6`,0Lèq0�:�¤@+�¤"0�¡ !�� ì/AEDs���Q���²AR�K*<�>@?�ACBEDGFH<I�J"AEKLDMACNROQAEDGI�J(KSAED ^9^`f9_ åmJ�D@�5J�D"�4��AED©<°¯« �IXJ�K�®� ikd9î J�D"�&��AED�<°¯jAE²AEKLD"� gRcjî �KSN5D@��A7BC<I�IXA��G�L<KSNJ�K�®¦��AED4<°¯j�����IXAEKS� « J�K�®�LAEI « �ÑDM�DGJ"<K��'&zï)(S��AEKzD@��A�¯E<��� <åmJ�K�®h��<� N���¯E<I¦AE²AEI � izø�VCi±ù5ªíikd9îqg ªÌgRc§î�KSN'� ª &zô izø Ó gRÎHi±ùQü*����ÏGizø�Ò Ó ���1Ï"g)ÒHÎ�����ÏGi±ùjÒ ï
æ D ?W=@Ps; ?JÀ F ÃLPsP D º S ; D F =@< < UeÁ,V F ºmUм S UN¼�U F D ºm DÊD�½ ¼ D »�º D M�?JU@ºm; UN?�U@Æ5KS� « AEF��>���DGIX��BEDMACN7��DM�DMA9�G�L��BCA���+-, � ��DM�DMA9�G�L��BCA��/.)U@Æ Ñ$Ñ ÉEÌ F ÈOãé D ?�À D ? D S =eºm; ?JÀ�=s?W=@P D Ä=@¾ F º S =N»�º D M F º�=eº D F ¼W=N» D I »�UN?W» S D º D ;>M D ?lºm; àWD S F U@Æ�; ? F º�=@?W» D F Á%; < </?JU@º�¾ D º�= G D ?ß; ?lºmU=N» »�UNVJ?lº/=@?WMsº[Á/U F º�=eº D F U S D Ç D ?lº F Á%; < <�¾ D »�UN? F ;>M D S D M Dj¿ VW=@<W; Æ�ºm D Ã�= S D�Dj¿ VW=@<WVJ¼�ºmUS D ?W=@Ps; ?JÀWÈNX6 D M D�à ?J; ºm; UN?U@Æ�?W=@P D Ä =@¾ F º S =N»�º D M F º�=eº D F ¼W=N» D F Á%; < <�¾ D ¾W= F D M�=@Àl=@; ?sUN?ºm D À D ? D S =@<�»�UN?W» D ¼Oº/U@Æ F º�=eº D F ¼W=N» D F È�ã�UeÁ D Ç D S I@ºmÂJ; F ºm; P D F º�=eº D F Á%; < <¢»�U SmS D F ¼�UN?WM�ºmUS D =N»�ÂW=@¾J< D KS� « AEFH��>���DGIX��BEDMACN « �IXJ�K�®��I@;}È D È Dj¿ VJ; Çe=@< D ?W» D »�<>= FmF D F U@Æ ikd Á$È S È ºjÈ0�)Ie=@?WMF º S VW»�ºmV S =@<Lº S =@? F ; ºm; UN? F ºmU$V F D ÆáVJ<�KS� « AEFH��>���DGIX��BEDMACN§AE²AEKLD"��I@;}È D È Dj¿ VJ; Çe=@< D ?W» D »�<>= FmF D F U@ÆgRc Á$È S È ºjÈ��)È ØLD P�=@?lºm;>»º S =@? F ; ºm; UN? F Á%; < <L¾ D M D�à ? D M�; ?�=N» »�U S MJ=@?W» D ºmU�ºm DEà S ; ?JÀ S VJ< D FU@Æ Ñ$Ñ ÉEÌ F =@?WM�ºmU§ºm D F D P�=@?lºm;>» F U@Æ S D ?W=@Ps; ?JÀWÈ�X6 D ; ?J; ºm;>=@< F º�=eº D Á%; < < ¾ D)Dj¿ VW=@<.ºmUºm D6Dj¿ VJ; Çe=@< D ?W» D »�<>= FmF »�UNPs¼ S ; F ; ?JÀ�ºm D ; ?J; ºm;>=@<LP�= S G ; ?JÀ�=@?WM�UN?J< Ãxºm D ; ?J; ºm;>=@<LP�= S G ; ?JÀWÈ�¦'�é�¡(¤@+�¤"0�¡�ß=ê°8;¢�£P'�1��á�:�+�,¢�.�+�'�ÿ÷) +�¢Ñ+�'~) è�¢�.�'�:ë��
ì/AEDj�Kk<�>@?�ACBEDGFH<I�J"AEKLDMACN~OQAEDGI�J&KSAED ^9^`f9_ åmJ�D@�íJ�D"�Ò��AED7<°¯ « �IXJ�K�®�Ò� �rî J�D"�J�KLJ�DGJ"�� « �IXJ�K�® i~Y�î J�D"�9��AEDQ<°¯RAE²AEKLD"� gRcjî �KSN�J�D"�9IXAEKS� « J�K�®ÒA��E�ÑJ�²�� AEKSBCARIXAE� �DGJ"<K� >CAÒ®�J�²AEKSï;ð;A~N�A"äsKSA*D@��AÊ?W=@P D Ä =@¾ F º S =N»�º D M F º�=eº D F ¼W=N» D Ï Ì Ë F º�=eº D F ¼W=N» D Ò <°¯^9^`f9_ DM<�>CA&D@��A4ñ�FMDG���S� A _hdra�ÁHaSò5vBÏGa32RVHb32&VCó42RV Ó i~Y Ö Ò ���LBC�ÒD@���DMôõ ï a32ºvk� Ó i Ö ª;ikd%$í��i¶ª Ó i~Y�Î � ïö ï b32ºvº�LÏ Ó izø Ö V Ó g Ö V Ó i±ù Ö Ò©ªha32n·ÒgRc5$Ì·;a32¸��izø Ó gRÎHi±ù � ïú ï©û� øÑV ù¦ª1ikd%$ û ! ª1gRc5$ Ó Ï øÑV ! V ùLÒ�ª;b32ºü�Ï ø�VjÏ ø�V ! V ùLÒ�V ùLÒ�ª
ó42 Ö°ïX6 D =@¾�UeÇ D ¼ S UN¼�U F D MxÌ Ë F º�=eº D F ¼W=N» D F = S D ¾W= F D M�UN?x¼ S U@Z D »�ºm; ?JÀ%=zÁ6=zÃ%ºm D ?W=@Ps; ?JÀ; ?OÆáU S P�=eºm; UN?)¼ S D F D ?lº ; ?�¼W= S ºm;>»�VJ<>= S F º�=eº D F =@?WM F º S VW»�ºmV S =@<lº S =@? F ; ºm; UN? F U@ÆJºm D »�<>= FmF ;>» =@<
F º�=eº D F ¼W=N» D F È�Ì Ë F º�=eº D F ¼W=N» D F ¼ S D F D S Ç D ; ?OÆáU S P�=eºm; UN?Ê=@¾�UNVOº S D =N»�ÂW=@¾J< D F º�=eº D F =@?WMD Ç D ?lº F IL¾JVOº6ºm D ; S ; ?lº D S »�UN?J? D »�ºm; UN?; F ¼ S D F D S Ç D M�UN?J< Ã�¼W= S ºm;>=@< < ÃNÈLX6ÂJ; F Æ�=N»�º%; F ÆáU S P�=@< Ä; Å D Må; ?ʼ S UN¼�U F ; ºm; UN? Â Æ S UNPêÁ%ÂJU F D F º S VW»�ºmV S D Á D » =@?åÀNV D FmF ºmÂW=eº)Ì Ë F º�=eº D F ¼W=N» D FMOU$?JU@ºE»�UN?lº�=@; ?s; ?OÆáU S P�=eºm; UN?s=@¾�UNVOº2Á%ÂJ;>»�Âs¼W= S ºm;>»�VJ<>= S ; ? F º�=@?W» D F = S D P�=@?J; ¼JVJ<>=eº D M�¾LÃD Ç D ?lº F Á% D ?�ÀNUN; ?JÀ)Æ S UNPëUN? D F º�=eº D ; ?lºmU�=@?JU@ºm D S È
45
6`,0Lèq0�:�¤@+�¤"0�¡�� � ì/AEDs���Q���²AR�K �`� O6,¸åmJ�D@�¦J�D"�4��DM�DMAr�G�L��BCA a�ÁHaSò �KSNjD@��A&BC<I�IXAEF�G�L<KSNJ�K�®5KS� « AEFH��>���DGIX��BEDMACNj��DM�DMA`�G�L��BCA _hdra�ÁHaSò ï�(S��AEK1D@��Aq¯E<��� <åmJ�K�®5��<� N���ôûSÓ87 ý û� øÑV ½�½�½ V :9 ª¸ikd%$ û ! øÑV ½�½�½ V ! 9<; ø�ª¿gRc5$ û [¦ª=� ý V ½�½�½ V Ó � û i�=7ª = Ó�> øÑV ! ø�V ½�½�½ V =�V ½�½�½ V ! 9<; øÑV :9 Î J��R�r�L�D@�ÒJ�K�, � � D � �*J ¯&�KSN5<KL� � J ¯�? izøhª ø�V ½�½�½ VCi�= ; ø�ª = ; øÑVCi�= @(ø�ª = @(ø�V ½�½�½ VCi 9 ª :9A? grø�ª ! øÑV ½�½�½ VXg 9<; ø÷ª! 9<; ø ���LBC�ÒD@���D > izø�VXgrø�V ½�½�½ VCi�=°V ½�½�½ VXg 9<; ø�VCi 9 Î J��R�r�L�D@�ÒJ�K a�ÁHaSò Ö°ï
X6 D ; ?OÆáU S P�=eºm; UN?�Á D = S D < U F ; ?JÀ�; ?"Ì Ë F º�=eº D F ¼W=N» D F ; F UN¾LÇL; UNV F < Ã)?JU@º/; Ps¼�U S º�=@?lºÁ% D ?"Á D = S D M D =@< ; ?JÀ�Á%; ºmÂ�; F UN<>=eº D M F º�=eº D F UN?J< ÃNÈ Ñ ?§ºm D U@ºm D S ÂW=@?WM�IO; Æ Á D ? D D MºmU¾ D =@¾J< D ºmU D�½ ¼J< U S D F Dj¿ V D ?W» D F U@Æ F º�=eº D F =@?WM D Ç D ?lº F IzºmÂJ; F ; ?OÆáU S P�=eºm; UN?�Ps; ÀNÂlº¾ D »�UNP D? D » D FmF = S à D Ç D ?$; ÆWÁ D MOU�?JU@º»�UN? F ;>M D S »�UN?W» S D º D ?W=@P D F U@ÆW; ? F º�=@?W» D F ºmU�¾ D ; Ps¼�U S º�=@?lºjÈX6ÂJ; F ; F ¾ D » =@V F D ; ºx» =@?�¾ D V F D ÆáVJ<.ºmU G ?JUeÁÍÂJUeÁÎ=�¼W= S ºm;>»�VJ<>= S ; ? F º�=@?W» D ÀN; Ç D ?�¾LÃ"; º F;>M D ?lºm; àWD S Á%; ºmÂJ; ? F UNP D = S ¾J; º S = S ; < Ãå»�ÂJU F D ? S D ¼ S D F D ?lº�=eºm; Ç D U@Æ6ºm D =@¼J¼ S UN¼ S ;>=eº D Ì ËF º�=eº D ¾ D ÂW=zÇ D F Á%; ºmÂJ; ?sºm D�D Ç D ?lº F2F V SmS UNVJ?WMO; ?JÀ�ºm D F º�=eº D ¾ D ; ?JÀ D�½ =@Ps; ? D M�È�ã�UeÁ D Ç D S I; Æ6Á D ? D D Måºm D ; ?OÆáU S P�=eºm; UN?1I�Á%ÂJ;>»�ÂÊ; F < U F º$; ?ßÌ Ë F º�=eº D F ¼W=N» D F I¢; º�; F ?JU@º�MO; è »�VJ< ººmUs¼ S D F D S Ç D ; ºjÈJïJU S ºmÂJ; F S D = F UN?1ILÁ D M D�à ? D ºm D F U Ä » =@< < D M*BC< « �S� AEDMA&KS� « AEFH��>���DGIX��BEDMACN��DM�DMA`�G�L��BCA���+�BC, � ��DM�DMA9�G�L��BCA��/.eÈ
ã D M D�à ? D�C Ì Ë F º�=eº D F ¼W=N» D F = F <>=@¾ D < < D M8Ì Ë F º�=eº D F ¼W=N» D F È Ù Ç D S ÃÞÌ Ë F º�=eº DÁ%; < <¾ D <>=@¾ D < < D Må¾Lî=§ºmVJ¼J< D »�UN? F ; F ºm; ?JÀ�U@Æ6= S D ¼ S D F D ?lº�=eºm; Ç D P�= S G ; ?JÀ"¾ D < UN?JÀN; ?JÀ§ºmUºm D�Dj¿ VJ; Çe=@< D ?W» D »�<>= FmF S D ¼ S D F D ?lº D MܾLÃߺm D Ì Ë F º�=eº D =@?WMÐ= F D º�U@Æ F D < Æ Ä S D ?W=@Ps; ?JÀ¼ D S P)VOº�=eºm; UN? F�Ï ;}È D È2¼ D S P)VOº�=eºm; UN? F Á%ÂJ;>»�ÂÐP�=@¼Ðºm D S D ¼ S D F D ?lº�=eºm; Ç D P�= S G ; ?JÀåºmUß; º ÄF D < Æ Ò È Ù Ç D S à F º S VW»�ºmV S =@<2º S =@? F ; ºm; UN?ßÁ%; < </¾ D <>=@¾ D < < D Mß¾LÃß= F D º�U@Æ%ºmVJ¼J< D F »�UN? F ; F ºm; ?JÀU@Æ�= S D ¼ S D F D ?lº�=eºm; Ç D�D Ç D ?lº�=@?WMß= S D ?W=@Ps; ?JÀ�¼ D S P)VOº�=eºm; UN?1Èiã D S Dj¿ VJ; S D ºmÂW=eº D Ç D S ÃS D ¼ S D F D ?lº�=eºm; Ç DxD Ç D ?lº�P)V F º�¾ D$à S =@¾J< D Æ S UNPäºm D =@¼J¼ S UN¼ S ;>=eº D S D ¼ S D F D ?lº�=eºm; Ç D F UNV S » DP�= S G ; ?JÀ"< D =NMO; ?JÀ§ºmU�ºm D =@¼J¼ S UN¼ S ;>=eº D S D ¼ S D F D ?lº�=eºm; Ç D º�= S À D ºxP�= S G ; ?JÀ±�°¯CDMAEI"=@¼J¼J< à Ä; ?JÀxºm D ÀN; Ç D ? S D ?W=@Ps; ?JÀWÈ@ïJV S ºm D S PsU S D I D Ç D S à D Ç D ?lº à S =@¾J< D Æ S UNPBºm D S D ¼ S D F D ?lº�=eºm; Ç DF UNV S » D P�= S G ; ?JÀ�=@?WM< D =NMO; ?JÀ�ºmUs=)P�= S G ; ?JÀ Dj¿ VW=@<�VJ¼§ºmU S D ?W=@Ps; ?JÀ�ºmU)ºm D S D ¼ S D F D ? ĺ�=eºm; Ç D º�= S À D ºEP�= S G ; ?JÀ)P)V F º/¾ D M D S ; Çe=@¾J< D Ï VJ¼ºmU)ºm D ?W=@P D U@Æi=@? D Ç D ?lºmVW=@< < Ã�? D Á%< Ã= S ; F ; ?JÀ); ? F º�=@?W» D Ò Æ S UNP F UNP D U@Æ1ºm D S D ¼ S D F D ?lº�=eºm; Ç D�D Ç D ?lº F ÇL;>=)=)¼ D S P)VOº�=eºm; UN?�Æ S UNPºm D F D º�U@Æ F UNV S » D F D < Æ Ä S D ?W=@Ps; ?JÀ®¼ D S P)VOº�=eºm; UN? F È ØLD < Æ Ä S D ?W=@Ps; ?JÀå¼ D S P)VOº�=eºm; UN? F » =@?M D » S D = F D ºm D ?LVJP)¾ D S U@Æ.º�= S À D º%P�= S G ; ?JÀ F Á D ÂW=zÇ D ºmUs¼ S UO» D FmF Ó T D ?WÔ�¾eÖ�È
�¦'�é�¡(¤@+�¤"0�¡DÞêFER0�£±è�â"'�+�'Ò8;¢�£P'�1��á�:�+�,¢�.�+�'�ÿ÷) +�¢Ñ+�'*) è�¢�.�'�:ë��� �����L<���AjåqA§���²A¦�K ^9^`f9_ åmJ�D@�*J�D"�R��AEDr<°¯ « �IXJ�K�®� ikd9î J�D"�§��AEDr<°¯7AE²AEKLD"�
gRcjî �KSN1J�D"����AED&<°¯5IXAEKS� « J�K�®��LAEI « �ÑDM�DGJ"<K��G&zï7ð;A;N�A"äsKSA5D@��A�»�UNPs¼J< D º D ?W=@P D Ä=@¾ F º S =N»�º D M F º�=eº D F ¼W=N» D Ï C Ì Ë F º�=eº D F ¼W=N» D Ò <°¯ ^9^`f9_ DM<`>CAÏD@��AÏDGI�J �S� A ]`_hdra�ÁHaSò5vÏ"_hdra�ÁHaSò/V�H*VXÀeÒ ���LBC�ÒD@���DMô
õ ï _hdra�ÁHaSò5vBÏGa32RVHb32RVCó42RV Ó i~Y Ö Ò J��&D@��AI, � ��DM�DMA`�G�L��BCA§<°¯ ^9^`f9_ ïö ï H ��a32º� ikdn·;ÂKJ ���LBC�ÒD@���D û� ª;a32 Ó HÞÏ Ò4vBÏGiºVFL2ÒNM!ÏGi¶ª PO
û3Q ª�L Ó �KR.ÏGiÎÒsv i Ö Ò Ö°ïú ï À&��b32º� ÂKSUTWVXJ ���LBC�7D@���D�¯E<Ir���� Ï ø�V ! V ùLÒϪ¦b32 åmJ�D@� HÞÏ øNÒsvBÏGizø�VFLqø Ò
�KSN HÞÏ ùLÒ4vëÏGi±ù�VFLmùjÒCîmÀLÏHÏ øÑV ! V ùLÒHÒ J��§D@��A§� « ���� A���DQ��AEDQ���LBC�hD@���D�û g&Ímª! û ikÍù ª ù Ó izø Ó g&Í�ÎHikÍù M ? Ï"g7V � ÒQªÒÀLÏHÏ øÑV ! V ùOÒHÒ Ó izø Ó gRÎ�����ÏGi±ùjÒ OY?XQ ªLqø Ó À�[M\�À�ZOÏ"g Í V[� R Ï"g)ÒHÒ Ö Ö Ö°ï
46
íb?§ºm D M D�à ?J; ºm; UN?"U@Æ C Ì Ë F º�=eº D F ¼W=N» D F ILÁ D ÂW=zÇ D V F D M"=�¼ S D MO;>» =eº D À�[M\�À�Z Á%ÂJ;>»�Â; F ÆáVJ< à < < D MßÁ% D ?8=@¼J¼J< ; D MÞºmU�º[Á/U÷� D�½ ; F ºm; ?JÀ®;>M D ?lºm; àWD S Dj¿ VW=@< ��D Ç D ?lº F È Ø VW»� D Ç D ?lº F» =@?ÜMO; â D S UN?J< ÃÊ; ?Þºm D ;>M D ?lºm; àWD S U@Æ6ºm D ? D Á%< ÃÞ» S D =eº D MÊUN¾OZ D »�º)Á%; ºmÂJ; ?8=@?±Æ D Ç D ?lº=@?WMs; ?sºm D ;>M D ?lºm; àWD S U@Æ¢ºm D ? D Á%< à F º�= S º D MsP D ºmÂJUOMs? D ºE; ? F º�=@?W» D Á%; ºmÂJ; ?=@?7Ê D Ç D ?lºjÈã D F ÂJUNVJ<>MÞ=NMJMåºmÂW=eº C Ì Ë F º�=eº D F ¼W=N» D F = S D »�< U F D ºmU®»�UNPsPsUN? F ÃLPsP D º S ;>» =@< < ÃS D MOVW» D M F º�=eº D F ¼W=N» D F Ó T D ?WÔ�¾eÖ�ÈeX6 D V F D U@Æ À�[M\�À�Z =@?WM�?JU@º S Dj¿ VJ; S ; ?JÀ�=@< < F D < Æ Ä S D ?W=@Ps; ?JÀ¼ D S P)VOº�=eºm; UN? F ºmU)¾ D »�UNPs¼JVOº D M; F =@?§=eºHº D Ps¼Oº/ºmU D = F D ºm D =@VOºmUNP�=eºm;>»�À D ? D S =eºm; UN?�U@ÆC Ì Ë F º�=eº D F ¼W=N» D F È Ï Ì�U@º D ºmÂW=eº$; º$» =@?å¾ D =NMOÇe=@?lº�=@À D UNV F ºmU§º S Ã�ºmU"UN¾Oº�=@; ?å=eºx< D = F ºF UNP D F D < Æ Ä S D ?W=@Ps; ?JÀ�¼ D S P)VOº�=eºm; UN? F�F º�= S ºm; ?JÀ�¾LÃÞ»�UNPs¼W= S ; ?JÀ D Ç D ?lº F D ?W=@¾J< D MÞ; ?Þºm DF =@P D F º�=eº D È Ò C Ì Ë F º�=eº D F ¼W=N» D F » =@?)¾ D V F D M�Á%; ºmÂs=@< <OPsUOM D < F M D F » S ; ¾ D M�¾Là Ñ$Ñ ÉEÌ F ÈãéÂW=eº�; F PsU S D I�= F Á D V F VW=@< < Ã"MOU?JU@º�»�UN? F ;>M D S »�UN?W» S D º D ?W=@P D F U@Æ; ? F º�=@?W» D F ºmU¾ D; Ps¼�U S º�=@?lºsÁ% D ?Y=@?W=@< ÃLÅ ; ?JÀå¼ S UN¼ D S ºm; D F U@Æ F à F º D P F Iiºm D S D MOUÊ?JU@º= S ; F D ¼ S UN¾J< D P FÁ%; ºmÂóºm DÊD�è »�; D ?W»�ÃéU@Æ D�½ º S =N»�ºm; ?JÀÐ; ?OÆáU S P�=eºm; UN?éÆ S UNP C Ì Ë F º�=eº D F ¼W=N» D F D Ç D ?�; ƺm D = S ; F ; ?JÀ Dj¿ VJ; Çe=@< D ?W» D »�<>= FmF D F = S D ; ? à ?J; º D È6ïi; ?W=@< < ÃNI C Ì Ë F º�=eº D F ¼W=N» D F » =@?Y¾ DÀ D ? D S =eº D MY»�UNPs¼J< D º D < ÃY=@VOºmUNP�=eºm;>» =@< < ÃNI/=@< ºmÂJUNVJÀN F UNP D ÂJ; ?lº F Æ S UNP PsUOM D < < D S F » =@?F UNP D ºm; P D F ; Ps¼ S UeÇ D ºm D$D�è »�; D ?W»�çU@ÆiÀ D ? D S =eºm; ?JÀ�ºm D P�IW= F Á D Á%; < <1P D ?lºm; UN?"<>=eº D S ÈC Ì Ë F º�=eº D F ¼W=N» D F »�UN?lº�=@; ?�; ?OÆáU S P�=eºm; UN?ó=@¾�UNVOº S D =N»�ÂW=@¾J< D F º�=eº D F =@?WM D Ç D ?lº FÏ VJ¼�ºmU S D ?W=@Ps; ?JÀ Ò =@?WM�=@< F U§=@¾�UNVOº�ºm D ; S »�UN?W» S D º D ; ?lº D S »�UN?J? D »�ºm; UN?1ÈWX6ÂJ; F =@< < UeÁ F ºmUà ?WMÞUNVOº)ÂJUeÁ ¼W= S ºm;>»�VJ<>= S ; ? F º�=@?W» D F = S D P�=@?J; ¼JVJ<>=eº D MÞ¾Là D Ç D ?lº F È C UN? F Dj¿ V D ?lºm< ÃNI1; º; F ¼�U FmF ; ¾J< D ºmU�UN¾Oº�=@; ?Þ=ÆáVJ< < F º�=eº D F ¼W=N» D Æ S UNPê; º F C Ì Ë Ä Çe= S ;>=@?lº$=@?WM®ºm D F D ºxU@Æ6=@< <S D ?W=@Ps; ?JÀ§¼ D S P)VOº�=eºm; UN? F È¢X6 D F D = S D ºm D »�UN?lº D ?lº F U@Æ2ºm D ¾ D < UeÁμ S UN¼�U F ; ºm; UN?1È¢Ì�U@º DºmÂW=eºEV F ; ?JÀxºm D F D ºEU@Æ�=@< < S D ?W=@Ps; ?JÀ$¼ D S P)VOº�=eºm; UN? F ; F ?JU S P�=@< < Ã�?JU@ºE? D » D FmF = S Ã$Á%; ºmÂJ; ?¼ S =N»�ºm;>» =@<OÇ D S ; à » =eºm; UN?)º�= FHGOF Á% D S D »�UN?W» S D º D ?W=@P D F U@Æ¢; ? F º�=@?W» D F = S D ?JU@º2; Ps¼�U S º�=@?lºjÈ6`,0Lèq0�:�¤@+�¤"0�¡íß�� ì/AED����Ï���²A&�Kh<�>@?�ACBEDGFH<I�J"AEKLDMACN&OQAEDGI�J/KSAED ^9^`f9_ åmJ�D@��J�D"�GBC, ���DM�DMA&�G�L��BCA ]`_hdra�ÁHaSò �KSN�J�D"�9��AED�<°¯&IXAEKS� « J�K�®9�LAEI « �ÑDM�DGJ"<K��I&zïI(S��AEK*J�DÏJ��Q�L<���F��J">E� ARDM<jIXACBC<K���DGI��LBEDqD@��Aq¯C�Ñ��� ��DM�DMA9�G�L��BCA§<°¯ ^9^`f9_ ¯CIX< « ]`_hdra�ÁHaSò �KSNG&zï
X6 D ºm; P D »�UNPs¼J< D�½ ; º[ÃÐU@Æ$À D ? D S =eºm; ?JÀ C Ì Ë F º�=eº D F ¼W=N» D F ; F =@< PsU F ººm D F =@P D= F ; ?Yºm D » = F D U@Æ�Ì Ë F º�=eº D F ¼W=N» D F ÈEX6ÂJ; F ; F ¾ D » =@V F D F º�=eº D S D ¼ S D F D ?lº�=eºm; Ç D F =@?WMS D ?W=@Ps; ?JÀ F ÃLPsP D º S ; D F P)V F ºE¾ D »�UNPs¼JVOº D M D Ç D ?sÁ% D ?�À D ? D S =eºm; ?JÀ$Ì Ë F º�=eº D F ¼W=N» D F I=@< ºmÂJUNVJÀNÂ"; ?§ºm D ; S » = F D ºm D Ã"= S D ºm S UeÁ%?�=zÁ6=zÃ�=eÆ�º D S M D º D S Ps; ?J; ?JÀ�ºm D º�= S À D º6?JUOM D FU@Æ ¼W= S ºm;>»�VJ<>= S F D P�=@?lºm;>»�º S =@? F ; ºm; UN? F$Ï ºmÂLV F�F =zÇL; ?JÀ F UNP D P D PsU S Ã Ò È
� D º�V F ?JUeÁª»�UNPs¼W= S D ºm D =eºHºm; ºmVWM D F U@Æ6V F ; ?JÀ F UN¼JÂJ; F ºm;>» =eº D MÊ?W=@Ps; ?JÀ S VJ< D F =@?WM?W=@P D =@¾ F º S =N»�ºm; UN?1È.ã D =@< S D =NMOà G ?JUeÁ ºmÂW=eº F UN¼JÂJ; F ºm;>» =eº D MÞ?W=@Ps; ?JÀ S VJ< D F I.¼�U FmF ; ¾J< û�UNP)¾J; ? D MÜÁ%; ºmÂY¼W= S ºm;>=@<6U S M D S�S D MOVW»�ºm; UN?1I» =@? S D PsUeÇ D F UNP D U@Æ�ºm D S D MOVJ?WMJ=@?W»�; D F» =@V F D M$¾LÃ$= FmF ; ÀN?J; ?JÀ�MO; â D S D ?lºi?W=@P D F ºmU�MOÃL?W=@Ps;>» =@< < Ã$= S ; F ; ?JÀ�; ? F º�=@?W» D F Á%; ºmÂs» D S º�=@; ?»�ÂW= S =N»�º D S ; F ºm;>» S UN< D F ; ?�ºm D PsUOM D < D M F à F º D P�Iz¾JVOº; º; F ?JU@ºÀNVW= S =@?lº D D M�ºmÂW=eº ºm D Ã�Á%; < <S D PsUeÇ D =@< <�U@Æiºm D P�ÈW:�U S D UeÇ D S I F UN¼JÂJ; F ºm;>» =eº D M?W=@Ps; ?JÀ S VJ< D F I D Ç D ?"Á% D ?�»�UNP)¾J; ? D MÁ%; ºmÂ"¼W= S ºm;>=@<¢U S M D S/S D MOVW»�ºm; UN?1IJMOU�?JU@º% D < ¼"P)VW»�Â"=@Àl=@; ? F º F à F º D P Ä < D Ç D < F ÃLPsP D º S ; D FP�=@¼J¼ D MéUN?lºmUÜÁ/U S G ; ?JÀßÁ%; ºmÂó» D S º�=@; ?é; ? F º�=@?W» D F ; ?ó= F ÃLPsP D º S ;>» =@<�Á6=zÃÐÇL;>=Þºm D ; S;>M D ?lºm; àWD S F ÈlÌ�=@P D =@¾ F º S =N»�ºm; UN?1IeUN?sºm D U@ºm D S ÂW=@?WM�Il» =@? S D PsUeÇ D =@< <Oºm D S D MOVJ?WMJ=@?W»�Ã= FmF UO»�;>=eº D M®ºmU�?W=@P D F U@Æ%MOÃL?W=@Ps;>» =@< < Ãå=@¼J¼ D = S ; ?JÀ�=@?WMÊMO; F =@¼J¼ D = S ; ?JÀ�; ? F º�=@?W» D F =@?WMºmÂLV F » =@? F =zÇ D PsU S D P D PsU S Ã�ºmÂW=@?®ºm D =eºHºm; ºmVWM D F ¾W= F D M®UN? F UN¼JÂJ; F ºm;>» =eº D M�?W=@Ps; ?JÀS VJ< D F È.X6ÂJ; F ; F =�»�UN? F Dj¿ V D ?W» D U@Æ%=@< Á6=zà F ; ÀN?JU S ; ?JÀ�=@< <ºm D MO; â D S D ?lº�¼�U FmF ; ¾J; < ; ºm; D F U@Æ;>M D ?lºm; ÆáÃL; ?JÀ�VJ?J; ?lº D S »�ÂW=@?JÀ D =@¾J< D ; ? F º�=@?W» D F Á%; ºmÂJ; ?�U@ºm D S Á%; F D ;>M D ?lºm;>» =@< F º�=eº D F Á%; ºmÂJUNVOº=@?Là S D F ¼ D »�º6ºmUsºm D Á6=zÃ�ÂJUeÁ�ºm D çÁ D S D » S D =eº D M"=@?WM"Á%ÂW=eº%Á6= F ºm D ; S%S UN< D F U�Æ�= S È
47
Ø UWIz; º F D D P F ºmÂW=eº S D ?W=@Ps; ?JÀx» =@? F =zÇ D PsU S D P D PsU S ÃxºmÂW=@? F UN¼JÂJ; F ºm;>» =eº D M�?W=@Ps; ?JÀS VJ< D F I D Ç D ?®; ?®ºm D » = F D U@ÆEV F ; ?JÀ§¼W= S ºm;>=@<iU S M D S�S D MOVW»�ºm; UN?1È Ñ ?®ºm D U@ºm D S ÂW=@?WM�I�Á DPs; ÀNÂlº2ÂW=zÇ D ºmU$¼W=zÃ$ÆáU S V F ; ?JÀ S D ?W=@Ps; ?JÀ ¿ VJ; º D =x< U@º2; ?�º D S P F U@Æ�ºm D ºm; P D »�UNPs¼J< D�½ ; º[þ D » =@V F D º D F ºm; ?JÀ�P�= S G ; ?JÀ F ºmU�¾ D�Dj¿ VW=@<VJ¼ÊºmU S D ?W=@Ps; ?JÀ�» =@?ÊP)VJ< ºm; ¼J< îºm D UeÇ D S =@< <ºm; P D U@Æ�À D ? D S =eºm; ?JÀ F º�=eº D F ¼W=N» D F ¾Là ^sÏ Ó6\ Ò Á% D S D Ó�; F ºm D P�= ½ ; P�=@<W?LVJP)¾ D S U@Æ.»�UN? Ä»�V SmS D ?lºm< à D�½ ; F ºm; ?JÀ$; ? F º�=@?W» D F È@ïJU S ºmVJ?W=eº D < ÃNIeºmÂJ; F ; F ºm D Á/U S F º2» = F D F » D ?W= S ; UxUN?J< Ã)=@?WMÁ D » =@?ßV F VW=@< < ÃÞM D » S D = F D ºm D ºm; P D »�UNPs¼J< D�½ ; º[ÃåV F ; ?JÀ�ºm D  D V S ; F ºm;>» F ¾ S ; D ìWÃÊP D ? ĺm; UN? D M); ?�ºm D ? D�½ º F VJ¾ F D »�ºm; UN?1È@X6 D F D  D V S ; F ºm;>» F = S D ¾W= F D M)UN? S D ?W=@Ps; ?JÀ�; ? F D ? F ; ºm; Ç DÂW= F ÂJ; ?JÀxº D »�ÂJ?J; ¿ V D F M D » S D = F ; ?JÀx?LVJP)¾ D S F U@Æ F º�=eº D F ºmU$¾ D »�UNPs¼W= S D M�=@?WMsUN? D�½ ¼J< UN; º Ä; ?JÀ�ºm D F º S VW»�ºmV S D U@Æ F º�=eº D F ÆáU S F D < D »�ºm; ?JÀ; ? F º�=@?W» D F Á%ÂJU F D ;>M D ?lºm; àWD S F ; º�; F�F D ? F ; ¾J< DºmUܼ D S P)VOº D ÈEãéÂW=eº§; F PsU S D I2Á D » =@?é D < ¼Yºm D P D »�ÂW=@?J; F P U@Æ$?W=@P D =@¾ F º S =N»�ºm; UN?¾LÃÊP�=@?LVW=@< < à F ¼ D »�; ÆáÃL; ?JÀ®ÂJUeÁ ºmU à ?WMÜ=@?WM D�½ ¼J< UN; º S D ?W=@Ps; ?JÀ F ÃLPsP D º S ; D F =eº)< D = F º=@PsUN?JÀ F UNP D U@Æ.ºm D ; ?LÇNUN< Ç D M�; ? F º�=@?W» D F ÈLíb? F VW»�Â"=�» = F D IlUN?J< Ãsºm D ; ? F º�=@?W» D F VJ?W»�UeÇ ÄD S D M�P�=@?LVW=@< < ÃxÂW=zÇ D ºmU�¾ D ¼ S UO» D FmF D M$¾LÃxºm D ÆáV S ºm D S P D ?lºm; UN? D M) D V S ; F ºm;>» F Èjí�º; F =@< F U; ?lº D S D F ºm; ?JÀ$ºmÂW=eºEUN?W» D Á D =@< < UeÁÐP�=@?LVW=@< F ¼ D »�; à » =eºm; UN?�U@Æ S D ?W=@Ps; ?JÀ F ÃLPsP D º S ; D F I@ºm DF =@P D P D »�ÂW=@?J; F P'» =@?�¾ D V F D M"ÆáU S F ¼ D »�; ÆáÃL; ?JÀÀ D ? D S =@< F ÃLPsP D º S ; D F =@?WM�ÇL;>» D Ç D S F =JÈ:�UOM D < < D S F » =@?)ºm D ?)Æ S D D < Ã)»�ÂJULU F D ÂJUeÁ8P)VW»�Â); ?OÆáU S P�=eºm; UN?)ºmU�¼ S UeÇL;>M D P�=@?LVW=@< < Ã�=@?WMÂJUeÁYP)VW»�Â�Á/U S G)F ÂJUNVJ<>Ms¾ D MOUN? D =@VOºmUNP�=eºm;>» =@< < ÃNÈ�ã�UeÁ D Ç D S I D Ç D ?�; ? F VW»�Â�=�» = F D I@ºm D=@¾�UeÇ D M D F » S ; ¾ D M"¼ S ; ?W»�; ¼J< D F U@Æi?W=@P D =@¾ F º S =N»�ºm; UN? F ÂJUNVJ<>M§¾ D S D F ¼ D »�º D M�ÈX.U®; < < V F º S =eº D ºm D =@¾�UeÇ D »�UN? F ;>M D S =eºm; UN? F I1Á D » =@?ß¼ S D F D ?lº F UNP D MJ=eº�=�UN¾Oº�=@; ? D MÆ S UNP = F ; Ps¼J< D É S UN< UNÀ"¼ S U@ºmU@º[ÃL¼ D U@Æ�=@? Ñ$Ñ ÉEÌ F º�=eº D F ¼W=N» D À D ? D S =eºmU S I�Á%ÂJ;>»�ÂßÁ D=@¼J¼J< ; D MܺmU F D Ç D S =@< D�½ =@Ps¼J< D PsUOM D < F I F VW»�ÂY= F »�<>= FmF ;>» =@<6¼JÂJ; < U F UN¼J D S F IMO; F º S ; ¾JVOº D M¼JÂJ; < U F UN¼J D S F I�æ%V FmF ;>=@?�¼JÂJ; < U F UN¼J D S F ILU S MO; â D S D ?lº�Ç D S F ; UN? F U@Æ F ; Ps¼J< D F à F º D P F Á%; ºmÂS D F º�= S º�=@¾J< D »�UNVJ?lº D S F Ó KU@Z����zÖ�È Ø º�=eº D F ¼W=N» D F U@Æ�ºm D F D PsUOM D < F UN¾Oº�=@; ? D M8V F ; ?JÀʺm DPsU F º D <>=@¾�U S =eº D M F UN¼JÂJ; F ºm;>» =eº D MÐ?W=@Ps; ?JÀ S VJ< D F®Ï Á%; ºmÂJUNVOº§¼W= S ºm;>=@< Ä U S M D SsS D MOVW»�ºm; UN? ÒÂW=NM�=@¾�UNVOº4¾L½ ý � ù Å ¾L½ ý �K] F º�=eº D F ÈJãé D ?�V F ; ?JÀ�?W=@P D =@¾ F º S =N»�ºm; UN?§ºm D Ã"Á D S D S D MOVW» D Mý ½ ý Å ¾ ý ¾/ºm; P D F Èzï S UNP5ºmÂJ; F Ij; º ; F ÇL; F ; ¾J< D ºmÂW=eº ?W=@P D =@¾ F º S =N»�ºm; UN?�» =@? S D =@< < Ã�< D =NMxºmU F ; À Ä?J; à » =@?lº S D MOVW»�ºm; UN? F ; ?�?LVJP)¾ D S F U@Æ F º�=eº D F Ie=@< ºmÂJUNVJÀNÂ)ºm D S D/D�½ ; F º F à F º D P F%Ï = F D È ÀWÈzºm DF à F º D PöU@Æ6MO; F º S ; ¾JVOº D Må¼JÂJ; < U F UN¼J D S F�Ò Á% D S D =@< S D =NMOÃ�ºm D PsU F º D <>=@¾�U S =eº D M F UN¼JÂJ; F[ĺm;>» =eº D M S VJ< D F S D PsUeÇ D PsU F º)U@Æ/ºm D ?W=@Ps; ?JÀ S D MOVJ?WMJ=@?W»�; D F È.X6 D F ¼ D D MOVJ¼ßUN¾Oº�=@; ? D MÇL;>=åV F ; ?JÀÞ?W=@P D =@¾ F º S =N»�ºm; UN?Ü; ?ÐUNV S D�½ =@Ps¼J< D F S =@?JÀ D MÞÆ S UNP Ç D S à F P�=@< <6? D Àl=eºm; Ç DÇe=@< V D F VJ¼§ºmU  ½ ý ��^eÈ�ã�UeÁ D Ç D S IN; º%; F Æ�=@; S ºmU�?JU@º D ºmÂW=eº6ºm D F ; ºmVW=eºm; UN?§Á/UNVJ<>M§»�ÂW=@?JÀ D ; ÆÁ D V F D M®¾ D ºHº D S ÂW= F ®ÆáVJ?W»�ºm; UN? F =@?WM®; Æ/Á D Á D S D º D F ºm; ?JÀ F º�=eº D F ºmU"¾ D ;>M D ?lºm;>» =@<ÇL;>== F º S =@; ÀNÂlº%»�UNPs¼W= S ; F UN?§U@Æ.ºm D =@¼J¼ S UN¼ S ;>=eº D ¾J< UO» GOF U@ÆiP D PsU S ÃNÈ Ñ ?§ºm D U@ºm D S ÂW=@?WM�IV F ; ?JÀ F VW»�Âʺ D »�ÂJ?J; ¿ V D F ; F À D ? D S =@< < î¼ S UN¾J< D P�=eºm;>»s; ?ÞºmULUN< F ¾W= F D MÊUN?ÞÆáVJ?W»�ºm; UN?W=@<EU S< UNÀN;>» =@<¢<>=@?JÀNVW=@À D F ÈË F =ß»�UN?W»�< V F ; UN?1IÁ D » =@? F =zÃߺmÂW=eºPsU S D F ºmVWMO; D F = S D F ºm; < <�? D D M D M8ºmUß=@? F Á D Sºm D�¿ V D F ºm; UN?8Á% D ºm D S =@?WMÜ; ?ÐÁ%ÂJ;>»�Âл = F D F ; º�; F ¾ D ºHº D S ºmUß=@< < UeÁ ¾J; ÀNÀ D S P D PsU S û�UN? F VJPs¼Oºm; UN?�=@?WM"Á% D ?"ºmUsV F D ?W=@P D =@¾ F º S =N»�ºm; UN?1È
ß��`_�a¦'�¡('�,¢Ñ+�¤"¡(àP) +�¢Ñ+�'*) è�¢�.�'�:�0�243537698;:íb?ºmÂJ; F6F D »�ºm; UN?1IlÁ D Á%; < <¢P D ?lºm; UN? F D Ç D S =@<WP D ºmÂJUOM F ; ?lº D ?WM D M�ºmU�¾ D V F D M; ?ºm D »�UN? ĺ D�½ º6U@Æ Ñ$Ñ ÉEÌ F ºmU�; Ps¼ S UeÇ D ºm D�D�è »�; D ?W»�Ã�U@Æ1ºm D »�<>= FmF ;>» =@<¢=@< ÀNU S ; ºmÂJPªU@Æ1À D ? D S =eºm; ?JÀÆáVJ< < F º�=eº D F ¼W=N» D F Ó T D ?WÔ�¾eÖ = F Á D < <i= F ; º F ¼J<>=@; ?�U S ¼W= S ºm;>=@<.U S M D S�S D MOVW» D M�M D ¼Oºm à S F ºÇe= S ;>=@?lº F º[ÃL¼J;>» =@< < ÃV F D M§ÆáU S ÆáU S P�=@<�Ç D S ; à » =eºm; UN? Ó É D <>Ô��jÖ�È
48
� ACN�LBEJ�K�®G,9� « >CAEIC�9<°¯ � DM�DMA��`DM<�>CAbBs< « �L�IXACN�ï Ë ?�; Ps¼�U S º�=@?lº%¼W= S º6U@Æ.ºm D ºm; P D? D D M D MåÆáU S À D ? D S =eºm; ?JÀ�= F º�=eº D F ¼W=N» D ; F�F ¼ D ?lº�º D F ºm; ?JÀ�Á% D ºm D S ="ÀN; Ç D ? F º�=eº D ÂW= F=@< S D =NMOÃ$¾ D D ?�; ?W»�< VWM D M�; ?lºmUxºm D F º�=eº D F ¼W=N» D U S ?JU@ºjÈ@íb?�ºm D » = F D U@Æ�Ì Ë F º�=eº D F ¼W=N» D F IºmÂJ; F ; F D F ¼ D »�;>=@< < Ãå» S ; ºm;>» =@<2MOV D ºmU"ºm D ºm; P D Ä »�UN? F VJPs; ?JÀ"º D F º F U@Æ Dj¿ VJ; Çe=@< D ?W» D VJ¼ÊºmUS D ?W=@Ps; ?JÀWÈEã D » =@? S D MOVW» D ºm D ºm; P D F ¼ D ?lº"UN?�»�UNPs¼W= S ; ?JÀ F º�=eº D F ¾LÃéM D » S D = F ; ?JÀ?LVJP)¾ D S F U@Æ F º�=eº D F ºmU"¾ D »�UNPs¼W= S D M�È�X6ÂJ; F » =@?å¾ D =N»�ÂJ; D Ç D M�¾Là S D ¼ S D F D ?lºm; ?JÀ F º�=eº DF ¼W=N» D F ¾LîÂW= F Âåº�=@¾J< D F ; ?WM D�½OD MåÇL;>= F VJ; º�=@¾J< D ÂW= F ÂåÆáVJ?W»�ºm; UN? F Á/U S G ; ?JÀ§UeÇ D S F º�=eº D F ÈX6 D ?ÞÁ D ÂW=zÇ D ºmU�»�UNPs¼W= S D UN?J< Ã�ºm D F º�=eº D F ÆáU S Á%ÂJ;>»�Âåºm D =@¼J¼J< ; D MÊÂW= F ÂåÆáVJ?W»�ºm; UN?S D ºmV S ? F ºm D F =@P D Çe=@< V D È
íb?§ºm D » = F D U@Æ Ï C Ò Ì Ë F º�=eº D F ¼W=N» D F Ilºm D$D Ps¼J< Ueà D MÂW= F ÂJ; ?JÀ�¼ S UO» D MOV S D P)V F º%¾ D; ? F D ? F ; ºm; Ç D ºmU�ºm D P D »�ÂW=@?J; F P'U@Æ?W=@P D =@¾ F º S =N»�ºm; UN?�=@¼J¼J< ; D M� D S D È�X.U§=N»�ÂJ; D Ç D ºmÂJ; FÁ D F VJÀNÀ D F º S D ¼ S D F D ?lºm; ?JÀ F º�=eº D F U@Æ Ñ$Ñ ÉEÌ F = FF Dj¿ V D ?W» D F U@Æ F º�=eº D F U@ÆWºm D Z[V F º/=N»�ºm; Ç DUN¾OZ D »�º F I F º�=eº D F U@ÆEºm D =N»�ºm; Ç D UN¾OZ D »�º F = FxF Dj¿ V D ?W» D F U@Æ F º�=eº D F U@Æ/ºm D ? D º�; ? F º�=@?W» D FD ?W» =@¼ F VJ<>=eº D Ms; ?�ºm D UN¾OZ D »�º F Il=@?WM�I à ?W=@< < ÃNI F º�=eº D F U@Æ¢ºm D ? D º/; ? F º�=@?W» D F = FEF Dj¿ V D ?W» D FU@Æ6ºm D P�= S G ; ?JÀ D < D P D ?lº F ¾ D < UN?JÀN; ?JÀ�ºmU�ºm D ¼W= S ºm;>»�VJ<>= S ; ? F º�=@?W» D F È.Û D ÆáU S D ÂW= F ÂJ; ?JÀUN? F VW»� F º�=eº D F Dj¿ V D ?W» D F IiÁ D ÆáV S ºm D S ÂW=zÇ D ºmU S D ¼J<>=N» D =@< </ºm D ;>M D ?lºm; àWD S F ¼ S D F D ?lº; ?8ºm D P ¾LÃÞºm D ?W=@P D F U@Æ�ºm D =@¼J¼ S UN¼ S ;>=eº D ? D º F =@?WM F U S º�ºm D ? D F º D M F Dj¿ V D ?W» D FU@Æ/P�= S G ; ?JÀ D < D P D ?lº F I1; ? F º�=@?W» D F I1=@?WMåUN¾OZ D »�º F =N» »�U S MO; ?JÀºmU"ºm D ; ?OÆáU S P�=eºm; UN?åºm D û�UN?lº�=@; ?s=eÆ�º D S ºm D S D ¼J<>=N» D P D ?lºU@Æ¢;>M D ?lºm; àWD S F ¾LÃ$ºm D = FmF UO»�;>=eº D M�º[ÃL¼J; ?JÀ$; ?OÆáU S P�=eºm; UN?1ÈX6 D M D F » S ; ¾ D Mܼ S D ¼W= S =eºm; UN?ÜU@Æ F º�=eº D F ÆáU S ÂW= F ÂJ; ?JÀÊ; F ¿ VJ; º D »�UNPs¼J< D�½ IiÂJUeÁ D Ç D S Ii; º» =@?�ÆáU S ºmVJ?W=eº D < Ã�¾ D S D =@< ; Å D Ms; ?"=@?§; ?W» S D P D ?lº�=@<�Á6=zÃNÈlX6 D M D F » S ; ¾ D M F »� D P D » =@?§¾ D; Ps¼ S UeÇ D MÞ¾Là S D ¼J<>=N»�; ?JÀ®; ? F º�=@?W» D ;>M D ?lºm; àWD S F ?JU@ºsUN?J< ÃÞ¾LÃʺm D =@¼J¼ S UN¼ S ;>=eº D º[ÃL¼J; ?JÀ; ?OÆáU S P�=eºm; UN?1IJ¾JVOºx=@< F U�¾Là F UNP D = FmF UO»�;>=eºm; Ç D ;>M D ?lºm; à » =eºm; UN?�; ? F D ? F ; ºm; Ç D ºmU S D ?W=@Ps; ?JÀ=@?WM D = F Ã8ºmUÜUN¾Oº�=@; ?1È Ë FmF UO»�;>=eºm; Ç D ;>M D ?lºm; à » =eºm; UN?éU@Æ�; ? F º�=@?W» D F » =@?�¾ D M D�à ? D Mé¾LÃPsUOM D < < D S F =@?WMÊ» =@?å¾ D ¾W= F D M®UN? F VJPsP�= S ; Å ; ?JÀ§Á%ÂW=eºxº S ; ÇL;>=@< UN¾OZ D »�º F = S D F ºmU S D M®; ?Á%ÂW=eº ¼J<>=N» D F U@ÆJºm D ; ? F º�=@?W» D F =@?WM�ÂJUeÁÞºm D F D ; ? F º�=@?W» D F = S D S D Æ D SmS D MxºmU�Æ S UNPͺm D S D F ºU@ÆEºm D F à F º D P�È1ïi; ?W=@< < ÃNI�PsUOM D < < D S F » =@?Ê D < ¼åºm D F à F º D Pö¾Lî¼ S UeÇL;>MO; ?JÀ§¼ S UO» D MOV S D FÆáU S%S D ¼ S D F D ?lºm; ?JÀs=eº�< D = F º F UNP D » S ; ºm;>» =@<�¼W= S º F U@Æ F º�=eº D F ; ?�=�VJ?J; ¿ V D Á6=zÃNÈ
c « �SIX<²�J�K�®±D@��A#d�eíBEJ"AEKSB � <°¯f(LA���DGJ�K�®~D@��A � AEKS� « J�K�®�d��E�ÑJ�²�� AEKSBCA�ï/X6 D Á/U S F º» = F D »�UNPs¼J< D�½ ; º[ÃÊU@Æ6º D F ºm; ?JÀ�ºm D S D ?W=@Ps; ?JÀ Dj¿ VJ; Çe=@< D ?W» D » =@?J?JU@º�¾ D M D » S D = F D M�I�¾JVOººm D =zÇ D S =@À D UN? D » =@?Þ¾ D ; Ps¼ S UeÇ D MʾLà D�½ ¼J< UN; ºm; ?JÀ�ºm D F º S VW»�ºmV S D U@Æ F º�=eº D F ; ? F º D =NMU@Æ)¾J< ; ?WMO< Ãéº D F ºm; ?JÀY=@< <x¼ D S P)VOº�=eºm; UN? F U@Æ);>M D ?lºm; àWD S F È6ã D » =@? S D ¼ S D F D ?lº F º�=eº D F = FU S ; D ?lº D M�À S =@¼J F Á%; ºm®º[Á/U G ; ?WM F U@Æ2?JUOM D F »�U SmS D F ¼�UN?WMO; ?JÀsºmU§? D ºx; ? F º�=@?W» D F =@?WM�ºmUP�= S G ; ?JÀ D < D P D ?lº F È�íb? F º�=@?W» D ?JUOM D F�F ÂJUNVJ<>M�¾ D < ; ? G D M"ºmU�ºm D =@¼J¼ S UN¼ S ;>=eº D P�= S G ; ?JÀD < D P D ?lº F =@?WM"ºmÂJU F D ºmUºm D ? D º�; ? F º�=@?W» D F ºm D à D Ç D ?lºmVW=@< < Ã�»�UN?lº�=@; ?1ÈWX D F ºm; ?JÀ F º�=eº D F¾ D ; ?JÀ Dj¿ VW=@<2VJ¼ÊºmU S D ?W=@Ps; ?JÀ�; F ºm D ?ʺ S =@? F ÆáU S P D M®ºmU®=�VJ?J; à » =eºm; UN?ÞU@Æ/ºm D ; S ��DM�DMA®�IX�X�L����º S D =eºm; ?JÀÞ;>M D ?lºm; àWD S F = F MO; F ºm; ?W»�º�º[ÃL¼ D MÐÇe= S ;>=@¾J< D F È2X6 D VJ?J; à » =eºm; UN?Y» =@?Y¾ D; Ps¼J< D P D ?lº D M®¾Là F ÃL?W»� S UN?JUNV F < ú S =zÇ D S F ; ?JÀ¾�U@ºm F º�=eº D À S =@¼J F =@?WM�VJ?J; ÆáÃL; ?JÀ§ºm D ; S?JUOM D F È × UN; ?JÀ)ºmÂJ; F Á D F ÂJUNVJ<>M¼ S D Æ D S VJ?J; ÆáÃL; ?JÀ�P�= S G ; ?JÀ D < D P D ?lº F »�UN?lº�=@; ?J; ?JÀ)º S ; ÇL;>=@<UN¾OZ D »�º F U S ?JUN?lº S ; ÇL;>=@<EUN¾OZ D »�º F Á%; ºmÂܺ[ÃL¼ D F Á%ÂJ;>»�ÂÜ= S D VJ?J; ¿ V D Á%; ºmÂJ; ?ܺm D P�= S G ; ?JÀU@ƺm D =@¼J¼ S UN¼ S ;>=eº D ¼J<>=N» D F È�X6ÂLV F Á D » =@? à ?WMåMO; â D S D ?W» D F = F�F ULUN?®= F ¼�U FmF ; ¾J< D =@?WMS D MOVW» D ºm D =@PsUNVJ?lº2U@Æ¢¾W=N» G º S =N» G ; ?JÀ F º D PsPs; ?JÀxÆ S UNP P�=eº�»�ÂJ; ?JÀxUN¾OZ D »�º F U@Æ�ºm D F =@P Dº[ÃL¼ D F ºmU S D Må; ?ʺm D F =@P D ¼J<>=N» D Á%; ºmÂʺm D ; S MO; â D S D ?lº�¼�U FmF ; ¾J< D »�UNVJ?lº D S ¼W= S º F ; ?ʺm DF =@P D ¼J<>=N» D U@ÆJºm D U@ºm D S F º�=eº D ÈeïJV S ºm D S PsU S D I Á D » =@? D�½ ¼J< UN; º.ºm D =@< S D =NMOÃ�P D ?lºm; UN? D M= FmF UO»�;>=eºm; Ç D ;>M D ?lºm; à » =eºm; UN?ÐU@Æ�; ? F º�=@?W» D F  D S D I= F Á D < <}È2X6ÂJ; F » =@?8¾ D MOUN? D ; ? F VW»�Â
49
=)Á6=zÃ)ºmÂW=eº%Á D MOU�?JU@º6VJ?J? D » D FmF = S ; < Ãs»�UNPs¼W= S D ; ? F º�=@?W» D F Á%; ºmÂ�MO; â D S D ?lº%= FmF UO»�;>=eºm; Ç D;>M D ?lºm; à » =eºm; UN?"» =@¼OºmV S ; ?JÀ)ºm D ; S < UO» =@< F º�=eº D F ; ?�= S D ?W=@Ps; ?JÀ�; ? F D ? F ; ºm; Ç D Á6=zÃNÈLïi; ?W=@< < ÃNIPsUOM D < < D S F » =@?®=@Àl=@; ?� D < ¼®ºm D F à F º D P,¾LÃ�¼ S UeÇL;>MO; ?JÀ¼ S UO» D MOV S D F ÆáU S »�UNPs¼W= S ; ?JÀ§=eº< D = F º F UNP D F D < D »�º D M"; ? F º�=@?W» D F ; ?�=�P�=@?LVW=@< < à F ¼ D »�; àWD MÆ�= F º�Á6=zÃNÈ�1<IXAgd�eíBEJ"AEKLD%h��I�>C��®�A#Bs<��� ACBEDGJ�K�®�ï�X6 D M D�à ?J; ºm; UN?�U@Æ Ñ$Ñ ÉEÌ F P�= G D F Àl= S ¾W=@À D»�UN< < D »�ºm; ?JÀ®=�¼W= S º�U@Æ D Ç D S à D Ç D ?lºjÈiÉ D S ÆáU S Ps; ?JÀ�Àl= S ¾W=@À D »�UN< < D »�ºm; ?JÀ®P D =@? F ºmÂW=eº)Á DÂW=zÇ D ºmU�º S =zÇ D S F D ºm D =@¼J¼ S UN¼ S ;>=eº D F º�=eº D À S =@¼JÂ Ï Á%ÂJ;>»�Â"» =@?�¾ D »�UNPs¼JVOº D M; ?W» S D P D ? ĺ�=@< < Ã Ò =@?WM à ?WM®UNVOº�Á%ÂJ;>»�Âå; ? F º�=@?W» D F » =@?J?JU@º�¾ D S D =N»� D M"Æ S UNP'ºm D S ULU@ºjÈSã�UeÁ D Ç D S IºmÂJ; F »�UNPs¼JVOº�=eºm; UN?Þ; F ?JU@º)? D » D FmF = S î; ? D Ç D S à F º D ¼ß¾ D » =@V F D ?JU@º D Ç D S à F º D ¼ßP�= G D F
F UNP D ; ? F º�=@?W» D UN¾ F UN< D º D ÈWí�º�; F�F V è »�; D ?lº�ºmU¼ D S ÆáU S P,Àl= S ¾W=@À D »�UN< < D »�ºm; ?JÀUN?J< Ã"Á% D ?à S ; ?JÀ®=@? D Ç D ?lº�Á%ÂJ;>»�Âß; ?W»�< VWM D F =�»�ÂW=@?JÀ D U@Æ6P�= S G ; ?JÀ�ÇL;>=�= S » F U@Æ%=�º S =@? F ; ºm; UN?ÞU S=x¼�U S º2; ? F » S ; ¾ D M�¾LÃ�=j� <��C��²�I�J"��>E� A�¾�UNVJ?WM�ºmU�=x?JUN?lº S ; ÇL;>=@<OUN¾OZ D »�ºjÈ��1U FmF Çe= S ;>=@¾J< D F U@Ƽ�U S º F =@?WM�º S =@? F ; ºm; UN? F = S D ºm D Çe= S ;>=@¾J< D F Á%ÂJ;>»�§=@¼J¼ D = S UN?�; ?J¼JVOº6¾JVOº/?JU@ºEUN?�UNVOºm¼JVOº= S » F È Ñ ¾OZ D »�º F ¾�UNVJ?WMºmU F VW»�Â"Çe= S ;>=@¾J< D F = S D < ; G D < Ã�ºmU�¾ D < U F º%=@?WM§Á D ÂW=zÇ D ºmU�»� D » GºmÂW=eº�V F ; ?JÀ§Àl= S ¾W=@À D »�UN< < D »�ºm; ?JÀWÈWí�ºx; F ?JU@º�? D » D FmF = S úmU§Á/U S G Á%; ºm®< U FmF Çe= S ;>=@¾J< D F U@ƺ S =@? F ; ºm; UN? F ; ?LÇNUN< Ç D M"; ?;Ê D Ç D ?lº F ¾ D » =@V F D ºm D »�UNPs¼J< D º D ¾J; ?WMO; ?JÀU@Æ ºm D ; S Çe= S ;>=@¾J< D F; F6F ºmU S D MÁ%; ºmÂJ; ?§ºm D =@¼J¼ S UN¼ S ;>=eº D ; ?LÇNUO» =eºm; UN? F ; ?ºm D P�= S G ; ?JÀ)U@Æ.ºm D F D º S =@? F ; ºm; UN? F Èíb?�ºm D » = F D U@Æ©Ë D Ç D ?lº F IJÁ D ÂW=zÇ D ºmU F º�= S º�Àl= S ¾W=@À D »�UN< < D »�ºm; UN?�=@< F U�; ƺm D S D S D P�=@; ?F UNP D ?JUN?lº S ; ÇL;>=@<lUN¾OZ D »�º F6Ï MO; â D S D ?lºiÆ S UNPͺm D S D F VJ< º U@ÆOºm D6D Ç D ?lº Ò ; ?)ºm D ? D º ; ? F º�=@?W» D¾ D ; ?JÀ à ?J; F  D M�È�æ%VJ?lºm; P D »� D » G ; ?JÀxÁ% D ºm D S =�< U FmF Çe= S ;>=@¾J< D ; F ¾�UNVJ?WM)ºmU$=�?JUN?lº S ; ÇL;>=@<UN¾OZ D »�ºx» =@? F UNP D ºm; P D F ¾ D =zÇNUN;>M D M�V F ; ?JÀ"= F º�=eºm;>»$º[ÃL¼ D =@?W=@< à F ; F Á%ÂJ;>»�Âå» =@?�º D < < V FºmÂW=eº%ºm D =@¼J¼ S UN¼ S ;>=eº D Çe= S ;>=@¾J< D » =@?�¾ D ¾�UNVJ?WM§ºmU�º S ; ÇL;>=@<�UN¾OZ D »�º F UN?J< ÃNÈ
Bs< « �S�ÑDGJ�K�®Id©KS��>E� ACNId©²AEKLD"�©J�K5�KGc�KSBEIXA « AEKLDM���ð;� � ïeãé D ?�Á D Á6=@?lº.ºmU D�½ ¼J< U S DF VW» » D FmF U S F U@Æ1= F º�=eº D Á D�à S F ºEÂW=zÇ D ºmU�»�UNPs¼JVOº D ºm D F D º/U@Æ1=@< <Wºm D�D Ç D ?lº F D ?W=@¾J< D M�; ?ºmÂW=eº F º�=eº D È�ã�UeÁ D Ç D S I@Á% D ?§Á D =N» » D ¼Oº6=�< ; ºHºm< D ¾J; º6; ?W» S D = F D M�P D PsU S à S Dj¿ VJ; S D P D ?lº FÁ D MOU�?JU@º$ÂW=zÇ D ºmU�»� D » G ºm Dsà S =@¾J; < ; º[Ã�U@Æ6=@< < º S =@? F ; ºm; UN? F ; ?ß=@< < ? D º�; ? F º�=@?W» D F ÆáU SD Ç D S ÃÜ? D Á F º�=eº D Æ S UNP = F » S =eº�»�Â1ÈX6ÂJ; F ; F ¾ D » =@V F D ºm D F D º�U@Æ D Ç D ?lº F D ?W=@¾J< D MÐ; ?= F º�=eº D » =@?å¾ D »�UNPs¼JVOº D M®; ?Ê=@?®; ?W» S D P D ?lº�=@<iÁ6=zà F º�= S ºm; ?JÀ§Á%; ºm®ºm D F D º�U@Æ D Ç D ?lº FD ?W=@¾J< D MÞ; ?ß=�¼ S D M D » D FmF U S F º�=eº D U@Æ/ºm D ÀN; Ç D ? F º�=eº D =@?WM§Z[V F ºs=NMJMO; ?JÀ�U S�S D PsUeÇL; ?JÀF UNP D�D Ç D ?lº F =N» »�U S MO; ?JÀʺmU S D Ä »� D » G ; ?JÀåºm D�à S =@¾J; < ; º[Ã8U@Æ F UNP D º S =@? F ; ºm; UN? F ÈE:�U S D¼ S D »�; F D < ÃNILÁ D ÂW=zÇ D ºmU D�½ =@Ps; ? D =@< <�ºm D º S =@? F ; ºm; UN? F Á%ÂJ;>»�Â"= S D »�UN?J? D »�º D M�ºmUs=eº6< D = F ºUN? D ; ?J¼JVOº¼J<>=N» D Á%ÂJU F D P�= S G ; ?JÀÊÁ6= F »�ÂW=@?JÀ D M�ÈïJV S ºm D S PsU S D IÁ D ÂW=zÇ D ºmUß»� D » Gº S =@? F ; ºm; UN? F Á%ÂJU F D ÀNVW= S M F » =@?ÊV F D UN¾OZ D »�º F Á%ÂJU F D F º�=eº D Á6= F »�ÂW=@?JÀ D M®; ?Þ="ÇL; F ; ¾J< DÁ6=zÃNÈ Ë ?åUN¾OZ D »�º�; F »�ÂW=@?JÀ D M�; ?Ê=�ÇL; F ; ¾J< D Á6=zÃ"; Æ2ºm D S D ; F =¼�U S º�; ?®ºm D »�<>= FmF U@Æ2ºm DUN¾OZ D »�º/Á%ÂJ;>»�§» =@? S D =NM�ºm D »�UN?lº D ?lº F U@Æ.=@?UN¾OZ D »�º/? D º/¼J<>=N» D Á%ÂJU F D P�= S G ; ?JÀ�Á%; ºmÂJ; ?ºm D UN¾OZ D »�º�Á6= F »�ÂW=@?JÀ D MÞU S Á%ÂJ;>»�Â8»�UN?lº�=@; ? F =®ÇL; F ; ¾J< Ãß»�ÂW=@?JÀ D MßUN¾OZ D »�ºjÈ�ã�UeÁ D Ç D S I?JU@º D ºmÂW=eº)ºm D Z[V F º�M D F » S ; ¾ D MÞP D »�ÂW=@?J; F P9» =@?ß¾ D =@¼J¼J< ; D MßUN?J< ÃÞÁ% D ?ÜÁ D S Dj¿ VJ; S DºmÂW=eº§ÀNVW= S M D�½ ¼ S D FmF ; UN? F U@Æ Ñ$Ñ ÉEÌ F » =@?J?JU@ºº D F º"=@?LÃ8UN¾OZ D »�º F Á%; ºmÂJUNVOº§U S ¾ D ÆáU S DS D =NMO; ?JÀ�ºm D P�Æ S UNP F UNP D ¼J<>=N» D F ÈiÌ D Ç D S ºm D < D FmF I1ºmÂJ; F S D F º S ;>»�ºm; UN?ßU@Æ%ºm D ?JU@ºm; UN?ßU@ÆÑ$Ñ ÉEÌ F6F D D P F ºmUs¾ D�¿ VJ; º D ¼ S =N»�ºm;>» =@<}È
i Ü6÷$ò.¸�¹[ùmô�¹H²�j ûå´Jµ2÷$ò1´O³J¹[ò.øÞµ2ù;Ü/ô�øN³OòlkªøPÕ�µ8mÞò�n:o�ÚmÙH·�Úi³Oò.¶
íb?�ºmÂJ; F�F D »�ºm; UN?1I�Á D Á%; < < MO; F »�V FmF�F D Ç D S =@<1¼�U FmF ; ¾J< D Á6=zà F U@Æ F ¼ D »�; ÆáÃL; ?JÀ§¼ S UN¼ D S ºm; D F ºmU¾ D$D Çe=@< VW=eº D M§UeÇ D S F º�=eº D F ¼W=N» D F U@Æ F à F º D P F PsUOM D < D M"¾Là Ñ$Ñ ÉEÌ F È
50
:�U F º�U@ƺm D »�UNPsPsUN?®Á6=zà F U@Æ F ¼ D »�; ÆáÃL; ?JÀ§¼ S UN¼ D S ºm; D F ºmU"¾ D »� D » G D M�UeÇ D S F º�=eº DF ¼W=N» D F U@ÆWPsUOM D < F ¾W= F D M�UN?sMO; â D S D ?lº PsUOM D < < ; ?JÀx<>=@?JÀNVW=@À D F Ó K2=@<>ÔNÕzÖW» =@?)¾ D V F D M�Á%; ºmÂÑ$Ñ ÉEÌ Ä ¾W= F D MPsUOM D < F ILºmULUWÈJã D » =@?§ºmÂJ; ? G U@ÆiV F ; ?JÀsºm D ÆáUN< < UeÁ%; ?JÀs=eºHºm; ºmVWM D F��p D Çe=@< VW=eºm; ?JÀ`��DM�DMAs�G�L��BCAq��DM�DGJ���DGJ"B�� F VW»�Â$= F ?LVJP)¾ D S F U@Æ F º�=eº D F I�?LVJP)¾ D S F U@Æ F º S UN?JÀN< û�UN?J? D »�º D M�»�UNPs¼�UN? D ?lº F IO¾�UNVJ?WM F U@Æ ¼J<>=N» D F IJÉ D º S ;�? D º�< ; Ç D º S =@? F ; ºm; UN? F I D º�»@È Ip ¼ S UN¼�U F ; ?JÀY= ²AEIC���DGJ�� A~��DM�DMA1�G�L��BCAq�E�LAEI � � �K�®��L��®�AÞºmUé=@< < UeÁêV F D S Ä »�UN?lº S UN< < D Mº S =zÇ D S F ; ?JÀ�ºm S UNVJÀN F º�=eº D F ¼W=N» D F =@?WM D�½ =@Ps; ?J; ?JÀ�ºm DxD ?W»�UNVJ?lº D S D M F º�=eº D F Ip J�K���DGI�� « AEKLDGJ�K�® « <�N�AE� ��¾Lî¼ S UN¼ D S º[Ã�<>=@¾ D < FxF VW»�ÂÞ= F D ?WM ÄbF º�=eº D <>=@¾ D < F I�¼ S UNÀ S D FmF<>=@¾ D < F IW= FmF D S ºm; UN? F I D º�»@ÈOU S ¾Lü S UN¼ D S º[ç=@VOºmUNP�=eº�=JIp V F ; ?JÀ�=5��J ®��;� AE²AE���G�LACBEJ ä©BC�DGJ"<K1� �K�®��L��®�A F VW»�Â�= F%F UNP D º D Ps¼�U S =@<�< UNÀN;>»@È:�U F º§U@Æ$ºm D =@¾�UeÇ D < ; F º D M�=eºHºm; ºmVWM D F ÂW=zÇ D ºmU8¾ D F < ; ÀNÂlºm< Ãé=N» »�UNPsPsUOMJ=eº D MÐÆáU Sºm D »�UN?lº D�½ º�U@Æ Ñ$Ñ ÉEÌ F =@?WMߺm D ; S F º�=eº D F ¼W=N» D F È ïJU S D�½ =@Ps¼J< D Ii¾�UNVJ?WM F U@Æ�¼J<>=N» D FU@Æ Ñ$Ñ ÉEÌ F"F ÂJUNVJ<>M�¾ D »�UNPs¼JVOº D M F D ¼W= S =eº D < Ã8ÆáU S ¼W= S ºm;>»�VJ<>= S ; ? F º�=@?W» D F =@?WMYºm D ?
= P�= ½ ; P)VJP F ÂJUNVJ<>Mо D »�ÂJU F D ?1I2¼W= S ºm;>»�VJ<>= S ¼ S UN¼ D S º[Ã8<>=@¾ D < FF ÂJUNVJ<>MY¾ D Z[UN; ?lº§; ?= F VJ; º�=@¾J< D Á6=zà D ; ºm D S Á%; ºmÂå¼J<>=N» D F U S º S =@? F ; ºm; UN? F U@Æ Ñ$Ñ ÉEÌ F I D º�»@ÈSã�UeÁ D Ç D S IOºm D S D= S ; F D F UN? D PsU S D À D ? D S =@<@¼ S UN¾J< D Pó D S D Á%ÂJ;>»�Âx; ?OìWV D ?W» D F =@< PsU F º.=@< <@U@ÆLºm D P D ?lºm; UN? D M=eºHºm; ºmVWM D F�Ï PsU S D ¼ S D »�; F D < ç=@< <¢U@Æiºm D PëVJ¼"ºmU F º�=eº D F ¼W=N» D F º�=eºm; F ºm;>» F�Ò ÈJX6ÂJ; F ¼ S UN¾J< D P; F ¿ V D S ÃL; ?JÀ�¼W= S ºm;>»�VJ<>= S F º�=eº D F =@?WM D Ç D ?lº F U@Æ Ñ$Ñ ÉEÌ F ÈX6 D P�=@; ?�¼ S UN¾J< D PëºmU�¾ D F UN< Ç D M§Á% D ? ¿ V D S ÃL; ?JÀ F º�=eº D F =@?WM D Ç D ?lº F U@Æ Ñ$Ñ ÉEÌ FF º D P F Æ S UNP ºm D MOÃL?W=@Ps; F P�U@Æ Ñ$Ñ ÉEÌ F È.ã D ÂW=zÇ D ºmUå¼ S D ¼W= S D ºmULUN< F ÆáU S D�½ ¼J< U S ; ?JÀ¼ S UN¼ D S ºm; D F U@Æ F D º F U@Æ F º�=eº D F =@?WM D Ç D ?lº F ; ?�=�Á6=zÃÁ%ÂJ;>»� S D F ¼ D »�º F ºm D Æ�=N»�º%ºmÂW=eº%ºm DF D º F U@Æ D�½ ; F ºm; ?JÀÊ; ? F º�=@?W» D F Iiºm D ; S ?W=@P D F =@?WM S D <>=eºm; UN? F » =@?8¾ D MO; â D S D ?lº�; ? D Ç D S ÃD ?W»�UNVJ?lº D S D M F º�=eº D =@?WM�» =@?J?JU@º�¾ D ÆáVJ< < Ã"¼ S D MO;>»�º D M�È�X6 D S D ÆáU S D ; º�; F ?JU@º�¼�U FmF ; ¾J< D ºmUV F D = F/F ; Ps¼J< D$¿ V D S ; D F = F D È ÀWÈL; ? ×�D F ; ÀN?�r C ÉEÌ�I F VW»�Â"= F �[º�= G D ºm D P�= S G ; ?JÀ)U@Æ F UNP D¼J<>=N» D ò Æ S UNP ºm D F º�=eºm;>»�? D º�; ? F º�=@?W» D VJ?W=@P)¾J; ÀNVJUNV F < Ã�;>M D ?lºm; àWD M"¾Là [M\ � Èãé; ºmÂJ; ?�=)¼ S U@ºmU@º[ÃL¼ D U@Æ =@? Ñ$Ñ ÉEÌ F º�=eº D F ¼W=N» D ºmULUN<}IOÁ D ÂW=zÇ D F VJÀNÀ D F º D M§= F UN< V ĺm; UN?"U@Æiºm D =@¾�UeÇ D ¼ S UN¾J< D Pë¾W= F D M§UN?§º[Á/U�À S UNVJ¼ F U@Æ.ÆáVJ?W»�ºm; UN? F ÈWïi; S F º%U@Æ =@< <}IOÁ D V F Dºm D F U Ä » =@< < D MjJ�K���DM�KSBCAI�E�LAEI � J�K�®q¯C�ÑKSBEDGJ"<K���ÈeX6 D Ã�=@< < UeÁßV F ºmU�¾ D ÀN; ?)Á%; ºmÂ)ºm D VJ?J; ¿ V D; ?J; ºm;>=@<2UN¾OZ D »�º$? D º�; ? F º�=@?W» D U S Á%; ºm F D º F U@Æ/ºm D Z[V F º D�½ ; F ºm; ?JÀ�; ? F º�=@?W» D F U@Æ%» D S º�=@; ?? D º F ÀN; Ç D ? F º�=eºm;>» =@< < Ã�¾Lçºm D ; S º[ÃL¼ D F È Ø VJ¾ F Dj¿ V D ?lºm< ÃNIWºm D Ã�=@< < UeÁ5ºmU S D »�V S F ; Ç D < Ã"M D ÄS ; Ç D F D º F U@ÆWºm D ? D º2; ? F º�=@?W» D F U S »�UN? F º�=@?lº FF º S =@; ÀNÂlºU S º S =@? F ; ºm; Ç D < à S D Æ D S D ?W» D M�Æ S UNPºm D =@< S D =NMOà G ?JUeÁ%?®; ? F º�=@?W» D F ÇL;>=�ºm D P�= S G ; ?JÀU@Æ F UNP D U@Æ2ºm D ; S ¼J<>=N» D F U S º S =@? F ; ĺm; UN? F ÈlX6 D S D =@< F U D�½ ; F º F =�ÆáVJ?W»�ºm; UN? S D ºmV S ?J; ?JÀ$ºm D F D ºEU@Æ�P D ºmÂJUOM�? D º/; ? F º�=@?W» D F Z[V F ºS VJ?J?J; ?JÀsUeÇ D S F UNP D ÀN; Ç D ?"UN¾OZ D »�º F È
íb? F º�=@?W» D)¿ V D S ÃL; ?JÀ�ÆáVJ?W»�ºm; UN? F = S D ; ?lº D ?WM D M�ºmU§¾ D »�UNP)¾J; ? D M�Á%; ºmÂ�ºm D F U Ä » =@< < D M��AED�J�DMAEIX�DGJ�K�®m¯C�ÑKSBEDGJ"<K��E; ?)U S M D S ºmU�UN¾Oº�=@; ?$ºm D =@¼J¼ S UN¼ S ;>=eº D »�ÂW= S =N»�º D S ; F ºm;>» F U@Æ F º�=eº D F ÈØLD º§; º D S =eºm; ?JÀÊÆáVJ?W»�ºm; UN? F =@< < UeÁ F D = S »�ÂJ; ?JÀ F UNP D ÂJUeÁä; ?lº D S D F ºm; ?JÀÞ; ? F º�=@?W» D F U S »�UN? ÄF º�=@?lº F ; ? F D º F S D ºmV S ? D M�¾Lçºm D ; ? F º�=@?W» D)¿ V D S ÃL; ?JÀsÆáVJ?W»�ºm; UN? F È�ã D » =@?�ÆáU S D�½ =@Ps¼J< Dº�= G D =@< <2ºm D Z[V F º D�½ ; F ºm; ?JÀ®; ? F º�=@?W» D F U@Æ F UNP D ? D ºjI F D < D »�º�ºm D UN? D F Á%ÂJ;>»�Â8»�UN?lº�=@; ?F UNP D »�UN? F º�=@?lº%; ? F UNP D ¼J<>=N» D IJ=@?WM�ºm D ?�ÀNU�UN?"¾Là D�½ ¼J< U S ; ?JÀ F UNP D U@ºm D S ; ? F º�=@?W» D FS D Æ D S D ?W» D MÆ S UNP ºm D F D < D »�º D M"UN? D F ÈØ U�Æ�= S Á D ÂW=zÇ D ¾ D D ? F ¼ D = G ; ?JÀ�=@¾�UNVOºiÆáVJ?W»�ºm; UN? F ÆáU S ¿ V D S ÃL; ?JÀ Ñ$Ñ ÉEÌ F º�=eº D F UN?J< ÃNÈã�UeÁ D Ç D S I D�½ =@Ps; ?J; ?JÀ D Ç D ?lº F/F D D P F ºmU)¾ D =�< ; ºHºm< D�D = F ; D S Èlí�º6; F D ?JUNVJÀNÂ�ºmU�ÂW=zÇ D ºmULUN< FÆáU S =N» » D FmF ; ?JÀ§ºm D ¼W= S ºm;>»�VJ<>= S ; º D P F U@Æ D Ç D ?lº F I�;}È D È¢ºm D ; S º[ÃL¼ D I¢ºm D º S =@? F ; ºm; UN?åºm D Ã= S D ¾�UNVJ?WM§ºmUWILºm D ; ? F º�=@?W» D ºm D Ã"= S D�à S ; ?JÀs; ?1IW=@?WMºm D =@¼J¼ S UN¼ S ;>=eº D ¾J; ?WMO; ?JÀWÈ
51
X6 D ÆáVJ?W»�ºm; UN? F ÆáU S ¿ V D S ÃL; ?JÀ F º�=eº D F =@?WM D Ç D ?lº F » =@?�¾ D F º S =@; ÀNÂlº�V F D M®= F =�¼W= S ºU@Æ=sÇ D S F =eºm; < D Ñ$Ñ ÉEÌ F º�=eº D F ¼W=N» D�¿ V D S Ã<>=@?JÀNVW=@À D ÆáU S D�½ =@Ps; ?J; ?JÀ�ºm D�D ?W»�UNVJ?lº D S D MF º�=eº D F =@?WM D Ç D ?lº F È.:�U S D UeÇ D S I�ºm D ÃÞ» =@?Þ¾ D V F D MÊÆáU S M D F » S ; ¾J; ?JÀ"º D S P F D P)¾ D MJM D M; ?�º D Ps¼�U S =@<.< UNÀN;>»xÆáU S P)VJ<>= D F ¼ D »�; ÆáÃL; ?JÀ¼ S UN¼ D S ºm; D F U@Æ F à F º D P F ºmU¾ D Ç D S ; àWD M�V F ; ?JÀºm D ; S Ñ$Ñ ÉEÌ Ä ¾W= F D MßPsUOM D < F Èïi; ?W=@< < ÃNI ºm D Ã8» =@?Ð=@< F Uʾ D =@¼J¼J< ; D M8Á% D ? F ¼ D »�; ÆáÃL; ?JÀ< D Àl=@<¢º D S Ps; ?W=eºm; UN? F º�=eº D F IO¼ S UNÀ S D FmF D Ç D ?lº F IOU S F à F º D Pë; ?LÇe= S ;>=@?lº F È
ã D Á%; < <.?JUeÁÎM D F » S ; ¾ D =�< ; ºHºm< D PsU S D F UNP D U@ƺm D ; ? F º�=@?W» D)¿ V D S ÃL; ?JÀ�ÆáVJ?W»�ºm; UN? F Èã D M D F » S ; ¾ D ºm D P5; ?$ºm D ÆáU S P5U@ÆJÉ S UN< UNÀ6¼ S D MO;>» =eº D F = F ºm D Ãx= S D M D »�<>= S D M�; ?xºm D ¼ S U ĺmU@º[ÃL¼ D ºmULUN<WV F ; ?JÀxºm D P�ÈLX6 D Ãs=@< <Oº�= G D ºm D »�V SmS D ?lº F º�=eº D ºmU�¾ D ; Ps¼J< ;>»�; º6=@?WM S D ºmV S ?ºm D S D F VJ< º/ÇL;>=xºm D ; S <>= F º/¼W= S =@P D º D S ÈNX6 D ¼ S D MO;>» =eº D&´�Ç ´�sNtvu0wXx S D ºmV S ? F ºm D F D ºEÁ%; ºmºm D ; ?J; ºm;>=@<WUN¾OZ D »�ºE? D º/; ? F º�=@?W» D ÈlX6 D ¼ S D MO;>» =eº D&´�Ç�w�sNtFyzw|{ Æ w|{[u0wXx S D ºmV S ? F ºm D F D ºEU@ƺm D Z[V F º D�½ ; F ºm; ?JÀ�; ? F º�=@?W» D F ¾ D < UN?JÀN; ?JÀ�ºmU�ºm D ? D º F Æ S UNPͺm D F D º�Æ w =@?WM S VJ?J?J; ?JÀ�UeÇ D SUN¾OZ D »�º F ¾ D < UN?JÀN; ?JÀ�ºmU�ºm D »�<>= FmF D F Æ S UNP yzw ÈeX6 D ¼ S D MO;>» =eº DWs~}���È�Ç�tvu0w|{��5w|{�yzw|{��zwXx S D ĺmV S ? F ºm D F D º6U@Æ1ºmU G D ? F ¾ D < UN?JÀN; ?JÀ�ºmU)ºm D »�<>= FmF D F Æ S UNP yzw =@?WM F ºmU S D M�; ?ºm D ¼J<>=N» D FÆ S UNP �5w Á%; ºmÂJ; ?åºm D ; ? F º�=@?W» D F Æ S UNP u0w È�X6 D ¼ S D MO;>» =eº D¦´�ÇX�~}~�ltvu0w|{��5w|{�yzw|{ Æ w|{/��w<xS D ºmV S ? F ºm D F D ºiU@ÆW; ?LÇNUO» =eºm; UN? F U@ÆOºm D º S =@? F ; ºm; UN? F Æ S UNP �5w Á%; ºmÂJ; ?)ºm D ; ? F º�=@?W» D F Æ S UNPu0w È.X6 D ; ?LÇNUO» =eºm; UN? F = S D S D ¼ S D F D ?lº D Må¾Lîºm D =@¼J¼ S UN¼ S ;>=eº D ¾J; ?WMO; ?JÀ F =@?WMÊUN?J< îºm DUN? D F = S D F D < D »�º D M§Á%ÂJ;>»�§<>=@VJ?W»�Â"? D º F Æ S UNPÞÆ w UeÇ D S UN¾OZ D »�º F U@Æ.ºm D »�<>= FmF D F Æ S UNP yzw Èïi; ?W=@< < ÃNINºm D ¼ S D MO;>» =eº D%}���È��Ntvu0wz�3{ Æ w|{[u0w��zx »�UN< < D »�º F =@< <Jºm D ; ? F º�=@?W» D F U@Æ�ºm D ? D º F ; ?Æ w Á%ÂJ;>»� S VJ?�UeÇ D S ºm D UN¾OZ D »�º F ; ? u0wz� È
Ñ VOº�U@Æiºm D À S UNVJ¼"U@Æiºm D F D º�; º D S =eºm; ?JÀsÆáVJ?W»�ºm; UN? F IWÁ D » =@?�P D ?lºm; UN?�ÆáU S D�½ =@Ps¼J< Dºm D ÆáUN< < UeÁ%; ?JÀ"UN? D F È1X6 D ¼ S D MO;>» =eº D#wK�X}��~�X�<�|t��6{���{���{���x S D ºmV S ? F s<�0�LÈ ; ? � ; âܺm D¼ S D MO;>» =eº DG� UeÇ D S � ; F ÆáVJ< à < < D MåUeÇ D S D Ç D S à D < D P D ?lºxU@Æ2ºm D ?JUN? Ä D Ps¼Oº[à F D º � Á%ÂJU F DD < D P D ?lº F = S D UN? D Ä ¾LÃ Ä UN? D ¾�UNVJ?WMsºmU � È Ñ ºm D S Á%; F D Il=)»�UNVJ?lº D S Ä D�½ =@Ps¼J< D ; F ÆáUNVJ?WM=@?WM¾�UNVJ?WM�ºmU � È¢X6 D ¼ S D MO;>» =eº D�w�ÈX��È~��sNt����3{���{���{F�<�~x F D < D »�º F =@< <.ºm D�D < D P D ?lº F � Æ S UNP��� Á%ÂJ;>»�§ÆáVJ< à < <1ºm D ¼ S D MO;>» =eº Dg� UeÇ D S � È
� D º%V F ?JUeÁó¼ S D F D ?lº%=@? D�½ =@Ps¼J< D U@Æ D�½ =@Ps; ?J; ?JÀ F º�=eº D F U@Æ Ñ$Ñ ÉEÌ F ÈOïJU S ºmÂJ; F S D = ÄF UN?1ILÁ D Á%; < <�V F D =)PsUOM D <�U@Æ1ºm D F à F º D P U@ÆiMO; F º S ; ¾JVOº D M§¼JÂJ; < U F UN¼J D S F Æ S UNP Ó T =@?WÔNÕzÖ�ÈX6 D »�<>= FmF M D F » S ; ¾J; ?JÀ�¼W= S ºm;>»�VJ<>= S MO; F º S ; ¾JVOº D M�¼JÂJ; < U F UN¼J D S F ; F2F ÂJUeÁ%?); ? à ÀNV S D  È@X6 DÁ%ÂJUN< D PsUOM D <WU@Æ�ºm D F à F º D P U@Æ�MO; F º S ; ¾JVOº D Ms¼JÂJ; < U F UN¼J D S F »�UN?lº�=@; ? F à D ºE=@?JU@ºm D S »�<>= FmFÁ%ÂJU F D UN?J< Ãsº�= FHG ; F ºmUs» S D =eº D =)À S UNVJ¼U@Æ.¼JÂJ; < U F UN¼J D S F =@?WM; ?lº D S »�UN?J? D »�º/ºm D Pë; ?lºmU= S ; ?JÀ§ÇL;>=�ºm D P D ºmÂJUOM F ��È0�0s Æ0�"�6=@?WM �S´��0�Xs Æ0�"��È × ; F º S ; ¾JVOº D M®¼JÂJ; < U F UN¼J D S F MO; â D SÆ S UNP ºm D »�<>= FmF ;>» =@<�UN? D F ; ?"?JU@º%ÂW=zÇL; ?JÀ�= F ÂW= S D M�º�=@¾J< D Á%ÂJ;>»�Â"»�UNVJ<>M§¾ D V F D MÆáU S D�½ Ä»�ÂW=@?JÀN; ?JÀ�ÆáU S GOF ÈOíb? F º D =NM§ºm D çÂW=zÇ D ºmU�? D ÀNU@ºm;>=eº D =@¾�UNVOº%ÆáU S GOF ÇL;>=sP D FmF =@À D F D ?WMO; ?JÀV F ; ?JÀ�ºm D P D ºmÂJUOM F �S´���È0� Ê }��<� =@?WM �S´���È�� Ê }��<� È
Û D < UeÁ Á D M D�à ? D =�É S UN< UNÀ�¼ S D MO;>» =eº D5È<��sS´�ÇX� ÇLÈL´��0� � }K�X�5w =@< < UeÁ%; ?JÀ"ºmUåM D S ; Ç Dºm D F D º�U@Æ D =eºm; ?JÀÞ¼JÂJ; < U F UN¼J D S F ÂW=zÇL; ?JÀÞ=@? D =eºm; ?JÀÊ? D ; ÀNÂL¾�UNV S Æ S UNP =åÀN; Ç D ? F º�=eº DU@Æ2ºm D PsUOM D < U@Æ/MO; F º S ; ¾JVOº D M®¼JÂJ; < U F UN¼J D S F È¢X6 D »�V SmS D ?lº F º�=eº D ; F »�UN? F ;>M D S D M�ºmU"¾ D; Ps¼J< ;>»�; ºjÈEX6 D ¼ S D MO;>» =eº D » =@?о D V F D MܺmUß»� D » G ºm D »�U SmS D »�ºm? D FmF U@Æ�ºm D ¼ S UN¼�U F D MF à F º D P Á%ÂJ;>»� F ÂJUNVJ<>MÞ?JU@º)=@< < UeÁ º[Á/U�? D ; ÀNÂL¾�UNV S F ºmU D =eº)=eº�ºm D F =@P D ºm; P D ÈiX6ÂLV Fºm D ¼ S D MO;>» =eº D F ÂJUNVJ<>M=@< Á6=zà F ÂJUN<>MsÆáU S ºm D�D Ps¼Oº[à F D º6UN?J< ÃNÈLX6ÂJ; F » =@?¾ D »� D » G D Ms¾LÃ= F VJ; º�=@¾J< D F º�=eº D F ¼W=N» D)¿ V D S Ã"Á%ÂJ;>»� D Çe=@< VW=eº D F ºm D ¼ S D MO;>» =eº D§È<��sS´�ÇX� ÇLÈL´��0� � }K�X�5wUeÇ D S D Ç D S à F º�=eº D =@?WM�»�UN< < D »�º F ºm D F º�=eº D F Á% D S D ; º�ÂJUN<>M F ÆáU S =8?JUN? Ä D Ps¼Oº[à F D ºjÈË PsU S D =@¾ F º S =N»�º$=@¼J¼ S Ul=N»�ÂåÁ/UNVJ<>Må¾ D »� D » G ; ?JÀ§ºm D Çe=@< ;>MO; º[îU@Æ/ºm D"C XQ�8ÆáU S P)VJ<>=d4o È<��sS´�ÇX� ÇLÈL´��0� � }K�X�5w Ï��NÒ È
52
DPhilosopher is_a PN
leftNb:left
.
giveLFork
return
f
f
f
.
.
giveRFork
return
f
f
f
.f := leftPh giveRFork
leftPh
return
.left
left
rightNb:right
return
.right
right
rightleft
rightPh
thinking
hungry
eatingright forkleft fork
. .
.
.
.
.
f := rightPh giveLFork
.
.
.
f1
f1
(f1, f2)
(f1, f2)
f2
f2
starteating
stopeating
left right
þ2ÿ � �v�J� ~ �l]%o�� _ {b{Ef g1qNp {�ab`[p �lkNa[]�q)^l�lp � fj{bfj^l�l]m`[{2g `[fjcA� �z_ d<�����
È<��sS´�ÇX�z ÇLÈL´��0� � }K�X�zwlt�¡ Æ x �F¢´�Ç�w�sNtz£Mµ0�0� ´���¤N{~£<£Mµ0��� ´K�U{F} �z¥ È~��sX¤<¤6{:u<xl{w�ÈX��È~��sNtvul{���{0t�s~}���È�ÇNtz£��X¤N{X£°È0��s�´�ÇX�<¤N{��X�<�|{�¡3��xC{XÈ�³X¦Xs0§Nt�¡3�3{��X�X�<w�È~xl{
s~}���È�Ç�tz£/�X¤N{~£���È0�0s�{���´����XsX¤6{F�<�<�|{��0�5xl{s~}���È�Ç�tF�0��{~£°È<��sS´�ÇX�X¤6{F�<�<�U{¨¡~�~xl{HÈ�³~¦<s<§6t�¡~�U{��<�X�Xw�Èzx0xl{4¡ Æ x|©
ª õʵE²�¸ ÙH·�øL¹[µE²�ø
íb?"ºm D = S ºm;>»�< D ILÁ D ÂW=zÇ D ¾ S ; D ìWçM D F » S ; ¾ D Mºm D ?JU@ºm; UN?"U@ÆiUN¾OZ D »�º Ä U S ; D ?lº D M§É D º S ;�? D º F= FmF UO»�;>=eº D MåºmU®ºm D ºmULUN</» =@< < D MßÉEÌ%º�=@< G =@?WM F UNP D U@Æ6ºm D ¼ S UN¾J< D P F =N» »�UNPs¼W=@?LÃL; ?JÀÀ D ? D S =eºm; ?JÀߺm D ; S F º�=eº D F ¼W=N» D F ÈEã D ÂW=zÇ D®D F ¼ D »�;>=@< < ÃYP D ?lºm; UN? D MYºm D ; ?OìWV D ?W» D U@ÆÁ/U S G ; ?JÀ"Á%; ºmÂß;>M D ?lºm; àWD S F U@Æ%MOÃL?W=@Ps;>» =@< < Ãå= S ; F ; ?JÀ�=@?WMÞMO; F =@¼J¼ D = S ; ?JÀ�? D º); ? F º�=@?W» D FVJ¼�UN?кm D F º�=eº D F ¼W=N» D�D�½ ¼J< U F ; UN?1ÈX6Á/UÞ¼�U FmF ; ¾J< D =@¼J¼ S Ul=N»� D F U@ÆxM D =@< ; ?JÀÞÁ%; ºmÂкm D;>M D ?lºm; àWD S F IO?W=@P D < à F UN¼JÂJ; F ºm;>» =eº D M?W=@Ps; ?JÀ S VJ< D F =@?WM§?W=@P D =@¾ F º S =N»�ºm; UN?1ILÂW=zÇ D ¾ D D ?M D F » S ; ¾ D M�=@?WM"»�UNPs¼W= S D M�È Ø UNP D ÆáV S ºm D S UN¼Oºm; Ps; Åj=eºm; UN? F U@Æ À D ? D S =eºm; ?JÀ F º�=eº D F ¼W=N» D FU@Æ Ñ$Ñ ÉEÌ F ÂW=zÇ D ¾ D D ?ÊP D ?lºm; UN? D M�I1= F Á D < <}È�X6 D P D ºmÂJUOM F ÆáU S UN¼Oºm; Ps; Å ; ?JÀ"Àl= S ¾W=@À D»�UN< < D »�ºm; UN?�=@?WM"ÆáU S »�UNPs¼JVOºm; ?JÀ D ?W=@¾J< D M"º S =@? F ; ºm; UN? F ; ?®=@?�; ?W» S D P D ?lº�=@<1Á6=zÃ"M D F ¼J; º Dºm D ; S ?JUN? Ä < UO» =@<i; ?OìWV D ?W» D » =@?å¾ D V F D Må?JU@ºxUN?J< Ã�Á% D ?ÊÀ D ? D S =eºm; ?JÀ F º�=eº D F ¼W=N» D F U@ÆÑ$Ñ ÉEÌ F IL¾JVOº�=@< F U�Á% D ? F ; P)VJ<>=eºm; ?JÀ F à F º D P F PsUOM D < D M"¾Là Ñ$Ñ ÉEÌ F È
53
ã D ÂW=zÇ D MO; F »�V FmF D M�=�P D ºmÂJUOMs=@< < UeÁ%; ?JÀ�ºmU$= FHG =@?W=@< à F ; F U S Ç D S ; à » =eºm; UN? ¿ V D F ºm; UN? FUeÇ D S Ñ$Ñ ÉEÌ F º�=eº D F ¼W=N» D F IJ= F Á D < <}ÈJX6ÂJ; F P D ºmÂJUOM�=zÇNUN;>M F S D Æ D SmS ; ?JÀ)ºmUsVJ?J; ?lº D S D F ºm; ?JÀ=@?WMsVJ? G ?JUeÁ%?�»�UN?W» S D º D ?W=@P D F U@Æ¢; ? F º�=@?W» D F =@?WMs» =@?s¾ D V F D MsÁ%; ºmÂJ; ?»�UNPsPsUN?�Á6=zà FU@Æ F ¼ D »�; ÆáÃL; ?JÀs¼ S UN¼ D S ºm; D F ºmUs¾ D$D Çe=@< VW=eº D M�ÈX6 D ?JU@ºm; UN? F ; ?W»�< VWM D M�; ?$ºm D = S ºm;>»�< D = S D F VJ¼J¼�U F D MxºmU�¾ DED�½ ¼J< UN; º D M$Á%; ºmÂJ; ?�ÆáU S P�=@<=@?W=@< à F ; F =@?WMåÇ D S ; à » =eºm; UN?ÊUN? F VJ; º�=@¾J< à S D MOVW» D M Ñ$Ñ ÉEÌ F º�=eº D F ¼W=N» D F Á%ÂJ;>»�ÂÞ; F UN? DU@Æ�ºm D ÀNUl=@< F U@Æ�UNV S ÆáVOºmV S D S D F D = S »�Â1È Ë F ÆáU SsS D MOVW»�; ?JÀ Ñ$Ñ ÉEÌ Fv« F º�=eº D F ¼W=N» D F IiÁ D; ?lº D ?WMsºmU�=NMJ=@¼Oº2ºm D ºm D U S Ã�U@Æ1¼W= S ºm;>=@<WU S M D SES D MOVW»�ºm; UN? F ÆáU S ºm D MOUNP�=@; ?U@Æ Ñ$Ñ ÉEÌ F¾ D » =@V F D ºm D S D ; F ¿ VJ; º D =$< U@º/U@Æ.»�UN?W»�V SmS D ?W»�Ã�; ?PsUOM D < F ¾W= F D MsUN?�ºm D P�ÈLã D ÆáV S ºm D S; ?lº D ?WM§ºmUMOU�PsU S D S D F D = S »�ÂUN?�V F ; ?JÀ Ñ$Ñ ÉEÌ F ÆáU S PsUOM D < < ; ?JÀMO; F º S ; ¾JVOº D M F à F º D P F I=@?WM D F ¼ D »�;>=@< < úm D F U@Æ�º[Á6= S D UN? D F È5.�¬�¡(0< 7â"'�ÿ(à�£P'�¡S+ ï8X6ÂJ; F Á/U S G Á6= F MOUN? D Á%; ºmÂJ; ?κm D S D F D = S »�Â5; ?lº D ?lºm; UN?BÌ�UWÈC/Ù" � T Â� reÔNÕ �L � Â� ����� ý Â�Ä �Xæ D F D = S »�Â�; ?åíb?OÆáU S P�=eºm; UN?å=@?WM C UN?lº S UN< Ø Ã F º D P F � =@?WM; ºsÁ6= F =@< F U F VJ¼J¼�U S º D MܾLÃÞºm D Ð S =@?lº Ë À D ?W»�ÃßU@Æ�ºm D®C Å D »�Âzæ D ¼JVJ¾J< ;>»"VJ?WM D S ºm D»�UN?lº S =N»�º ý �  r����<r ý � ý Ý1�m:�UOM D < < ; ?JÀWI1K D S ; ÆáÃL; ?JÀWI.=@?WMÞÉ S U@ºmU@º[ÃL¼J; ?JÀ × ; F º S ; ¾JVOº D M Ë ¼ ļJ< ;>» =eºm; UN? F Ú F ; ?JÀ�É D º S ;1Ì D º F � È
×Yò1ù�ò1´Jò.²�¸¢ò.ø� hi\%¯�®"��¯°�G±��ihi�lp fj� _@uhE�.\6kNa[�l]�p � � ]ma�u|±��i¯N`H_ dlo�]�{boH�lp dlp {�u._ dLqÊnO�C®6_jqlql_jqJ� � ne|Nc��Ofj� p o
�E]�_ oH�L_ �lp � p a}|)±E`H_ ^l�xg>f `Ehifj� fjkN`[]�q�¡¢]mab`[pL¥/]ma[{��N²5³0´¨µv¶�´�·`¸-¹�º�»3¼lµv½W¾<¿K·�´�¶WÀX¹F¸Á´�ÂX¹�´Hu�[¯ �@� Ã����@��Äeu��°����¯e�
� �hU��Å"��¯°��«§� �hi] �{b�j_@u0Å��0�z_ dlfjkJ�{b]��OuL_ dLq�~/�0Å.f���dL_�`��.¡1¥EaH_ � �x� � hifjc$^lkNa[]m`[p � ]�q�~�fefj�Jg>f `¤ �@��]�omab� ¤ `[p ]�dea[]�q�¡¢]mab`[p1¥/]ma[{%«�f@qN]�� � p dltN�IÆ}d§¯i�W¡1p oH�l� ]m`�_ dLq����W«�f `[]�dlf ��\%ÇÈ _ � u]�qNp a[f `[{�u5ÉU¶¨µ°¹[ÊUµ/Ë�ÌgÍ~Î�Ï"¼�ÐWÀ�²�Ñ ÒKÓ�Ê uOyzfj���1�°Ã�Ã�Ã)f gNÔ�´¨¹F·`¿K¶�´%Õ�µv·�´�Ö%¸×Â�¼lµv½W¾<¿K·�´�¶ÀX¹F¸Á´�ÂX¹�´Hu<Ø�_ {/¡�_ � c�_ {EqN]�±E`H_ dh _ dL_�`[p _@uWn@^L_ p dWuJ�°����¯e�Wn@^N`[p dltj]m`b�ÁÅ.]m`[� _ tN�
� ®/fj� ��¯°� ±�� �N�<®/fj� � c�_ dldW�.~ �l]�«�f@qN]���hi�l]�oH�z]m`/n@^lp dW�6Ù/ÌlÌlÌ�²0¶¨ºvÂ0ÖFº�¹F·`¸-µvÂ0Ö%µvÂ�ÀXµ/Ë�·`Ú|ºv¶�´ÌUÂKÛv¸×Â~´�´�¶�¸×ÂKÛ uO�và £ Äj¦HuJ«s_�|§�°����¯e�� �z_ d<���[�ÜÅ����z_ dlfjkJ�{b]��O�UÝ#µ°Þ�´F»×» ¸×ÂKÛ4ÏNß×à[´¨¹F·`Ö�ßFáIÉ�´�·`¶�¸3Õ�´�·`Ö[�i¡1�l\8a[�l]�{bp {�uL¯L_ o�kl� a}|�f g�r1� ]�om�
ab`[p o�_ ��r1dltjp dl]�]m`[p dlt�_ dLqshifjc$^lkNa[]m`/n@o�p ]�dlo�]juL~ wév.`[dlfNuOh � ]�oH�s�E]�^lkl�l� p ojuW�°�����@�� �j]�d<�vâv�äãx�6�j]�dl{b]�dW�å¼lµ�» µv¿K¶�´¨Þ�É�´�·`¶�¸IÕ�´�·`Ö�æ�ç�ºvÖ�¸-¹è¼lµvÂX¹�´Á¾<·`Ö�é%ÐNÂXº�» ávÖ�¸×ÖYÝ:´�·×³�µ°ÞvÖ:ºvÂXÞÉU¶¨º�¹F·`¸-¹�º�»3ÍzÖ�´�éUê0µ�» ÊKë�æ�ÐNÂXº�» ávÖ�¸×ÖCÝ:´�·×³�µ°ÞvÖ[�@r � ~2hn�«�fjdlfjt `H_ ^l�l{¢fjd�~ �l]�f `[]ma[p o�_ �hifjc$^lkNa[]m`En@o�p ]�dlo�]j�Jn@^N`[p dltj]m`b�ÁÅ.]m`[� _ tNuW�°���vâN�
� ��Å"���[� Å��5�z_ dlfjkJ�{b]��"_ dLq"~/�5Å.f���dL_�`��s«�f@qN]�� � p dlt_s¯¢� ]m Np �l� ])«s_ d@kNg�_ oma[kN`[p dltne|N{�a[]�cs�Æ}d:�N� �nea[]mg�_ dWu�]�qNp a[f `�u3ÉU¶¨µ°¹�´�´¨Þv¸×ÂKÛvÖGµ/Ë%ÝìÏUÀ�Ù�À)Ñ Ò�í�é)ê0µ�» Êlëzu�^L_ tj]�{$�°��Ä��N�vî�î@u.n@yO�®/fj{�aXÇ|NdWuLh � ]�oH�s�E]�^lkl�l� p ojuL«s_�|§�°�����@�J« � ��ï ¤ {�ab`H_�yj_@�
� ¡¢]�� �j�[� \��2¡¢]�� ]�qJ�ªhifjc��lp dlp dltå¡�_�`ba[p _ � ¤ `HqN]m`s�E]�qNkloma[p fjdl{�¬2p a[� ¤ dN�áa[�l]m�á¨l|ß«�f@qN]�� �hi�l]�oH�@p dltN�3ðKµv¿K¶�ÂXº�»Xµ/ËUñ5µv¶�½'º�»�Ý:´�·×³�µ°ÞvÖN¸×ÂGÀ0ávÖ�·�´�½%Ö6òI´�Ö�¸ ÛvÂluK� £ ��¦H� Ã����@�vâNuO�°���j�@�
� nNvU�vâv� hE�2n@p �O]m`ba[p dN�}vi� _ dloj��hifefj^O]m`H_�a[p yz]§¥/]ma[{��óÆ}dÞ���UÅi_ � ]maba[]jui]�qNp a[f `�u�ÉU¶¨µ°¹�´�´¨Þv¸×ÂKÛvÖµ/Ë'Ù[¼�ÐW²zÉ|ÕYÑ Ò�ôNu�yzfj� klc$]G�@�[Äf g�Ô�´¨¹F·`¿K¶�´4Õ�µv·�´�ÖG¸×Âq¼lµv½W¾<¿K·�´�¶4ÀX¹F¸Á´�ÂX¹�´Hu.^L_ tj]�{â�¯e�H��â���î@uW�J_�`H_ tjf � _@uWn@^L_ p dWu<�jkldl]��°���vâN�Wn@^N`[p dltj]m`b�ÁÅ.]m`[� _ tN�� Åi_ � ���[� � ��Åi_ � c�_�`[p���~ �l]6neaH_�a[]/r� N^l� fj{bp fjd�¡�`[fj�l� ]�cs�zÆ}dgõY�e�E]�p {bp t�_ dLqG±��e�Ef � ]�d@�O]m`[tNu]�qNp a[f `[{�u�Ô�´¨¹F·`¿K¶�´�Ö�µvÂ�É�´�·`¶�¸IÕ�´�·`ÖbÙ�æ�ç�ºvÖ�¸-¹�Ý#µ°Þ�´F» Ö[uyzfj� klc$]���â��@�"f g'Ô�´¨¹F·`¿K¶�´Õ�µv·�´�Ö"¸×Âì¼lµv½W¾<¿K·�´�¶�ÀX¹F¸Á´�ÂX¹�´HuL^L_ tj]�{�âe�v����Äj�v�@�Wn@^N`[p dltj]m`b�ÁÅ.]m`[� _ tNuW�°�����@�
� Å.f��¨î�î[� ~/�3Å.f���dL_�`��èÀ0·Áºv·�´4À�¾�º�¹�´�Ö4µ/Ë�ÏNß×à[´¨¹F·-ö�ÏU¶�¸Á´�Â0·�´¨Þ�É�´�·`¶�¸�Õ�´�·`Ö[��¡1�l\Îa[�l]�{bp {�u1¯L_ om�kl� a}|®f g%r1� ]�omab`[p o�_ �6r1dltjp dl]�]m`[p dlt�_ dLqÞhifjc$^lkNa[]m`)n@o�p ]�dlo�]ju v.`[dlf"w/dlp yz]m`[{bp a}|®f g~�]�oH�ldlfj� fjt |euOh � ]�oH�s�E]�^lkl�l� p oju@a[fx�O] © dlp {b�l]�q�p d��vî�î�î@�
54
The OCoN Approach for Object-OrientedDistributed Software Systems Modeling
Holger Giese and Guido Wirtz
Institut fur Informatik, Westfalische Wilhelms-Universitat MunsterEinsteinstraße 62, 48149 Munster, GERMANY{gieseh,guidow}@math.uni-muenster.de
Abstract. The problems of todays software engineering for complex dis-tributed software systems with control as well as data processing aspectsare manifold. Besides the general problem of software complexity weadditionally have to deal with the problems of concurrency and distribu-tion. A set of well evolved formalisms especially w.r.t. concurrency exists,while their integration into the common software engineering frameworkis still missing and related attempts have often not gained the intendedacceptance. But ever increasing system complexity as well as a fast grow-ing market for distributed software effectuate a shift towards high levelbehavior modeling. The presented OCoN approach does provide a highlevel behavior modeling as extension to the UML de-facto standard forobject-oriented modeling. It is an approach to integrate an adjusted Petrinet formalism with the software engineering world.
1 Introduction
While place/transition nets [9] are accepted as one standard formalism of soft-ware engineering (cf. [42]) is the situation quite different for high-level Petrinets (HLPN ). With the development of object-oriented analysis and design [44,15] the shift towards a more high-level design view further boosts, but otherbehavioral formalisms like statecharts [28] win recognition. The high-level Petrinet formalisms play no prominent role for object-oriented behavior modeling inpractice.
There are several rational as well as historical reasons for this situation. APetri net is a conceptional extension of an automaton and thus it is inherentlymore complex than state machines. The adequate handling of concurrency isstill a complex problem and often solutions applying database technology thatprovides parallel access transparency to avoid the related problems is more ap-propriate. Thus, the development of complex software system engineering incor-porating sophisticated concurrency aspects had been less influential and thussuitable concepts for object-oriented concurrent behavior modeling are not themain stream. Nowadays development of object-oriented methods and notationsas well as the UML [40] neglect systems with concurrency.
55
It also has been detected that the expressiveness of the basic Petri net for-malism is not sufficient to handle real modeling problems and thus several high-level extensions have been suggested. But as common for formal methods andsoftware engineering practice, a trade off between expressiveness and efficienttestable system properties exists.
A compositional language and building modular software systems has beenidentified as essential for successful designing. But the classical Petri net for-malism as well as first approaches towards higher-level concepts [20,31] fail toprovide it. Still most extensions put their emphasis on preserving an analyz-able model while in practice a clear semantics as well as support for embeddingbased on abstractions like interfaces are more important. Meyer [37, p. 979]summarizes the common critiques as follows:
Petri nets, in particular, rely on graphical descriptions of the transitions.Although intuitive for simple hardware devices, such techniques quicklyyield a combinatorial explosion in the number of states and transitions,and make it hard to work hierarchically (specifying subsystems indepen-dently, then recursively embedding their specifications in those of biggersystems). So they do not seem applicable to large, evolutionary softwaresystems.
In general is behavior modeling neglected in practice while several newertrend like the shift towards software architecture [46] may change this. Nowa-days, software evolves from isolated solutions for business or industry appli-cations towards distributed environments. It will further interlink informationsystem structures which are still isolated today and become persuasive. The soft-ware will often take responsibility for considerable coordination tasks and theever increasing demand to improve business processes and process centered tech-nologies like workflow [45] indicates that this trend will make system behaviorone essential point.
Formal methods and from our point of view especially Petri nets can gainmore acceptance from the resulting change of demands. This is independent fromthe fact whether this trend leads to a common software engineering practicewhere complete analyzable system models will become the regular case. Thetrend towards higher-level abstraction to handle the ever increasing complexityhas led to the success of visual notations in software engineering for structuremodeling. For behavior modeling to achieve more acceptance also a notationwhich is scalable as well as has an intuitive semantics is needed. The notationhas to cover concurrency as a specific aspect, design has to deal with in thefuture. Petri nets conceptionally provide ingredients for all these aspects.
The object coordination net (OCoN) approach [57,24, 27] tries to overcomethe described problems with high-level Petri net formalisms. It has its originand roots in an attempt to achieve an equally weighted compromise between therequirements of concurrency modeling (due to the usage of Petri nets), object-orientation for structure and behavior and the limits and demands a suitablevisual formalism implies.
56
In the paper the stepwise development of the OCoN approach foundationsis presented. In section 2 the basic notion of contract and its formalization interms of protocol nets is studied. Then, a flexible notion of port-passing netsnamed coordination nets (CoN) is introduced in section 3. It is used to definethe OCoN notation in section 4 on top of them in combination with the UML.Visual language aspects are discussed in section 5 and the tight integration withthe UML is studied in section 6 by presenting a schematic example. We finallycompare the approach with the most prominent proposed solutions for object-oriented nets in section 7 and discuss other related work. We conclude the articlewith some remarks on planned further work and the project status.
2 Protocol Nets and Contracts
When behavioral modeling should also provide some degree of modularity, ab-straction and data hiding [41] are mandatory. While several extensions to theclassical interface notion to achieve a more suitable external specification havebeen suggested, is the question of behavior w.r.t. subtyping and inheritance stillan area of research. The phenomena of non uniform service availability for aclass has to be considered for interfaces to provide the needed encapsulationand separation. For the object-oriented design statecharts [28] for OMT [44] orpath expressions for Fusion[15] have been proposed. Both are used to specify theexternal available operations of a class depending on its history.
A general notion of a contract covering the classical as well as additionalaspects is presented in [6]: The cases of syntactical interfaces, behavior contracts,synchronization effects and quality of service are distinguished. While syntacticalinterfaces do not provide enough information to exclude semantical misusage,can behavior contracts not be managed in an efficient way automatically. Qualityof service considerations are often run-time dependent and thus can only bespecified when instantiating a system on a specific platform. In contrast doesthe synchronization aspect represent an aspect that can be considered alreadyduring the design and can be expressed using Petri nets.
The notion of substitutability [55] can be used to characterize behavior subtyp-ing [1] needed to ensure the secure usage of contracts w.r.t. behavior in contrastto interface subtyping as supported by most object-oriented languages. Whenmultiple concurrent clients are possible we also have to ensure view consistency[35] for a subtype.
Protocol Nets
The identified demand of covering synchronization aspects within contracts ishandled in the OCoN approach by supporting the specification of protocols with a(nearly) state machine like labeled place/transition net. In order to distinguishif a behavior has to occur (obligation) or may be used as needed we have tofurther distinguish between fair transitions and quiescent (grey) ones that doguarantee some sort of progress or not (cf. [43]).
57
m
≡m m
m
≡m
m2
m1≡m
m
mm
≡m
Fig. 1. The set of protocol macros
In figure 1 the different kind of operations which are supported by an OCoNprotocol net are defined. The protocols are specified from the perspective of theclient and thus a grey behavior indicates free choice while a normal transition hasto occur. The normal labels indicate a usual or one way request (m) while a labelm does correspond to a reply or event. Only the modification and synchronizationw.r.t. the protocol state itself is described in a protocol net and thus edges forparameter or reply values do not occur. From left to right and top to the bottomwe have the usual operation request containing of a request as well as a reply,an operation request with parallel reply, a request with alternative replies (e.g.,named replies or exceptions can be covered) and an one way call.
Fig. 2. A File contract described with a protocol net
In practice, for example, a file handle protocol will imply a certain usage,e.g., a read request will not succeed if not an open request has succeeded beforeor if the end of file is already reached. This example protocol of a File can bedescribed using the defined macros of figure 1. An appropriate protocol for afile handle with operations open, read and close is presented in figure 2. Theinitial state where only an open request is possible is named [closed]. One possiblereply is open1 as an acknowledgment for a successful opening which results instate [opened]. If the request fails, an exception opene is replied and the protocolremains in state [closed]. A file handle in state [opened] can further be used to
58
read data. A successful read request is signaled by reply read1 whereas thereached end of file results in read2 and a state change to [eof]. If we are eitherin state [opened] or [eof] the close request can be used to close the file handleand reach the state [closed] again.
The contracts are the essential elements to separate the classes as well asallow further independent subsystem evolution. Subtyping and contract inher-itance are suitable concepts to support such efforts. For the OCoN approach acontract subtyping notion has been developed in [23] that provides the neededsubstitutability as well as view consistency .
While the described protocol nets are capable to describe the behavior relatedto a single connection in form of a protocol, we have to provide a formalism thatis also capable of expressing multiple connections in parallel.
3 Coordination Nets
For colored Petri nets the extension to hierarchical colored Petri nets [32] and thecomposition mechanisms substitution of transitions or places, invocation transi-tions and fusion sets for transitions or places have been proposed [30]. All thesemechanisms, excluding the invocation, are very Petri net specific and do notrely on the natural notion of information exchange directly, but encode it into anet specific view. Consider for example a place fusion which might be a usefulabstraction in a assembly line like structure, but it does not correspond to acommon software interface like a procedure or stream. Nets with procedure callsas considered in [33] result in considerable analysis problems and thus are usu-ally provided as add-on and not as basic concept; see,e.g., [19] for an extensionof B(PN)2 [5] with procedures. The transition invocation can be considered asthe procedural abstraction common in programming languages and thus pro-vides the needed general abstraction concept. To model object orientation anddynamically evolving structures we even have to add references and port passingcapabilities (cf. π-calculus [38]).
The coordination nets (CoN) formalism has been invented in [21] to providean abstraction for the specification of the OCoN semantics. We base the formal-ization on the forthcoming ISO high-level Petri net standard [16], which providesa non hierarchical high-level Petri net model. Port passing capabilities to modelinstance and system behavior even for dynamic evolving structures are added.For the CoN formalism, the level 2 conformance with the HLPN standard hasbeen demonstrated in [21]. In extension to high-level Petri nets as defined in thestandard a concept to provide modularity is needed. To achieve this, a systemis built based on a set of coordination net graphs which are allowed to interact.The formalism should allow to model multiple instances of one object type, eachone providing a set of interfaces with dynamically changing external protocolstate. Several net instances may be used to implement the object behavior to-gether and thus a mechanism like place sharing for them is necessary to modelthe object environment shared by all net instances of an object instance.
59
We do not provide a builtin object notion with the coordination nets. Instead,we provide an interface based separation using typed ports which consist of aninterface and a protocol net restricting the message occurrences. Our final netdialect object coordination nets will provide a suitable object and class notionbased on CoNs.
net instances
net type 1
BUS
receivereceive
”real place”
create net
net type 2
send
send
Fig. 3. Basic structure of a coordination net system
The standard is extended by suitable mechanisms for communication, placesharing as well as dynamic net and port creation. In figure 3, the basic structureof a coordination net system is shown. There do exist multiple instances of thesame net type possibly sharing places between a net instance and its child (”realplace arrow connection”). The nets may communicate using a communicationinfrastructure. The basic idea for communication is to introduce ports ζ, η,. . . representing associated or exported interfaces (objects) as pairs of connectedcommunication endpoints which are represented by port token (see figure 4, 5 forport usage). These ports can be used to receive a message (?) using the followingannotation for a transition:
η = ζ?〈〈op(a1, . . . , an)〉〉 η = ζ!s〈〈op(. . .)〉〉 η = ζ!a〈〈op(. . .)〉〉,
where η is the resulting port and 〈〈〉〉 denotes a given marshaling function;op(a1, . . . , an) stands for an operation call with operation name op and inputparameters a1, . . . , an. There may be several distinct return vectors for a calland thus we use opi as operation name for the return alternative i to an op-eration op and annotate opi(r1, . . . , rm) for a reply with return vector r1, . . . ,rm. A corresponding synchronous send can be specified using a port ζ and thesynchronous send operator !s. Analogous an asynchronous send can be specifiedusing !a We distinguish provide ports ρ, %, . . . for exported and usage ports φ,
60
ϕ, . . . for associated interfaces. A provide port can receive operation calls op
and sends replies opi whereas an usage port can be used to send requests op
and receive replies opi. Asynchronous and synchronous interaction are distin-guished, because the synchronous interaction provides more sophisticated waysto interact. The asynchronous communication is in contrast more efficient andreduces the coupling between two systems. When useful we do not further spec-ify if synchronous or asynchronous interaction is wanted and the more generalsend operation (!) is used.
To create ports of type P or net instances for a declared net type N alsocorresponding annotation expressions are supported. A net creation expression(φ= @N) binds to φ an usage port corresponding to a special initial providedstandard port (std) each new net instance contains. This initial connectionallows to establish more connections by using these port connections to publishother ones. After a port creation ((ρ,φ) = @P ) a pair of new unique connectedusage and provide port instances is bound to φ and ρ. This way the dynamiccreation of active net instances as basic formalism to model instances as well asmultiple active threads of an instance is provided.
12
3 4
φ=@N
〈a1, a2, φ〉a1
a2
%=ρ?〈〈m(. . .)〉〉σ=%!a〈〈m(. . .)〉〉
%
σ
%
ρ
Fig. 4. A coordination net graph example
By allowing the described annotations in net declarations, a dynamicallychanging set of net instances interacting via port instances can be specified. Toachieve a better visual representation we draw all transitions annotated withreceive terms and imported places with a shadow as shown in figure 4. Thereis a request received in transition 1 which is replied with a send expressionin transition 2. Transition 3 creates a new net of type N and propagates theresulting usage port φ together with its other pre-conditions a1 and a2 in formof a vector to a place. Transition 4 may consume it then. Hence, the parts which asingle coordination net graph distinguishes from a high-level Petri net as definedin the high-level Petri net standard are the additional annotations. They addmessage send, message receive, port creation and net creation to a transition asshown in figure 4.
The single net graphs are interacting via send and receive annotations whichare using the already introduced ports as addresses. The resulting system consists
61
std
φ
create net”real place”
φ
ρφ
send
%=ρ?〈〈m()〉〉
ϕ=φ!s〈〈m()〉〉
φ=@N
(ρ,φ)=@P
ρ
Nreceive
Fig. 5. An example for different ways nets may interact
of a number of net graph instances connected via ports and a marking for allof them, as presented in figure 5. The left two nets interact via correspondingusage/provide ports and a synchronized send and receive transition pair. Thesynchronous send ensures, that the message is directly received. In the middle anet creation is presented and the resulting port pair is visualized. The importedplace of the created Net N is linked to the corresponding local place of thecreating net and the standard port (std) of the new net is connected to theresulting port φ of the create expression. A port creation is demonstrated in theright net. This technique is used to describe instance or subsystem wide sharingof resources and is realized with some sort of lexical scoping .
ε ε
%=ρ?〈〈m〉〉
ρ
φ ϕ
ϕ=φ!s〈〈m〉〉
φ
ϕ=φ!a〈〈m〉〉
φ
ϕϕφ
ρ
%=ρ?〈〈m〉〉
Fig. 6. Asynchronous and synchronous interaction
We have decided to provide synchronous as well as asynchronous behavior forcoordination nets to achieve a greater flexibility. The synchronous interaction (cf.synchronous channels [14]) is useful, because it provides a higher-level abstrac-tion to describe explicit synchronization where needed while the asynchronousinteraction can be used to combine systems with FIFO queues (cf. FIFO Petri
62
nets as a medium [48]). An example visualization of an asynchronous and syn-chronous interaction is shown in figure 6. In the left case of an asynchronousinteraction the FIFO queue as medium does decouple both transitions while inthe right case of synchronous interaction both transitions are firing atomicallytogether.
A suitable typing has to carefully distinguish usual types (literals) that de-scribe a value domain and represent passive data and ports which are handles oridentifiers that allow to request certain activities or attributes. For ports a typingthat supports subtype polymorphism is essential. Ports represent connections toother entities in a fashion that should ensure abstraction and autonomy whichare the essential characteristics of object-based systems (see Wegner [54]). Thebasic idea for port typing is to associate an interface (signature) and a behaviorto every port connection. Thus the object life cycle and the possible interactionwith an object becomes a part of the usage contract.
I[s1]
ϕϕ
I[s0]I[s2]
χ
χ=ϕ?〈〈m(r1)〉〉ϕ=φ!〈〈m(a1, a2)〉〉int
r1
φI
int
int
a1
a2
Fig. 7. The usage side of a remote procedure call
A protocol conform usage is presented in figure 7 where the port φ is trans-formed to ϕ by sending m and later transformed to χ when receiving the reply m.The port type and state is annotated using the shortcut I[si], where I denotesthe interface and protocol and si the specific protocol state.
4 Object Coordination Nets
The object coordination nets (OCoNs) combine the strength of Petri nets withthe structural modeling techniques of the UML, the de-facto standard for object-oriented modeling. By combining both techniques in an orthogonal way, the Petrinet mechanisms can be used to express coordination, concurrency and partialstates while the structure is described in terms of objects, classes and associa-tions. The Petri net concepts lack a suitable structural modeling concept andthus an orthogonal combination with the object-oriented structural model isneeded and possible. OCoNs are build on top of the CoN formalism to providea more high-level as well as more restricted formalism. Structural aspects arerealized with UML mechanisms and the usage of nets is restricted to modelbehavior. As demonstrated in [25], the OCoN formalism results in a more accu-rate representation of the structural model within the formalism compared withstatecharts.
63
Fig. 8. The structural concept for a class or subsystem
The CoN formalism is used to describe two specific net forms while the pro-tocol nets are used to type contracts. Figure 8 presents the relation betweenthe different nets. The protocol nets are used to describe the guaranteed or as-sumed behavior of contracts. So called service nets (SN) describe behavior fora specific task right like a method with its own thread of control in a program-ming language. An instance wide unique resource allocation net (RAN) is usedto describe the overall instance activities like request acceptance as well as theallocation of needed resources for the request processing including the creationof related service nets for a request.
(c)
action
(a) (b)
Fig. 9. Several basic elements of an OCoN
An overview about the elements of an OCoN is presented in figure 9. Theresource and event pool elements are represented by hexagons and cycles. Wedistinguish between them, to describe the more transient character of parame-ters, the control flow and temporary events by using event pools as well as themore static resource character of associations and local variables represented byresource pools. Resources are required as the carriers of activities to performthe processing of events during the computation and thus events describe thecontrol flow of a net (see figure 9 (a) and (b)). Based on the distinction between
64
resources and objects produced and consumed through the flow of data and con-trol, the metaphor of resources which is crucial in distributed systems can beused to make resource handling explicit. The usage and status of resources canbe specified in detail. A single resource may be represented by more than oneresource pool if the different pools stand for the same resource but different ex-ternal states. Using a set of useful actions to abstraction from concrete and errorprone explicit port handling, the behavior can be described in terms of requestsand simple contract usages. No explicit send and receive have to be consideredany more and instead the more high-level interactions like call or one way callare provided directly. The typing of the contracts using interfaces and protocolnets does further enforce a disciplined usage. Also the creation of instances aswell as subnets is covered using extra forms of actions.
abstract action net
action
⇒
Fig. 10. Embedding of an action with multiple output alternatives
To specify the semantics of OCoN constructs we will use reentrant subnets ina macro like way and a special kind of transition refinements (see [8]). Valette[50] refines transitions by subnets called block with one initial and one final tran-sition. The block is protected from multiple occurrences of the initial transitionbefore the final transition occurs by assuming that the refined transition is not2-enabled for any reachable marking. Thus the net must not be reentrant . Suzukiand Murata [49] generalize this technique and consider the case, where the re-fined transition is restricted to be at most k-enabled. Work which considers alsodistributed input and output has been done by Vogler [53]. He studies a refine-ment notion depending on the environment of the transition. He demonstratesthat only non distributed input is feasible but distributed output can be usedwhen environment independent refinement is considered. In contrast to all theseconsiderations we need a really reentrant (see [13]) construction, otherwise theparallel occurrence of actions will be limited, but for the presented refinementsthis condition is obviously fulfilled due to their restriction to at most a singletoken per usage. The general scheme used is presented in figure 10. This way thecall with contract blocking character, the call with parallel reply or a one waycall can be specified.
In figure 11 the corresponding CoN behavior for a regular call with alternativereplies is specified. It is a generalization of the simple call described earlierin figure 7. The pre-condition edge denotes the necessary port and a requestm(a1, . . . , an) is send using the usage port φ. For each possible reply immediately
65
a receive is offered which may handle different return parameters as well as thedifferent transitions can be used to specify different side effects in the embeddingnet.
χ
χ=ϕ?〈〈m1(r1)〉〉
ϕ
ϕ
ϕ
χ
≡m
χ=ϕ?〈〈mn(rn)〉〉
ϕ=φ!〈〈m(a1, . . . , an)〉〉
φ
Fig. 11. The macro refinement for a regular call
As reverse representation exists for every contract usage port also a provideport and the owning instance has to provide the described services accordinglyto the protocol net. This has to be done using a so called call forward actionas specified in figure 12. Initially a request is received and the set of resourcesexclusivly needed for the request processing is consumed. As post-condition thereceived parameters as well as the allocated resource are forwarded to a newcreated net. Also the port for receiving the result from the new instantiated netas well as the port to send the reply to the requesting party are stored as apair locally. The created service net will initially receive the forwarded request.When it terminates it will send the reply and the temporary used resources back.The reply will be forwarded while the resources are put back to their originalpools. A call action may occur in a service or resource allocation net while acall forward action for the request acceptance is restricted to occur only in aresource allocation net.
e1
en en
e1
φ=@N〈%,ϕ〉 〈%,ϕ〉
χ=ϕ?〈〈m(r,e)〉〉
σ=%!a〈〈m(r)〉〉
%=ρ?〈〈m(a)〉〉
ϕ=φ!a〈〈m(a, e)〉〉
ρ
≡e1
en
e1
en
m, N
Fig. 12. The call forward action and request acceptance
When considering the definitions for a call action of figure 11 directly on theOCoN net level, we can see that a labeled action does essentially fire two timesduring the processing of a request. One time when the request is started andonce when it terminates. This step semantic is further described in figure 13.The two steps correspond very well to the input and output parts of the callaction. While the direct correspondence with a classical Petri net transition is
66
Fig. 13. The two times an action can fire
abandoned, the integrity of an operation request including request sending andreply receiving is better preserved this way.
By additionally providing a notion of inheritance, the OCoN language can beconsidered to fulfill the requirements for an object-oriented language (cf. [54]).The notion of inheritance for concurrent object oriented languages is a criticaldesign aspect. As noted already in [1], inheritance can be employed to reuse thesequential methods, but inheriting the instance wide synchronization seems tobe not practical. Thus in the current used inheritance notion for OCoN classes,a subclass does inherit all structural properties as well as the associated servicenets of its superclasses, while the resourc allocation net is not inherited. Due tothe syntactical inheritance it is ensured that each subclass contains always allresources a supertype service net may demand. The overall resource allocationof a derived class has to be rewritten and reuse is currently not supported forresource allocation nets.
We have to emphasize that in contrast to the contract subtyping and in-heritence, implementation inheritance is for the intended usage of OCoNs notthat relevant. The external visible contract or interface hierarchy should be ingeneral better separated from implementation reuse strategies applying inheri-tance, otherwise later when the subsystems evolve independently serious designproblems will result.
5 Visual Language
For place/transition nets the popular token game provides a suitable visual rep-resentation as well as intuitive semantics. We thus have designed the OCoN for-malism to provide a set of higher-level action types that can be understood w.r.t.the local effects as a token game. E.g., the enabling does not depend on textualguards. To model alternative behavior in a graphical rather than textual man-ner we use methods or external operations with alternative replies (see figure 11)that indicate the relevant different cases. This way a useful additional abstrac-tion for predicates is introduced and textual guards transferring the semanticsfrom the transitions to the annotations can be avoided. This is in contrast tomost HLPN approaches which make heavy use of textual annotations and arethus not such suitable visual formalisms.
In figure 14 the visual integration of contracts described by protocol nets andthe resource allocation as well as service nets is presented. Associations repre-
67
ContractR1<<contract>>
op1()op2()op3()
[R1]
op1
res1_
ContractImpl::op1
op2
op1
[S2][S1]
Contract1<<contract>>
[R2]
...
res1_
op2
ContractR2
res1_
op4
self
...
self
res2_
...
res2_
.........
#op4()
+op1()
+op3()+op2()
resource allocation net
signatures
<<implementation>>
Contract2
signatures
ContractR2<<contract>>
ContractImpl
protocol net
<<service>>
[S1] [S2]
<<service>>ContractImpl::op2
Fig. 14. Visual seamless embedding of contracts via typed resource pools
sented by resource pools containing related contracts can be used in conformancewith the specified protocol and thus their usage corresponds to a graphical em-bedding. This seamless visual embedding [26] is the reason for our design decisionto restrict protocol nets to state machines. Then the multiple places of a Petrinet allow to embed the contracts using resource pools representing the differentcontract states. The object life-cycle can also be modeled with full Petri nets,e.g., with subtyping based on branching-bisimulation and abstraction [51], butthen the intended visual embedding as well as a more Petri net independentcontract notion are excluded. In figure 9 (c) the related signature abstractionrelating an action to a servie net has been demonstrated.
6 Integration into the UML
In the OCoN approach the HLPN standard [16] and the UML [40] have beencombined. But in practice usually perfect orthogonality is not achieved. The UMLspecification does still contain several inconsistencies, but there are currentlyattempts like the pUML initiative [18] that try to improve the situation and thususing it is still more appropriate than chosing a proprietary solution. For theincluded behavioral description techniques we even identified several weaknesses[22]. For the achieved OCoN integration it has been demonstrated in [25] thatseveral limitations and problems related to behavior modeling with the UMLnotations can be avoided.
68
HLPN
CoN UML
OCoN
OMGmeta-model
Fig. 15. The layers to build the OCoN semantics
In figure 15 the abstraction layers of the semantic foundations of the OCoNapproach are visualized. We decided to avoid the considerable weaknesses ofthe UML by integrating our approach only with a w.r.t. structural as well asbehavioral questions more consistent subset.
By providing the bus like implementation structure shown in figure 8 for aclass, a clear separation between request specific and overall instance behavioris achieved. In figure 16 an example of a simple complete UML structure withadded nets is presented. It describes a class SiteImpl that implements a simpleallocation protocol which provides alternating allocate and release operation calls.The implementation stores the provided Data in a buffer initially filled withan empty data item. The buffer is accessed using the Buffer contract which isimplemented by the class BufferImpl. The three specific stereotypes <<contract>>for contracts, <<implementation>> for the overall instance behavior includingthe resource allocation net and <<service>> for a service net or method are
Fig. 16. An OCoN and UML example
69
used. For the operations SiteImpl::release and SiteImpl::allocate the differencebetween initial exclusive locking and shared access can be described. While forthe SiteImpl::release call forward action no initial exclusive locking is specifiedwill SiteImpl::allocate demand it. In correspondence is in SiteImpl::release theconsidered resource myB shown with a double bordered hexagon to indicatethat it is an imported resource and thus interference is possible. In contrast hasSiteImpl::allocate an exclusive resource for myB and thus the resource is drawnwith a single border. Also the number of used contracts Buffer for SiteImpl arespecified in the UML diagram and we can derive the related net capacities usingthe specified multiplicity constraints of the related association.
7 Related Work
The net dynamics of the OCoN approach has been realized introducing the visualas well as high-level Petri net conform CoN formalism. In the context of the π-calculus also a net based calculus named Mobile Nets has been developed [11]. Itextends the π-calculus to contain true concurrency , but this is done by extendingthe usual textual binding for π-calculus processes to cover some notion for placesthat can be accessed in parallel and thus does not provide the needed visual netrelated methapor like the CoN formalism neccessary to build a visual languageupon.
We think it is more promising for the system design with Petri nets to avoida Petri net specific mechanism and integrate Petri nets into an usual object-oriented decomposed system. The approach should rely on the well studied andsuccessful mechanisms for abstraction and encapsulation. Following [3] we canclassify most earlier proposed solutions to combine object orientation and Petrinets as either ”Petri nets inside Objects” [10] or ”Objects inside Petri Nets” [4,52]. Later approaches support more dynamic and expressive models where objectreferences are controlled in nets related to classes and thus they can support bothconcepts.
Another cruicial aspect for the design of an object-oriented Petri net for-malism is the interaction and if it supports interfaces and polymorphism ina manner adequate for software. Several approaches support the traditional ap-proach to connect Petri nets using place fusion [2, 34], but places usually provideno suitable interface directly. Most solutions derived from the algebraic specifi-cation domain instead provide cooperation in terms of transition fusion [4, 10,7, 17] and allow the related behavior to access all cooperating objects of thatactivity in a united action. This results in a missing encapsulation and behaviorwill not be associated with objects itself which is a common criteria for object-orientation. The support for message exchange or operations is essentially neededto achieve encapsulation. The different approaches that support this vary w.r.t.the level of support for either message passing or the higher-level interaction of aprocedure call construct [47,36, 12, 29]. The approaches provide an object stateeither explicit using one global net per instance [39,34, 47, 29] or only implicitas composition of so called method nets [36,12]. A systematic separation into
70
a resource oriented scheduler describing the overall instance state and methodrelated active method net instances is only realized in the OCoN approach. Toachieve visual scalability the usage of several nets for specific tasks is necessarywhile their simple visual separation using regions (cf. [12]) is not sufiicient.
For distributed system design the encapsulation has to be ensured and hencea notion of contract or interfaces is necessary and thus not type secure approacheslike [12] are not sufficient. Up to our knowledge does no other approach intergratean external behavioral specification like a protocol net to provide a contractnotion with behavioral subtyping and thus supports behavioral abstraction.
8 Conclusion and Outlook
The integration of software engineering and especially object-oriented technologywith a high-level Petri net formalism that is extended in a π-calculus style toalso cover dynamic aspects has been presented. The OCoN approach builds anorthogonal extension to a subset of the UML and adds powerful concurrencyand contract modeling capabilities. A tight integration has been achieved whileproprietary extensions to the UML itself could be avoided.
The contract notion for the OCoN design approach supports the explicitspecification of contractually relations and provides a notation to specify coor-dination aspects already on an abstract level. We can further express severaldesign alternatives and evaluate them [27] in order to decide which one is mostsuitable. Thus, the OCoN formalism is a suitable notation that can be appliedalready during the earlier stages of the design process with emphasis on thesoftware architecture [46]. A suitable visual notation is a crucial prequisite fora successful approach. We applied useful Petri net visualization concepts andachieved to preserve them by applying object-oriented standard techniques in asystematic fashion.
Our initial application domain has been distributed software systems, whilewe have also explored embedded systems and currently investigate the design ofworkflow [56] applications. The experience with student classes and courses indi-cates that even without experienced designers the approach is applicable. Whilethe results are promising the training for a specific net based notation is still dif-ficult for beginners. A framework supporting the final implementation of OCoNdesigns as well as an integration of the tools into an UML tool and extensionstowards consistency checks and complete simulation capabilities are planned. Atthe moment, we study the approach also in an industrial environment to gainmore experience with larger projects.
References
1. P. America. A Behavioural Approach to Subtyping in Object-Oriented Languages.Techreport, Philips Research Laboratories, 1989. Technical Report 443.
2. M. Baldassari and G. Bruno. An Environement of Object-Oriented ConceptualProgramming Based on PROT Nets. In Advances in Petri Nets, number 340 inLNCS, pages 1–19. Springer Verlag, 1988.
71
3. R. Bastide. Approaches in unifying Petri nets and the Object-Oriented Approach.In 1st Workshop on Object-Oriented Programming and Models of Concurrency,within the 16th International Conference on Application and Theory of Petri nets,27 June 1995, Turin, Italy, 1995.
4. E. Battiston, F. D. Cindio, and G. Mauri. Objsa Nets: A Class of High-Level NetsHaving Objects as Domains. In Advances in Petri Nets, number 424 in LNCS,pages 20–43. Springer Verlag, 1988.
5. E. Best and R. P. Hopkins. B(pn)2 - a Basic Petri Net Programming Notation. InPARLE’93, LNCS, pages 379–390. Springer Verlag, 1993.
6. A. Beugnard, J.-M. Jezequel, and D. Watkins. Making Components ContractAware. IEEE Computer, 32(7):38–45, July 1999.
7. O. Biberstein and D. Buchs. Structured Algrbraic Nets with Object-Orientation.In Applications and Theory of Petri Nets 1995, 16th International Conference,Turin, Italy, number 935 in LNCS. Springer Verlag, June 1995.
8. W. Brauer, R. Gold, and W. Vogler. A Survey of Behaviour and EquivalencePreserving Refinements of Petri Nets. In Advances in Petri Nets, number 483 inLNCS, pages 1–46. Springer Verlag, 1990.
9. W. Brauer, W. Reisig, and G. Rozenberg [eds]. Petri Nets: Central Models (partI)/Applications (part II), volume 254/255 of LNCS. Springer Verlag, Berlin, 1987.
10. D. Buchs and N. Guelfi. A Concurrent Object-Oriented Petri Net Approach. InApplications and Theory of Petri Nets 1991, 12th International Conference, Gjern,Denmark, 1991.
11. N. Busi. Mobile Petri Nets. In Proc. 3rd Int. Conf. on Formal Methods forOpen Object-based Distributed Systems (FMOODS), February 15-18, 1999, Flo-rence, Italy, pages 51–66. Kluewer Academic Publishers, 1999.
12. M. Ceska, V. Janousek, and T. Vojnar. PNtalk - A Computerized Tool for ObjectOriented Petri Nets Modeling. In EUROCAST’97, Las Palmas de Gran Canaria,Canary Islands, Spain, number 1333 in LNCS. Springer Verlag, 1997.
13. G. Chehaibar. Use of Reentrant Nets in Modular Analysis of Colored Nets. volume524, pages 58–77, Berlin, Germany, 1991. Springer Verlag. NewsletterInfo: 40.
14. S. Christensen and N. D. Hansen. Coloured Petri Nets Extended with Channelsfor Synchronous Communication. In LNCS; Application and Theory of Petri Nets1994, Proceedings 15th International Conference, Zaragoza, Spain, volume 815,pages 159–178. Springer Verlag, 1994.
15. D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and P. Jere-maes. Object-Oriented Development: The Fusion Method. Prentice-Hall, 1994.
16. Committee Draft ISO/IEC 15909. High-level Petri Nets - Concepts, Definitionsand Graphical Notation, Oct. 1997. Version 3.4.
17. J. Engelfriet, G. Leih, and G. Rozenberg. Net-Based Description of Parallel Object-Based Systems. In Foundations of Object-Oriented Languages, number 489 inLNCS. Springer Verlag, 1990.
18. A. Evans, R. France, K. Lano, and B. Rumpe. Developing the UMl as a FormalModelling Notation. In UML’98 Beyond the notation. International WorkshopMulhouse France. Ecole Superieure Mulhouse, Universite de Haute-Alsace, 1998.
19. H. Fleischhack and B. Grahlmann. A Petri Net Semantics for B(PN)2 with Proce-dures. In Proceedings of PDSE’97 (Parallel and Distributed Software Engineering),Boston MA, pages 15 – 27. IEEE Computer Society, May 1997.
20. H. J. Genrich and K. Lautenbach. System Modelling with High-Level Petri Nets.Theor. Comp. Science, 13:109 – 136, Jan 1981.
21. H. Giese. Object Coordination Nets 2.0 – Semantics Specification. Techreport,University Munster, Computer Science, May 1999. 15/99-I.
72
22. H. Giese. Towards a Dynamic Model for the UML. In 14th Annual ACM SIGPLANConference on Object-Oriented Programming Systems, Languages, and Applica-tions November 1-5, 1999, Denver, Colorado, USA. Workshop: Rigorous Modelingand Analysis with the UML: Challenges and Limitations, Nov. 1999. (submittedstatement).
23. H. Giese. Synchronization Behavior Typing for Contracts in Component-basedSystems. Techreport, University Munster, Computer Science, Distributed SystemsGroup, Feb. 2000. Techreport 03/00-I.
24. H. Giese, J. Graf, and G. Wirtz. Modeling Distributed Software Systems with Ob-ject Coordination Nets. pages 107–116, July 1998. Proc. Int. Symposium on Soft-ware Engineering for Parallel and Distributed Systems (PDSE’98), Kyoto, Japan.
25. H. Giese, J. Graf, and G. Wirtz. Closing the Gap Between Object-Oriented Model-ing of Structure and Behavior. In UML’99 - The Second International Conferenceon The Unified Modeling Language Fort Collins, Colorado, USA, volume 1723 ofLNCS, pages 534–549, Oct. 1999.
26. H. Giese, J. Graf, and G. Wirtz. Seamless Visual Object-Oriented Behavior Mod-eling for Distributed Software Systems. In IEEE Symposium On Visual Languages,Tokyo, Japan, Sept. 1999.
27. H. Giese and G. Wirtz. Early Evaluation of Design Options for Distributed Sys-tems. In Int. Symposium on Software Engineering for Parallel and DistributedSystems (PDSE’2000), Limerik, Ireland. IEEE Press, June 2000.
28. D. Harel. Statecharts: A Visual Formalism for complex systems. Science of Com-puter Programming, 3(8):231–274, 1987.
29. T. Holvoet and P. Verbaeten. PN-TOX: a Paradigm and Development Environ-ment for Object Concurrency Specifications. In 1st Workshop on Object-OrientedProgramming Models of Concurrency, Turin, 1995.
30. P. Huber, K. Jensen, and R. M. Shapiro. Hierarchies in Coloured Petri Nets. InAdvances in Petri Nets, number 483 in LNCS, pages 313–341. Springer Verlag,1990.
31. K. Jensen. Coloured Petri Nets. In Petri Nets: Central Models and Their Prop-erties, Advances in Petri Nets 1986 Part I, number 254 in LNCS, pages 248–299.Springer Verlag, 1987.
32. K. Jensen. Coloured Petri Nets: A High Level language for System Design andAnalysis. In Advances in Petri Nets, number 483 in LNCS, pages 342–416. SpringerVerlag, 1990.
33. A. Kiehn. Petri Net Systems and their Closure Properties. In Advances in PetriNets 1989, number 424 in LNCS, pages 306–328. Springer Verlag, 1990.
34. C. Lakos. From Coloured Petri Nets to Object Petri Nets. In Applications andTheory of Petri Nets 1995, 16th International Conference, Turin, Italy, number935 in LNCS. Springer Verlag, June 1995.
35. B. Liskov and J. M. Wing. A New Definition of the Subtype Relation. In Proceed-ings of the European Conference on Object-Oriented Programming ’93, volume 707of LNCS, pages 118–141, July 1993.
36. C. Maier and D. Moldt. Object Colored Petri Nets - a Formal Technique forObject Oriented Modelling. Workshop PNSE’97, Petri Nets in System Engineering,Modelling, Verification, and Validation, Hamburg, Germany, Sept. 1997.
37. B. Meyer. Object-Oriented Software Construction. Prentice Hall, 1997. 2nd edition.
38. R. Milner, J. G. Parrow, and D. J. Walker. A Calculus of Mobiler Processes.Techreport, Edinburgh Univeristy, 1989. Part I and II. ESC-LFCS-89-85/86.
73
39. A. Newman, S. M. Shatz, and X. Xie. An Approach to Object System Modeling byState-Based Object Petri Nets. Int. Journal of Circuits, Systems, and Computers,9(1):1–20, Feb. 1998.
40. Object Management Group. OMG Unified Modelling Language 1.3, June 1999.OMG document ad/99-06-08.
41. D. L. Parnas. A Technique for Software Module Specification with Examples.Communications of the ACM, 15(5):330–336, 1972.
42. S. L. Pfleeger. Software Engineering: Theory and Practice, 1/e. Prentice Hall,1998.
43. W. Reisig. Petri Net Models of Distributed Algorithms. In Computer ScienceToday – Recent trends and Developments, number 1000 in LNCS, pages 441–454.Springer Verlag, 1995.
44. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991.
45. T. Schael. Workflow Management Systems for Process Organizations. Number1096 in LNCS. Springer Verlag, 1998. Second Edition.
46. M. Shaw and D. Garlan. Software Architecture: Perspectives on an emerging Dis-cipline. Prentice Hall, 1996.
47. C. Sibertin-Blanc. Cooperative NETs. In Applications and Theory of Petri Nets1994, 15th International Conference, Zaragoza, Spain, number 815 in LNCS, pages471–490. Springer Verlag, June 1994.
48. Y. Souissi and G. Memmi. Composition of Nets via a Communication Medium.In Advances in Petri Nets, number 483 in LNCS, pages 457–470. Springer Verlag,1990.
49. I. Suzuki and T. Murata. A method for stepwise refinement and abstraction ofPetri nets. Journal Computer System Science, 27:51–76, 1983.
50. R. Valette. Analysis of nets by stepwise refinement. Journal Computer SystemScience, 18:35–46, 1979.
51. W. M. P. van der Aalst and T. Basten. Life-Cycle Inheritance: A Petri-Net-BasedApproach. In 18th International Conference on Application and Theory of PetriNets, Toulouse, France, June 1997, LNCS, pages 62–81, 1997.
52. K. van Hee and P. Verkoulen. Integration of a Data Model and High Level PetriNets. In Proceedings of the 12th International Conference on Application andTheory of Petri Nets,Aarhus, Denmark, pages 410–431, June 1991.
53. W. Vogler. Behaviour preserving refinements of Petri nets. In Graph-TheoreticConcepts in Computer Science, Proc. WG86, Bernried, volume 246 of LNCS, pages82–93, 1987.
54. P. Wegner. Dimensions of Object-Based Language Design. In Object-oriented Pro-gramming Systems, Languages and Applications (OOPSLA87, Orlando, Florida,October 4-8, 1987, volume 22 of SPECIAl ISSUE of ACM SIGPLAN notices, pages168–182. ACM Press, Dec. 1987.
55. P. Wegner and S. B. Zdonik. Inheritance as an Incremental Modification Mecha-nism or What Like Is and Isn’t Like. In Proceedings of the European Conference onObject-Oriented Programming ’88, volume 322 of LNCS, pages 55–77, Aug. 1988.
56. G. Wirtz and H. Giese. Using UML and Object-Coordination-Nets for workflowspecification. In IEEE International Conference on Systems, Man, and Cybernetics(SMC’2000), Nashville, TN, USA, October 8-11, 2000.
57. G. Wirtz, J. Graf, and H. Giese. Ruling the Behavior of Distributed SoftwareComponents. In Proc. Int. Conf. on Parallel and Distributed Processing Techniquesand Applications (PDPTA’97), Las Vegas, Nevada, July 1997.
74
Seamless Object-Oriented Software
Development on a Formal Base
Stephan Philippi
University of Koblenz-Landau,Rheinau 1, 56075 Koblenz, Germany
Abstract Object-oriented development of complex software systems iswidely recognized as state of the art within the industry as well as thescientific community. What is less commonly recognized (especially inthe industry) is that object-orientation itself is not properly defined andneither are popular notations like UML and others. Existing proposalsfor the formally based development of object-oriented systems are fordifferent reasons often not usable for complex and/or concurrent sys-tems. In addition, the semantics of object-oriented concepts within suchnotations only rarely match common programming language implemen-tations. This mismatch most likely leads to a costly redesign of a givenmodel during implementation. To overcome these problems approachesfor a seamless object-oriented software development on a formal base areneeded.
This article surveys several proposals for the formally based devel-opment of object-oriented systems based on Petri-Nets. Subsequently, anew approach in this area is introduced which supports multiperspectivemodeling of concurrent object-oriented systems on arbitrary abstractionlevels and also allows automatic generation of executable Java code.
Keywords: concurrent systems design, Petri-Nets, Java code-generation
1 Introduction
Today object-oriented software development practice often includes multiper-spective system views using different types of diagrams. The most popular collec-tion of such diagrams is the so-called unified modeling language (UML) [Rati99].Even if the emergence of this industry standard is useful from an economicalpoint of view, there are some serious drawbacks with respect to its applicationin the software engineering area. Besides the difficulties in choosing an adequatesubset of diagrams with respect to a specific application domain, further prob-lems arise from the UML’s lack of formality. In fact, most of the UML notationsare not formally based, i.e. they have no formally defined semantics. In combina-tion with the fact that a commonly agreed definition of ’object-orientation’ doesnot exist, this easily leads to communication problems, as neither the notations
75
nor the underlying concepts are properly defined. Another problem in this con-text is that a tight integration of different views in a formal sense is not givenwith the UML. Thus, contradicting system views representing a non-consistentmodel are usual observations within UML projects. Especially considering con-current systems this is not tolerable, as even for small systems a huge amount ofpossible interaction sequences between concurrent parts exists, which results indifficulties for human understanding. Thus, non-formally based approaches arenot well suited to meet today’s demands as they do not offer a reliable base forcommunication and understanding.
Principally, formally based approaches for the object-oriented modeling ofsystems are well suited to solve these problems. Nevertheless, proposals in thisarea are not widely accepted today. Major drawbacks of approaches like OOZE[AleGog91], VDM++ [Durr92], and others are that often no visual represen-tation of models exists and the development of concurrent systems as well assimulation is not supported. In addition, such approaches are frequently criti-cised for being too difficult to use1. Another crucial point is that the definitionsof object-oriented concepts in formally based notations only rarely match theircounterparts in programming languages. Theoretically this is not necessarily aproblem, as the realization of object-oriented concepts within common program-ming languages is not perfect at all, as shows for example the nonvariant insteadof covariant overwriting in Java [ArnGos96]. From a more practical point ofview the use of such formally based notations leads to a mismatch if a givenmodel serves as architectural layout for the implementation of a system, whichis usually the motivation for creating a model in the software engineering area.
Another family of approaches to model object-oriented systems in a formalway is based on Petri-Nets [Petri62], which are well known for their graphicalappearance, their simulation capabilities, and their native support for the mod-eling of concurrent systems. The extension of Petri-Nets with object-orientedconcepts is a promising approach as the resulting notation ideally allows forthe formally based modeling of concurrent object-oriented systems and for theobject-oriented structuring of Petri-Nets. Due to this potential, there has beenconsiderable research activity in the object-oriented Petri-Net area.
The next section of this article describes from a software engineering point ofview a set of properties for approaches integrating object-oriented concepts andPetri-Nets. Based on these properties, existing proposals are surveyed and typicalproblems discussed. Section three introduces OOPr/T-Models, a novel approachfor the integration of Petri-Nets and object-oriented concepts, which supportsthe multiperspective modeling of systems on arbitrary abstraction levels. Sectionfour describes the formal base of OOPr/T-Models as well as their automatictranslation to executable Java code. Finally, the last section gives a summaryand presents further perspectives.
1 A more detailed discussion of related problems with existing proposals in the area offormally based development of object-oriented systems can be found in [LanHau94].A survey on UML formalization approaches is given in [Evans∗98], [KeEvRu99].
76
2 Essential properties and related work
Since the mid-eighties, various approaches integrating object-oriented conceptsand Petri-Nets have been published. To be able to evaluate the existing pro-posals with respect to their applicability in the software development, a set ofessential properties is introduced. The classification of these properties as ’es-sential’ reflects that from our point of view, omitting one of them results in anotation which is not well suited for the object-oriented development of complex,concurrent software systems. Thus, to solve the above stated problems of (non-)formally based notations, an approach integrating object-oriented concepts andPetri-Nets ideally fulfills the following criteria:
– Completeness with respect to object-orientation: In order to be ableto structure systems in an object-oriented way, a notation combining object-orientation and Petri-Nets should at least support object identity, com-plex objects, classes, encapsulation, inheritance, overriding, and polymor-phism/late binding.
– Support for seamless development: Ideally, a notation for the model-ing of object-oriented systems supports every stage of development rangingfrom high-level analysis to low-level implementation. If a notation only sup-ports part(s) of the development cycle, every shift to another notation (e.g.a programming language) will almost inevitably result in a redesign of themodel, as no commonly accepted definition of object-orientation exists. Thereason for the need to redesign a given model in this context is that differ-ent notations integrate different object-oriented concepts, and correspondingconcepts often differ significantly from a semantical point of view, as for in-stance visibility definitions and inheritance.
’When examining object-oriented solutions, you should check thatthe method and language, as well as the supporting tools, apply toanalysis and design as well as implementation and maintenance. Thelanguage, in particular, should be a vehicle for thought which willhelp you through all stages of your work.’ [Meyer97]
– Completeness with respect to Petri-Nets: Petri-Nets are well-knownfor their graphical appearance, their power for the modeling of concurrentsystems, and their formal base which allows for simulation and analysis. Anapproach integrating object-oriented concepts and Petri-Nets should pre-serve these properties.
– Concepts to resolve inheritance anomalies: Ideally, a notation forobject-oriented software development allows for the modeling of concur-rent systems. As a consequence, concepts to resolve inheritance anomalies[MatYon93] should be supported by such a notation. Inheritance anomaliesoccur in concurrent object-oriented systems if synchronization conditions
77
are integrated into the functional description of a method. Problems arisehere, as within every subclass containing additional methods, the inheritedsynchronization conditions almost inevitably change. As a consequence, in-herited methods have to be redefined in subclasses to integrate the modifiedsynchronization conditions, even if there is no need to do so from a func-tional point of view. Thus, to be able to benefit from inheritance, a notationfor the development of concurrent object-oriented systems needs to integrateconcepts to avoid the redefinition of methods.
– Modeling ergonomics/usability: System modeling usually starts at ahigh level of abstraction, the main task being to collect knowledge in orderto understand the system domain. As this is a very difficult task in its ownright, the designer should not be hampered by a modeling framework whichdoes not offer the highest possible ergonomical degree, i.e. the formalismused to support modeling should be as easy as possible to learn and handle.Thus, modeling ergonomics is one of our main concerns even if this propertyis not exactly quantifiable. In particular, former users of Petri-Nets or object-oriented concepts should with only minor problems be able to use a newapproach combining both. Prerequisite is a ’natural’ solution allowing eachuser to feel familiar with the way concepts he already knew are integrated.
The result of the evaluation of existing approaches for the integration ofPetri-Nets and object-oriented concepts is that none of them offers an overall sat-isfactory solution with respect to the described properties. In detail, approacheslike PROT-Nets [BruBal86], OBJSA-Nets [BaDeMa88], POT/POP [EnLeRo90],SimCon [HeeVer91], OOCPN [Engl93], PN-TOX [HolVer95], and others are notcomplete with respect to our understanding of object-orientation, i.e. impor-tant concepts are not integrated, like for example inheritance or dynamic bind-ing. Another common problem from the point of view of software developmentis that approaches like Object/Behaviour Diagrams [KapSch91], Object-Nets[BoNuFe97], OOPN [Stulle97], and others represent objects as Petri-Net struc-tures. Consequently, dynamic object instantiation is not supported in order toavoid dynamic Petri-Net structures. In turn, such proposals only allow for themodeling of systems with a fixed number of objects which have to be identifiedduring system design. To support the development of software systems, suchapproaches (which are partly intended to be used for the modeling of techni-cal systems) are not well suited, because objects are usually instantiated anddestroyed at a high rate during the runtime of such a system.
Other approaches, e.g. PN-TOX [HolVer95] and OCoN [GiGrWi98], are in-tended for modeling only certain aspects of object-oriented systems, augmentingnotations like OMT [Rumb∗91] or UML. Thus, only parts of the resulting modelshave a formally defined semantics. Another point is that approaches like F-Nets[Deck95], OOPN [Stulle97], and others do not provide a single notation coveringthe life-cycle a project ranging from analysis to implementation. In detail, mod-eling the functional parts of an object-oriented system is not supported, whichleads to the use of other notations whilst shifting from higher to lower abstraction
78
levels. If functional modeling is supported, not necessarily are methods for thepartitioning of the functionality of an object. Such a practice does in consequencenot take full advantage of the structuring capabilities of object-orientation, e.g.SimCon [HeeVer91] and OPN [Lakos95].
In contrast to the stated problems with object-oriented concepts, most ofthe considered approaches are complete with respect to Petri-Nets, i.e. only fewproposals like OPM [Burk94] lack a formal base.
Considering the development of concurrent systems, none of the evaluatedproposals integrates concepts to resolve inheritance anomalies, even if all of themallow for the modeling of concurrent systems, e.g. [CeJaVo97] and [Maier97].
Finally, modeling ergonomics is generally not considered. In combination withthe fact that tool support is mostly not given, this leads to proposals which arepractically not usable for the development of complex (software) systems2.
To summarize, on the one hand none of the considered proposals for theintegration of Petri-Nets and object-oriented concepts is without weaknesseswith respect to the introduced essential properties. From our point of view,existing object-oriented Petri-Net approaches are thus only of limited use forthe development of software systems. On the other hand, each of the criteria(except the integration of concepts to resolve inheritance anomalies) is fulfilledby at least one of the considered proposals. As a consequence, the developmentof a Petri-Net based notation which is practically usable for the seamless, object-oriented development of complex and/or concurrent software systems should bepossible at least from a theoretical point of view.
One of the most common problems with the existing work in the area ofobject-oriented Petri-Nets is that only few proposals are based on one another,i.e. in most cases the experience from existing work is not taken into account forthe development of novel approaches. In contrast, common pitfalls of existingproposals had a direct impact on the development of OOPr/T-Models, whichare intended to overcome the limitations of existing approaches with respect tothe introduced properties.
3 Systems modeling with OOPr/T-Models
This section introduces OOPr/T-Models (’object-oriented Predicate/Transition-Models’), which were developed based on the set of essential properties as wellas on the evaluation of existing object-oriented Petri-Net approaches.
First of all, the scenario to set up multiperspective system views with OOPr/T-Models is shown. Then the notations used to describe these views are intro-duced using an object-oriented version of a simple producer/consumer system.Afterwards, an example on how to resolve inheritance anomalies with OOPr/T-Models is given using an extended version of the initial example. The formalbase of OOPr/T-Models as well as their automatic translation to Java code aresurveyed in section four.2 A more complete overview and detailed evaluation of existing object-oriented Petri-
Net proposals is given in [Phil99].
79
3.1 The scenario of OOPr/T-Modeling
The scenario providing an overview on how to use OOPr/T-Models is givenin figure 1. Starting from a system to model, different views have to be setup, namely a static, a dynamic, and a functional view. The interdependenciesof these views result in the following (cyclic) three-step design process, whichapplies to arbitrary development stages ranging from high-level analysis to low-level implementation. In the latter case OOPr/T-Models can be used as visualprogramming language.
1. Usually, the starting point of object-oriented modeling is a class diagramstructuring the system domain into classes with their respective relation-ships. As Petri-Nets themselves are not very well suited to model the staticaspects of a system, our approach incorporates a subset of UML class dia-grams [Rati99] for this purpose.
2. For each class a dynamic model is defined using Petri-Nets. Here, dynamicmodels integrate conditions for the activation of methods. This allows forthe separation of the functionality of a method and its synchronization con-ditions, thus resolving inheritance anomalies.
3. For each non-abstract method a single extended (hierarchical) Pr/T-Net[GenLau81] describes the intended functionality.
systemto model
manual model building
Pr/T-Net
integration
static
dynamic view
functional view
Java
view
automatic
Fig. 1. Scenario of OOPr/T-Modeling
Unlike OMT, UML and other basically similar modeling frameworks to setup multiperspective system views, OOPr/T-Models have a formally defined se-mantics given through a set of rules which allow for the automatic translationof OOPr/T-Models into a single Pr/T-Net as described in section four. Thus, itis not only single views that have a formally defined semantics, but the wholesystem consisting of different views and their interdependencies does. From adesigner’s point of view the resulting Pr/T-Net integrating these views shouldbe transparent, because usually only manually created views are visible. Thenotations to set up these views are described in the following sections.
80
3.1.1 Static view
The first step in modeling states the structure of a system using classes which arerelated through associations and an inheritance hierarchy. An interface definitioncan be assigned to each class, consisting of (class) attribute and method signaturespecifications. To visualize this structure a subset of UML class diagrams is used[Rati99]. Figure 2 shows a class diagram for a producer/consumer system at alow abstraction level.
count : intcapacity : Int
+ sync insert (x : int)+ remove() : int
buffer
+ produce ()
id : intb : buffer
producer
+ consume ()
id : intb : buffer
consumer
+ start ()
controller
Fig. 2. Class diagram for a producer/consumer system
By definition, each system contains a default ’controller’ class with a ’start’method as system starting point. The diagram also contains classes ‘producer’,’consumer‘, and ’buffer’, the latter associated to the former ones. Class ’buffer’includes two attributes ’count’ and ’capacity’ for storing actual/maximum dataitem entries and methods ’insert’ and ’remove’. The ’producer’ and ’consumer’classes each consist of attributes ’b’, implementing the association to ’buffer’,and ’id’ as well as a single signature for a method without return value. Thisis an important aspect, as patterns of concurrency are not explicitly definedin OOPr/T-Models in terms of ’threads’ or similar low-level concepts. Instead,calls to ’asynchronous methods’ not returning any value as well as forward splittransitions within functional descriptions of methods start concurrent processesimplicitly. Here, asynchronous methods can be synchronized by using an addi-tional keyword (’sync’) extending the signature definition if the activation ofa method without return value should not lead to the implicit start of a newthread, e.g. method ’insert’ of class ’buffer’3.
3.1.2 Dynamic view
The second step in the design process consists of creating a dynamic model foreach class of the system. Dynamic models are used to specify activation condi-tions for publicly available methods. Like attributes, these conditions are objectproperties, i.e. each object holds its own dynamic model during the runtime of3 In contrast, ’synchronized’ in Java specifies mutually exclusive access.
81
a system. A dynamic model is set up using Petri-Nets with anonymous tokenswhere each transition represents a publicly available method of the correspond-ing class. To each transition a guard may be assigned containing an expressionwith attribute identifiers of the associated class. If an object receives a mes-sage, the addressed method is activated if the preconditions of the associatedtransition as well as its guard allow to do so. If a method is activated, tokenswithin the dynamic model are consumed by the associated transition. After theexecution of the method is terminated, new tokens are created on outgoing arcs.Thus, from a designer’s point of view transitions within dynamic models haveno timeless behaviour, as tokens disappear while methods are being executed.From a semantical point of view, however, this is a syntactical abbreviation, i.e.a shortcut for a more complex ’real’ Petri-Net structure with additional placesrepresenting currently active methods.
Dynamic models are inherited within a class hierarchy like attributes andmethods. Here, dynamic models are only allowed to be modified in subclasses ac-cording to refinement rules [Hutten00] based on protocol inheritance [AalBas97].
insert remove
[count < capacity] [count ≠ 0]
buffer
Fig. 3. Dynamic model of class ’buffer’
Figure 3 shows the dynamic model for class ’buffer’ of the producer/consu-mer system. Here, methods ’insert’ and ’remove’ are not allowed to be activatedconcurrently to avoid inconsistencies. Similarly, ’insert’ is only allowed to beactivated if the amount of buffer elements is lower than the upper boundary,whereas ’remove’ is only allowed to be activated if the buffer is not empty. Acloser look on the use of dynamic models to resolve inheritance anomalies isgiven in section 3.2.
3.1.3 Functional view
To be able to model the functionality of a method, high-level Petri-Nets need tobe extended to support specific interfacing services. Figure 4 illustrates a methodfrom a black-box point of view, with the following types of interactions with theenvironment:
1. An input interface: As possible input to a method we consider signaturespecified parameters and current attribute values of the object the respectivemethod belongs to.
82
2. An interaction interface: As the overall behaviour of an object-orientedsystem is given through the interaction of its message-passing objects, aPetri-Net representing a method has to be able to send messages.
3. An output interface: Possible method outputs are new attribute-valuesof the current object, and return values to the sender of the message whichactivated the execution of the method.
method
attribute values method parameters
return valuenew attribute values
methodinteraction
Fig. 4. Black-box view of a method
This black-box view of a method does not contain the proper objects asin- and output values. Instead, a finer granularity is given, considering currentattribute values. Thus, the answer to the question what exactly flows througha Petri-Net representing a method is not objects, but relevant parts of objects.The reason for the decision not to let the objects themselves flow through amethod is to avoid a situation in which one object moves through differentconcurrent threads of one method, as this could lead to different versions ofthe same object, each having different attribute values. These versions wouldhave to be merged at the end of the execution of a method with respect toits semantics to become consistent. This would be achieved with the help ofadditional modeling constructs, which would lead to more complex models.
What follows is a description of Pr/T-Net extensions, introduced to enablecommunication from a net-specified method with the environment as describedabove.
Input interface extensions for Pr/T-Nets:
The input interface is simply a set of bold printed places. These ’preload places’called net elements serve different tasks. As already mentioned, input values formethods are parameters, given by the message received from the object for whicha method is to be executed, as well as current attribute values. Considering amethod signature like ’method name (arg1 : type1,...,argn : typen)’, the execut-ing method needs to access parameters arg1,...,argn. Utilizing preload places,import of these parameters into a method is achieved simply by assigning sucha place the respective parameter identifier (fig. 5a). If a method is executed,
83
the value of the parameter assigned to the preload place is transparently loadedinto this place, which further behaves like an ordinary one. Preload places areused analogously to import attribute values by assigning to them the respectiveidentifiers (fig. 5b), as well as for the initialization of local variables (fig. 5c).Furthermore, ’self’ can be assigned to preload places (fig. 5d), which explicitlyimports the OID of the object for which the method was activated. Finally,preload places can be annotated with tuples built from these alternatives. Insummary, preload places are used to define an object-dependent initial markingfor nets describing the functionality of methods in object-oriented models.
attributeparameter
a) b) c)
type : value
d)
´self´
Fig. 5. Preload places serving different tasks
Interacting interface extensions for Pr/T-Nets:
To communicate with the environment of a method we need to be able to sendmessages. Therefore, a special kind of transition called ’message transition’ isintroduced (fig. 6).
OID.message(arg ,...arg )->return_valuen1
Fig. 6. Message transition
From a designer’s point of view, a message transition is simply a transitionwith a message specification in it. The OID of the object the message shouldbe sent to and the respective method parameters have to be transported to themessage transition, where arcs can be annotated as usual within Pr/T-Nets. Ifthe method to be activated with a message is a synchronous one, the returnvalue can be used in further steps of the execution of the method. Analogue todynamic models, such a transition does not fire timeless as it has to wait for thereturn value of the method to be activated. From a semantical point of view,this is again only a syntactical abbreviation for a more complex net structure.
Output interface extensions for Pr/T-Nets:
Similar to the input interface special kinds of places are introduced to serve asoutput interface. To indicate the end of the execution of a method, a so called
84
’exit place’ is introduced by a double circle (fig. 7a). If a token resides on sucha place the execution of the method ends. In case of a synchronous method thistoken is returned to the sender of the activating message.
attribute
a) b)
Fig. 7. Exit and postsave place
Attributes often have to be updated at the end of the execution of a method.To be able to model such a case in a comfortable way, ’postsave places’ areintroduced by bold circles like preload places (fig. 7b). Preload and postsaveplaces can be distinguished easily in a given net: the former has at least oneoutgoing arc and may have incoming arcs, whereas the latter may have incomingarcs only. A postsave place is annotated with the attribute identifier to whichthe token resident on this place should be the new value as soon as the executionof the method ends. If attributes need to be accessed not only at the start/endof the execution of a method, message transitions calling the implicitly defined’get’ and ’set’ methods of an attribute have to be used.
Using Pr/T-Nets with a place capacity of ’1’ extended this way the specifi-cation of methods ’produce’ and ’consume’ of the example results in fig. 8.
b.insert(id)
b, id
b, id
b, idb, id
b, id
producer.produce ()
b.remove() -> x
b
b, x
bb
b, x
consumer.consume ()
Fig. 8. Methods of classes ’producer’ and ’consumer’
As ’produce’ gives no return value activation of this method results in the(implicit) creation of a new concurrent process. This process imports the currentvalues of attributes ’b’ and ’id’ into the net, using a single preload place. After-wards, method ’insert’ of the associated ’buffer’ object is activated with the ’id’of the producer as argument utilizing a message transition. If the amount of data
85
elements stored within the addressed buffer object exceeds the maximum bound-ary, or if any of the methods ’insert’ or ’remove’ is already active, the producerprocess is suspended. If the state of the dynamic model of the ’buffer’ objectallows for the activation of ’insert’, the suspended producer process continuesafter termination of this method.
Within method ’consume’ a preload place imports the value of attribute ’b’into the net, i.e. the identifier of the associated ’buffer’ instance. This value isfurther used as destination of the message sent to activate the ’remove’ methodusing a message transition. Here, a ’consumer’ process implicitly activated bycalling its asynchronous ’consume’ method is suspended if the state of the dy-namic model of the ’buffer’ instance demands so, i.e. if there is no element to beremoved from the buffer or if a method of this object is currently executed. If thestate of the dynamic model of the associated ’buffer’ object allows for activationof ’remove’, the consumer process continues after termination of this method.
Even if the producer/consumer example is presented including all implemen-tation details, OOPr/T-Models offer support for object-oriented modeling onarbitrary abstraction levels. Class diagrams (which can be organized throughpackages) to structure a system domain are in principle useful at every abstrac-tion level. Dynamic and functional descriptions can be added and stepwise re-fined in a seamless way if details become more relevant. The descriptions of themethods of a system may include supertransitions [HuJeSh90] for abstractionpurposes in the early stages and functional decompositions in the later ones.
3.2 Avoiding inheritance anomalies
After having introduced the OOPr/T-Model notations, the subject of this sub-section is now the description of a slightly modified producer/consumer sys-tem to illustrate the use of dynamic models to resolve inheritance anomalies[MatYon93].
Inheritance anomalies are very likely to occur within concurrent object-oriented systems if there are no concepts to separate the synchronization condi-tions of a method from its functionality. In case such concepts are not available,the extension of a superclass by a subclass with additional methods leads to theredefinition of inherited methods within the subclass. The reason for this need toredefine inherited methods stems from the integrated synchronization conditions,which almost inevitably change if a subclass includes additional methods. Dueto these problems, early ’object-oriented’ programming languages for concur-rent systems like POOL/T [Amer87], PROCOL [BosLaf89], and others offeredno support for the concept of inheritance to avoid related anomalies.
The separation of a the synchronization conditions of a method from itsfunctionality is realized by OOPr/T-Models through the use of separate dynamicand functional views. To illustrate this aspect, figure 9 gives a modified versionof the static view of the initial producer/consumer system.
Here, class ’new buffer’ extends its superclass with an additional method ’re-move new’. This method intends to remove an element out of the buffer onlyif a call to method ’remove’ has not followed the last activation of ’insert’, i.e.
86
+ remove_new() : int
new_buffer
count : intcapacity : Int
+ insert (x : int) : bool+ remove() : int
buffer
+ start ()
id : intb : new_buffer
producer
+ start ()
id : intb : new buffer
consumer
+ start ()
controller
Fig. 9. Extended producer/consumer system
’remove new’ is only allowed to be activated immediately after ’insert’. Withina language not integrating concepts to resolve inheritance anomalies, this acti-vation condition leads to a reimplementation of the inherited methods ’insert’and ’remove’ to be able to indicate which was activated last, even if there isno need to do so from a functional point of view. OOPr/T-Models avoid suchredefinitions as a consequence of class extensions through the use of separatedynamic models, which include synchronization conditions. Figure 10 gives thedynamic model assigned to class ’new buffer’, which specifies that method ’re-move new’ is only allowed to be activated if invoked immediately after ’insert’.In consequence, the inherited methods ’insert’ and ’remove’ remain unchangedin class ’new buffer’, thus resolving inheritance anomalies.
insert remove
[count < capacity] [count ≠ 0]
remove_new
new_buffer
insert
[count < capacity]
remove
Fig. 10. Dynamic model for class ’new buffer’
87
4 OOPr/T-Models and their formal base
Unlike OMT, UML, and other modeling frameworks to set up multiperspectivesystem views, OOPr/T-Models have a formally defined semantics and allow forthe automatic generation of executable Java code. This section outlines both.
4.1 Translation to Pr/T-Nets
The formal base of the introduced notation is given by a set of translation ruleswhich generate a Pr/T-Net out of a given OOPr/T-Model. Here, static, dynamicand functional views are integrated. In consequence, it is not only single viewsbut the whole system that has a formally defined semantics in terms of a Pr/T-Net extended with supertransitions and place fusion [HuJeSh90].
The main idea is to use predefined patterns for building a Pr/T-Net-basedobject-oriented runtime system which integrates the static, dynamic and func-tional views of an OOPr/T-Modell. The elementary structure of such a Pr/T-Netconstructed from a given OOPr/T-Model serves the purpose of message routing,providing the communication infrastructure needed in object-oriented systems.Figure 11 gives an abstract sketch of the runtime system, which is set up hi-erarchically with a single place as root called ’system message collector’. Everymessage sent in a system is placed here first, utilizing place fusion. Each class ofan object-oriented system is represented by a Pr/T-Net structure, which is con-nected to the ’system message collector’ by a single transition. The guard of sucha transition evaluates to ’true’ if a message resident on the ’system message col-lector’ is to be sent to the associated class. If such a transition fires, the messageis taken from the ’system message collector’ to the ’class message collector’ of therespective class. The Pr/T-Net representation of each class integrates its associ-ated dynamic and functional models. In order to connect dynamic and functionalmodels to a class representation, the respective views of an OOPr/T-Model needto be transformed into Pr/T-Nets first. This translation, which is in detail de-scribed in [Phil99], allows concurrent reentrant usage of functional models, i.e. aPr/T-Net representing a method exists only once within its defining class. Thesame holds for dynamic models which are object properties like attributes, butwhich exist, like methods, only once within each class. If a message is routed tothe method to activate, and the dynamic model of the respective object allowsfor execution, the preload places of the addressed method are initialized.
Figure 12 gives an abstract sketch of the top-level Pr/T-Net structure whichrepresents a class and serves message routing purposes. If a message resides ona ’class message collector’, the following cases are distinguished:
– ’create’: In order to instantiate a new object, its definition is needed, i.e. aclass representation has to store static information concerning object defini-tions to be able to instantiate new ones. This is realized using a prototypefor each class whose structure reflects the attribute definitions of the staticOOPr/T-Model. If a new object is to instantiate, this prototype is dupli-cated and a new OID generated. This identifier is then returned to the caller
88
[ message for ´method 1´ ]
net structurerepresenting ´method 1´
. . . . . .
. . . . . .
’system message collector’
message
’class message collector’
[ message for ´class 1´ ]
[ message for ´class n´ ]
[ message for ´method n´ ]
. . . . . .
. . . . . .
net structurerepresenting ´class 1´
message
message
. . . . . .
message
net structure representingdynamic model of ´class 1´
. . . . . .
Fig. 11. Abstract sketch of the e.g. system
of the method in order to be able to reference the new object. To store all itsobjects, each class integrates a single place called ’extent’, i.e. if an object iscreated, the duplicated prototype with its newly generated OID is insertedinto the set of already existing objects of this class residing on the extent.
– ’get attribute’, ’set attribute’ : As the extent storing all objects of aclass is transparent, i.e. not directly accessible from a user’s point of view,predefined ’get’ and ’set’ basic update methods for each attribute have tobe used. If such a method is invoked, the requested attribute value is ex-tracted/replaced from the respective object in the extent. Due to the fact,that basic update methods are the only way to access attributes of an object,the use of preload and postsave places within functional OOPr/T-Models isonly a syntactical abbreviation of their explicit use.
’class message collector’
message
[message for user- defined method ]
’list of available ’get’ and ’set’-methods’
[’return’][’create’]
[’get’, ’set’]
list
list
list
list
message
message
message. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
Fig. 12. Schematic pattern for representing classes within Pr/T-Nets
89
– user-defined methods: If a message addresses a user-defined method, thismessage is routed to the Pr/T-Net representation of the respective functionalOOPr/T-Model. If the addressed method is inherited, the message to invokethis method is redirected to the superclass where the corresponding Pr/T-Net representation is included. This practice avoids the need to representthe functional model of a method defined in one class within each of itssubclasses. If the message reaches the Pr/T-Net representation of the methodand the dynamic model allows for execution, the preload places of the methodare initialized.
– return message: In order to be able to return a value from a synchronousmethod to the sender of the message activating this method, an internal(transparent) ’return message’ is used. If a class receives such a message, thevalue returned is routed to the respective method.
The Pr/T-Net structures extending the described top-level view of a classrepresentation providing a more detailed insight into the formal base of OOPr/T-Models are given in [Phil99]. A prototype to support the graphical editing ofOOPr/T-Models is developed in [George99]. This prototype also allows for theautomatic generation of executable Java code, which is described next.
4.2 Java code-generation
Due to the formal base of OOPr/T-Models, they are not only suited to serve asarchitectural layout for implementation. Additionally, executable Java code canbe automatically generated, because the formal semantics of OOPr/T-Modelsas described in the last section is explicitly defined to be compatible with theway object-oriented concepts are integrated in Java (other languages are alsopossible). This binding to a programming language results from our goal to sup-port seamless software development ranging from high-level analysis to low-levelimplementation and the not commonly accepted definition of object-orientation,which leads to different programming language interpretations.
At early development stages with their abstract high-level models automaticcode-generation is only rarely useful, as implementation details are not knownor considered. In contrast, this feature can be useful during the design periodto create class frames from the architecture, if a direct use of the destinationlanguage for implementation purposes is preferred. If a particular applicationdemands a partial or a complete formal model, OOPr/T-Models can be useddown to the visual programming level.
In detail, static, dynamic, and functional views are translated to Java ac-cording to the following principles:
– Static view: The generation of Java classes from a static OOPr/T-Model ismostly straightforward. A difference between Java and OOPr/T-Models isthat the latter supports generic classes (templates). To be able to map thisconcept to Java, a preprocessing step is introduced which first replaces ab-stract parameters of generic classes by actual ones. Furthermore, additional
90
classes need to be introduced to the Java code to implement the implicitstart of a new Java thread if a method without return value is activated andits ’sync’ flag is not set within the OOPr/T-Model.
– Dynamic view: A dynamic model specifies activation conditions for pub-licly available methods of the class it is assigned to. To integrate a dynamicmodel into each instance of a Java class, each place of such a model is trans-lated into an additional attribute of type ’int’, which stores the amount oftoken resident on the corresponding place. If a publicly available method isto activate, an additional method is called which returns if the current stateof the dynamic model allows for the execution of the method. If so, this ad-ditional method changes the state of the dynamic model. Then the methodis executed and finally the dynamic model is updated again to indicate thatthe execution of the method is terminated. If the dynamic model does notallow the activation of a method, the requesting thread is suspended untilthe dynamic model of the particular object changes.
– Functional view: The generation of Java methods from correspondingfunctional OOPr/T-Models is realized with a Pr/T-Net simulator in eachmethod. Here, each place of a functional model is translated into a pair oflocal variables, the first of which indicates if a token resides on the corre-sponding place. The particular value of this token is then stored within thesecond variable. Each transition of a functional OOPr/T-Model is translatedinto an ’if’-statement as part of a loop which terminates if a value exists onthe local variable representing the exit place of the functional OOPr/T-Model. The preconditions to fire a transition are then translated into theenabling conditions of the corresponding ’if’-statement. If such a conditionholds, values are removed from local variables representing places with in-coming arcs to the respective transition. Furthermore, new values are pro-duced and assigned to the local variables representing places with outgoingarcs from the transition represented by the ’if’-statement.
The described generation of Java code gives reasonable results but is not yetoptimized and has several drawbacks which are mainly related to the transla-tion of functional models. In fact, the use of a Pr/T-Net simulator within eachmethod is not the best choice, as only interleaving concurrency is supportedwithin a method. Additionally, this approach lacks efficiency especially consid-ering complex methods. We are currently working on a more sophisticated solu-tion for code-generation which is intended to result in true concurrency withinmethods and a more efficient code.
5 Summary and further perspectives
This article has introduced OOPr/T-Models which were developed to overcomethe problems of existing proposals in the area of object-oriented Petri-Nets withrespect to a set of properties which we consider essential. As a result of working inthis direction, OOPr/T-Models are complete with respect to object-orientation
91
and Petri-Nets. Furthermore, concepts to resolve inheritance anomalies are in-tegrated and a comparatively ergonomical notation is given, even if the lattercan not be proved due to its qualitative nature. Finally, OOPr/T-Models allowfor the multiperspective development of (software) systems with static, dynamic,and functional views on arbitrary abstraction levels ranging from high-level anal-ysis to visual programming. In combination with automatic code-generation,seamless object-oriented software development on a formal base is supported.
OOPr/T-Models have proven to be applicable not only to small systemslike the described producer/consumer example which mainly illustrates concur-rency synchronization features. An example containing more complex methodsfrom a functional point of view is described in [Phil00] with the specificationof a system for the concurrent calculation of primes. More complex concurrentobject-oriented systems were created with OOPr/T-Models also, namely a frac-tal rendering and a ray-tracing system [Hutten00]. The image synthesis of thelatter includes features like different geometric objects, multiple lights sources,reflection, shading, transparency etc. All these examples were refined down tothe visual programming language level, and executable concurrent Java code wasgenerated from them.
The overall results from developing the described systems using OOPr/T-Models are encouraging, even if there still remain some open issues. To be ableto further develop the concepts of OOPr/T-Models and the supporting tool, morecase studies from different application areas are needed. Another field of interestis the mapping of UML notations to dynamic and functional OOPr/T-Models.This would allow for the formalization of UML parts and the hiding of Petri-Nets from a designer’s point of view, if necessary. Integration of an additionalsemi-formal (but Petri-Net based) notation to support the communication withdomain experts especially in the early analysis stages is possible as well (e.g.[Marx98]).
Besides the ongoing work on these topics, future developments will includeextensions of the notation and the tool with concepts to handle persistent data,integration of mechanisms to model/generate distributed systems (CORBA) aswell as a GUI building facility. Ideally, these improvements will lead to anintegrated CASE-tool for the seamless development of concurrent/distributedobject-oriented (software) systems throughout the whole development processon the formal base of Petri-Nets.
References
[AalBas97] W.M.P. van der Aalst und T. Basten. Life-cycle Inheritance: APetri-net-based approach. Application and Theory of Petri Nets 1997,Band 1248 von LNCS. Springer-Verlag, Berlin, 1997.
[AleGog91] A. J. Alencar und J. A. Goguen. ’OOZE: An Object OrientedZ Environment’. P. America, ’ECOOP ’91: European Conference onObject Oriented Programming’, LNCS 512. Springer-Verlag, 1991.
92
[Amer87] P. America. ’Inheritance and subtyping in a parallel object-orientedlanguage’. ’ECOOP ’87: European Conference on Object Oriented Pro-gramming’, LNCS 276. Springer-Verlag, 1987.
[ArnGos96] K. Arnold und J. Gosling. ’The Java Programming Language’.Addison-Wesley, 1996.
[BaDeMa88] E. Battiston, F. DeCindio und G. Mauri. ’OBJSA Nets: a classof high level nets having objects as domains’. ’Advances in Petri-Nets1988’, LNCS 340. Springer-Verlag, 1988.
[BoNuFe97] T. Boehme, J. Nuetzel und W. Fengler. ’Objektorientiertes En-twurfsmodell fur Steuerungssysteme auf Basis der Petri-Netz-Theorie’.D. Abel E. Schnieder, ’Entwurf komplexer Automatisierungssysteme’,Braunschweig, 1997.
[BosLaf89] Jan van den Bos und Chris Laffra. PROCOL – A Parallel ObjectLanguage with Protocols. Proceedings of the OOPSLA ’89 Conferenceon Object-oriented Programming Systems, Languages and Applications,S. 95–102, Oktober 1989.
[BruBal86] G. Bruno und A. Balsamo. ’Petri net-based object-oriented mod-elling of distributed systems’. ACM SIGPLAN Notices, 21(11), Novem-ber 1986.
[Burk94] R. Burkhardt. ’Modellierung dynamischer Aspekte mit dem Objekt-Prozess-Modell’. Dissertation, Technische Universitat Ilmenau, 1994.
[CeJaVo97] M. Ceska, V. Janousek und T. Vojnar. ’PN-Talk - A Comput-erized Tool for Object-Oriented Petri Nets Modelling’. ’Proceedings ofthe 6th International Workshop on Computer Aided Systems Theory -EUROCAST‘97’, LNCS 1333. Springer-Verlag, 1997.
[Deck95] G. Decknatel. ’F-Nets’. Diplomarbeit, Universitat Koblenz-Landau,1995.
[Durr92] E. Durr. ’A formal specification language for object-oriented designs’.P. Dewilde und J. Vandewalle, ’IEEE CompEuro 92 Proceedings’. IEEEPress, 1992.
[Engl93] S. English. ’Coloured Petri Nets for object-oriented modelling’. Disser-tation, University of Brighton, 1993.
[EnLeRo90] J. Engelfriet, G. Leih und G. Rozenberg. ’Net-Based Descrip-tion of Parallel Object-Based Systems’. ’Foundations of Object-OrientedLanguages’, LNCS 489. Springer-Verlag, 1990.
[Evans∗98] Andy Evans, Jean-Michel Bruel, Robert France, Kevin Lanound Bernhard Rumpe. Making UML Precise. Luis Andrade, AnaMoreira, Akash Deshpande und Stuart Kent, Proceedings of the OOP-SLA’98 Workshop on Formalizing UML. Why? How?, 1998.
[GenLau81] H. J. Genrich und K. Lautenbach. ’System Modelling with High-Level Petri Nets’. Theoretical Computer Science, 13(1), 1981.
[George99] T. George. ’OOPr/T-Modeller : Ein Werkzeug zur Modellierungnebenlaufiger objektorientierter Systeme auf der Basis von UML undPetri-Netzen’. Diplomarbeit, Universitat Koblenz-Landau, 1999.
[GiGrWi98] H. Giese, J. Graf und G. Wirtz. ’Modeling Distributed SoftwareSystems with Object Coordination Nets’. ’Int. Symposium on SoftwareEngineering for Parallel and Distributed Systems (PDSE’98)’, Kyoto,April 1998.
[HeeVer91] K. M. van Hee und P. A. C. Verkoulen. ’Integration of a DataModel and High-Level Petri-Nets’. ’Proceedings of the 12th Interna-
93
tional Conference on Applications and Theory of Petri-Nets’, Gjern(Denmark), 1991.
[HolVer95] T. Holvoet und P. Verbaeten. ’PN-TOX: a Paradigm and Develop-ment Environment for Object Concurrency Specifications’. ’Proceedingsof the 16th International Conference on the Application and Theory ofPetri-Nets’, Turin, 1995.
[HuJeSh90] Peter Huber, Kurt Jensen und Robert M. Shapiro. ’Hierarchiesin Coloured Petri Nets’. G. Rozenberg, ’Advances in Petri Nets 1990’,LNCS 483. Springer-Verlag, 1990.
[Hutten00] P. von Hutten. ’Modellierung eines Ray-Tracers mit OOPr/T-Modellen’. Diplomarbeit, Universitat Koblenz, erscheint 2000.
[KapSch91] G. Kappel und M. Schrefl. ’Using an Object-Oriented Diagram-Technique for the Design of Information Systems’. H.G. Sol und K.M.van Hee, ’Dynamic Modelling of Information Systems’. Elsvier SciencePublishers B.V. (North-Holland), 1991.
[KeEvRu99] S. Kent, A. Evans und B. Rumpe. UML Semantics FAQ. A. Mor-eira und S. Demeyer, Object-Oriented Technology, ECOOP’99 WorkshopReader. LNCS 1743, Springer Verlag, 1999.
[Lakos95] C. Lakos. ’From Coloured Petri Nets to Object Petri Nets’. ’Proceedingsof the 1st Workshop on Object-Oriented Programming and Models ofConcurrency’, Turin, 1995.
[LanHau94] K. Lano und H. Haughton. ’A Comparative Description of Object-Oriented Specification Languages’. K. Lano und H. Haughton, ’Object-Oriented Specification Case Studies’. Prentice Hall International, 1994.
[Maier97] C. Maier. ’Objektorientierte Analyse mit gefarbten Petri-Netzen’.Diplomarbeit, Universitat Hamburg, 1997.
[Marx98] T. Marx. ’NetCase : Softwareentwurf und Workflow-Modellierung mitPetri-Netzen’. Dissertation, Universitat Koblenz-Landau, 1998.
[MatYon93] S. Matsuoka und A. Yonezawa. ’Analysis of Inheritance Anomalyin Object-Oriented Concurrent Programming Languages’. Research Di-rections in Concurrent Object-Oriented Programming, 1993.
[Meyer97] Bertrand Meyer. Object-oriented Software Construction. PrenticeHall, second edition, New York, N.Y., 1997.
[Petri62] C. A. Petri. ’Kommunikation mit Automaten’. Dissertation, Institutfur Instrumentelle Mathematik Bonn, 1962.
[Phil99] S. Philippi. ’Synthese von Petri-Netzen und objektorientiertenKonzepten’. Dissertation, Universitat Koblenz-Landau, 1999.
[Phil00] S. Philippi. ’Modeling of concurrent object-oriented systems using high-level Petri-Nets’. Proceedings of the 4th World Multiconference on Sys-temics, Cybernetics and Informatics (SCI’2000), Orlando, USA, 2000.
[Rati99] Rational Software Corporation. ’UML-Documentation 1.3’.’www.rational.com/uml’, 1999.
[Rumb∗91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy undW. Lorensen. ’Object-oriented modeling and design’. Prentice HallInternational, 1991.
[Stulle97] M. Stulle. ’Ereignisdiskrete Zustandsrekonstruktion auf der Grund-lage objektorientierter Petri-Netz-Modelle am Beispiel flexibler Ferti-gungssysteme’. Dissertation, Technische Universitat Munchen, 1997.
94
An Architecture for Adaptive Planning and Schedulingof Software Processes Using Timed Colored Petri Nets
By
N.C. Narendra and Indradeb P. PalSoftware Engineering Process Group (SEPG)
Hewlett-Packard India Software Operations Ltd.29 Cunningham RoadBangalore - 560 052
Email: {ncnaren,ipp}@india.hp.com
Abstract. One of the most vexing problems in managing software projects, is the need toappropriately plan and schedule them. Since software projects are process-oriented, this givesrise to the need for planning and scheduling the processes in a software project, so as to be ableto meet the project’s objectives within the time and cost constraints imposed on the softwareproject. To make matters worse, the parameters of a software project keep changing all thetime, requiring the project team to continuously adapt their processes and replan and rescheduletheir activities constantly.
In this paper, we present a Petri Net based formalism called TCPN or Timed Colored Petri Net,for modeling, planning and scheduling software processes. Our formalism is based on the sameformalism in [4], and we show how it can incorporate planning and scheduling algorithmsdeveloped outside the Petri Net community; in particular, planning algorithms from [8], andscheduling algorithms from [9]. We also show that it is an overall Planning and Schedulingarchitecture, and we also show how this can fit into an adaptive process framework such as theone described in [1]. Since the original formalism in [4] was developed for modeling generalworkflows, we show how it can be adapted to suit the multidimensional nature of softwareprojects.
1. Introduction
In any software project, planning and scheduling is one of the most critical problemsthat the project team could face. The reason for this, is that improper planning andscheduling will cause severe problems later in the software lifecycle, problems thatcould become impossible to fix. Hence proper planning and scheduling – andappropriate mechanisms for handling risks and unexpected deviations during thecourse of the project – is crucial for the project.
In this paper, we present a Petri Net based formalism called TCPN or Timed ColoredPetri Net, for modeling, planning and scheduling software processes. Our formalismis based on the Timed Colored Petri Net formalism of [4]. We show how itincorporates planning algorithms from [8], and scheduling algorithms from [9], i.e.,planning and scheduling algorithms from outside the Petri Net community. We also
95
show that it is an overall Planning and Scheduling architecture, and we also show howthis can fit into an adaptive process framework [1]. Since the original formalism in [4]was developed for modeling workflows in general, we show how it can be adapted tosuit the multidimensional nature of software projects.
This paper is organized as follows. We present some preliminary definitions in thenext section. In Section 3, our planning algorithm is presented. We show how – onceplanning is done - scheduling can be done, in Section 4. In Section 5, we demonstratehow our algorithm incorporates the adaptivity that is a crucial aspect of softwareprocesses. In Section 6, we present an example from a real-life project that illustratesour ideas. The paper concludes in Section 7 with suggestions for future work.
2. Preliminaries
Every software project is composed of the following basic entities:• Activities: These are the steps followed during the software project, and are
usually composed into two types of processes in the project:• Engineering processes: these are the "regular" processes implemented by the
project team in order to develop their deliverables• Support processes: these are the processes that are required to be executed by
the project team in coordination with central groups such as the SEPG, SQA,etc. Although these may not provide immediate benefit to the softwareproject, they are useful for providing project-level process performanceinformation to the central groups, which can in turn be used to improvefuture projects
• Artifacts: These are the internal and external deliverables produced by the projectteam.
• Agents: These are the roles played by different individuals in the project team,e.g., Project Manager, Technical Lead, Testing Engineer, etc.
• Resources: These are the software and hardware resources needed to execute theproject, e.g., software tools, special-purpose hardware, etc.
From the above definitions, it is clear that software development is truly a multi-dimensional activity, involving both engineering and support processes, and wherethe project team needs to balance among activities, artifacts, agents and resources.
Most software projects can be modeled as per a 3-tier architecture, thus:• The goals of the project and the organization to which it belongs, is the top tier.
These goals are usually business-driven, and can be mapped into goals forparticular software processes
• The middle tier typically models the usual lifecycles that the software projectsfollow, e.g., waterfall, V-model, spiral, etc.
• The lowest tier represents the actual processes defined and followed in theproject; it is an instantiation of the lifecycle that the project team has chosen, andwhich has been modeled in the middle tier
96
In [1], the first author has described a similar 3-tier architecture for general workflowprocesses, which finds application in software projects also. The corresponding layersfrom [1] are Planning, Schema and Process Layers, respectively.
We now present the Petri Net definitions. A Timed Colored Petri Net (TCPN) (seeFig. 1) is a five-tuple N = (P,T,I,O,TS) satisfying the following requirements:i) P is a finite set of placesii) T is a finite set of transitionsiii) I belonging to T is the set of input places for each transition, i.e, the pre-set
of Tiv) O belonging to T is the set of output places for each transition, i.e., the post-
set of Tv) TS is the time set, i.e., the set of execution times for each transition
(expressed as execution intervals)vi) Also, each place p in P has a set of allowed colors attached to it and this
means that a token residing in p must have a value which is an element ofthis set. In other words, the colors specify the different types associated witheach token. In the software project context, each token represents a resource(such as a human, or computer resource) which is consumed during atransition.
A marking M of the Petri Net represents the state of the Net, i.e., the distribution oftokens over places. Whenever a transition fires, the marking changes, since tokens getredistributed over the Net; hence a transition firing causes a state change in the PetriNet. A marking M" is said to be reachable from a marking M' if it possible to reachM" from M' by a sequence of transition firings.
Fig.1
io
Transitiont
Place p
97
A Petri net is said to be live if for every reachable state M' and every transition t, thereis a state M" reachable from M' which enables t.
A Petri net is said to be bounded or k-safe if and only if for each place p there is anatural number k such that for every reachable state the number of tokens in p is lessthan or equal to k . If k is 1, then the Petri net is said to be safe.
Paths connect nodes by a sequence of arcs. Hence a Petri net is strongly connected ifand only if for every pair of nodes (i.e., places and transitions) x and y, there is a pathleading from x to y.
A workflow net (see [6]) is a Petri Net with the following properties:• It has a unique sink place o (with no output transitions) and a unique source place
i (with no input transitions)• If we add a transition from o to i (hereafter referred to as the augmented workflow
net), then the resulting Petri net becomes strongly connected.
We call our TCPN representation well-defined if and only if it is live and bounded.Hereafter in this paper, we will be dealing only with well-defined TCPNs, due to thefollowing reasons:• We will see in later sections, that due to our planning and scheduling algorithms,
the TCPNs that will be generated, will have to be live• We will also see in later sections, that the constraints and invariants on the
activities and resources of the software project, will ensure that a finite bound canbe determined on the resources (and hence, tokens)
A Petri net that is live and bounded, is said to be sound. In [6], it has been provedthat workflow nets are sound.
Prop 1 : For our software domain, it is clear that our TCPN must be a workflow net.Proof:
• All software projects should have uniquely defined starting and ending points• The software processes should be defined so that the resulting augmented
workflow net is strongly connected, since there should be a path from any placeto any transition in the TCPN representation of the software project's processes
QED
Prop 2 : All well-defined TCPNs are sound.Proof:From Prop 1, it is clear that the TCPN is a workflow net. From Theorem 1 in [6], a
workflow net is sound if and only if its augmented workflow net is live and bounded.
From the above definitions, it is clear that the augmented workflow net for theTCPN is live and bounded, since the underlying TCPN representation is well-defined.
QED
98
A workflow net is said to be free-choice, if and only if the following holds:• For any two transitions, either their presets are identical or they do not have any
place in common
Although most workflow models are supposed to be free-choice [Aalst3, pg. 38],TCPNs representing software projects need not be. This is due to the fact that parallelexecution threads in a software project may still have dependencies on each other.Our example in Section 6 will illustrate this fact.
3. Planning Algorithm
3.1 Planning in Software Projects
The task of planning involves the following activities:• Determining the project requirements and goals – this will involve not only
product requirements, but also process requirements (such as, for example, thenumber of defects that need to be caught during reviews, the maximum numberof defects that can be tolerated in any lifecycle phase, or the productivity goalsfor specified project activities)
• Identifying the resources and staffing available for the project• Fixing the schedule of the project via negotiations with the customer• Identifying the major risks in the project [12]
Once these are identified, the planning process basically boils down to determiningthe project delivery lifecycle, and the different processes that should form part of thelifecycle. This will also involve sequencing the support activities that go along withthe lifecycle, such as the following:• Data collection and submission to the central Software Engineering Process
Group (SEPG), who will then do data collation and analysis• Planning Software Quality Assurance (SQA) activities, such as end-of-phase
previews/postmortems, audits, process reviews within the project, in consultationwith the central SQA group
• Participation by project team members in organization-wide processimprovement activities, in order to support the central SEPG in its activities
These activities should also be executed as per predefined processes, and they alsoneed to be sequenced along with the “regular” project activities.
Since planning is typically a complex and iterative activity involving makingchoices from among several alternatives, there is a need to encode the relativeusefulness of the different choices in terms of the impact that they will make on theoverall delivery lifecycle. It is usually convenient to represent these as predicates, inthe normal (either conjunctive or disjunctive) form that predicates are usuallyrepresented. These predicates are needed either as preconditions or postconditions of
99
activities. Preconditions specify the conditions necessary for an activity to beexecuted successfully, and postconditions specify the state of the project (from theperspective of that activity) once the activity is successfully executed.
Hence predicates can be specified for the project artifacts that are produced/usedduring any activity in the software project, and these predicates can be used to derivethe appropriate software processes for the project. Some examples are:• The review should catch at least a minimum number of errors; in other words, the
review should have been effective enough to weed out a sufficiently largenumber of problems in the artifact. Such metrics are typically derived fromorganization metrics data, and are assigned to the project team by the SeniorManagement, in the form of quantitative process goals
• There should have been sufficient participation in the review by the project team– in other words, the appropriate team members (decided by skill level,experience, etc.) should have participated in the review
Thus each of these predicates can also be encoded against each of the artifacts inthe project, and it will be the responsibility of the project team to ensure that they planthe project activities so that all these predicates are met.
3.2 Object-Centered Planning
From the description above, it becomes clear that the planning algorithm that weuse, should be “object-centered”. In other words, the predicates used in planningshould be oriented towards the objects in the projects (viz., agents, artifacts,resources, activities), which will greatly enhance planning efficiency [8].
Hence we have adapted the Object-Centered Planning (OCP) approach presentedin [8] for our purposes. The OCP approach consists of the following steps:• Initial domain description; here, the objects, the sorts (i.e., object classes) that
they belong to, the different states and substates that they can exist in for eachsort, are described and represented as predicates
• State transition diagrams are then described for each sort in the domain, whereeach node in the diagram represents a substate class - a disjoint set of substates
• State invariant construction - here, we consider the different ways in which thedifferent sorts can interact with other, and from this we can construct a set oflogical invariants for the model. Invariants are nothing but predicates that shouldalways hold during project execution. (more on this in Section 3.3).
• Operator specification; here, parametrized operators that model the effect ofactions are specified in terms of the they affect classes of substates
N.B: In the software domain, the operators are nothing but the activities performedby the project team, which can be represented as transitions in the TCPN formalism(this will be described in detail later in this section).
The OCP algorithm basically operates as follows [8]:
100
• It is a search through a space of partial plans. (The partial plans are nothing butthose derived from the project lifecycle model, from which the actual processescan be derived.) First an open node in the set of partial plans is retracted
• If the node does NOT meet the termination condition such that the substates ofthe node meets a goal condition (i.e., its postconditions as expressed in the formof predicates and invariants do not meet a goal condition), then we find thedifference between the objects' current states and their desired states
• An operator (or operator sequence) is then picked that reduces the difference• If the operator (or operator sequence) is applicable (i.e., its precondition is met),
then it is applied to the existing node; otherwise, the weakest precondition of aninstantiation of the operator (or operator sequence) is generated, and is used toopen a new node
• If the node DOES meet the termination condition, then the node's parent is thenopened, the algorithm is then applied on the parent
In the next section, we will describe how this algorithm can be mapped onto ourTCPN formalism.
3.3 Mapping OCP Onto the TCPN Formalism
As already described above, the OCP formulation easily maps onto the entities in asoftware project, due to the object-centered nature of OCP. The mapping is given inthe table below:
OCP Software Project
Sort = object class Resource class; this includes theclasses of the agents (i.e., peopleperforming certain roles in the softwareproject) and classes of the resources(i.e., hardware and software)
Objects Agents and ResourcesOperator Change of state as a result of an
activity executing – in our TCPNformalism, this represents the executionof a transition
Predicate The predicates can be used to definecertain conditions on the resources andhow they can be utilized in the project.Each predicate will represent either aprecondition or a postcondition on anactivity
These predicates are usually derived
101
from the collective experiences of pastprojects in the organization, and alsofrom historical metrics data which isusually stored in a database [3].
In our TCPN formalism, these aremodeled as places
Substate State of the TCPN at any given timeInvariants Invariants in the software project,
i.e., predicates that cannot be violatedthroughout the project execution – thiscould be items like resources, cost, etc.
Using this mapping, it becomes easy to map the OCP algorithm in our TCPNformalism, and obtain a TCPN representation of the software project plan.
The other major aspect of software project planning, and one that has not beenconsidered so far, is risk modeling. Risks are essentially negations of preconditions orpostconditions of certain activities in the project plan. Hence, in our TCPNrepresentation, we use the risk modeling method presented in [2] (which is adaptedfrom [12]), and we represent risk modeling as alternate paths in the TCPNrepresentation. In order to do so, we need to consider the following different aspectsof risk modeling:• the risk factor, i.e., the characteristic that affects the probability of a risk event
occurring• the risk event, which represents the occurrence of a negative incident - or a
discovery of information that reveals negative circumstances• the risk outcome , which describes the state of the project after the risk has
materialized• the risk consequences, which represents the state of the project after corrective
action has been taken• the risk effect, which represents the impact of the risk on the customer and the
project• the utility loss, which captures the severity of the loss to the project and to the
organization
Hence, we model risks in the following manner:• determine the risk factors, risk events, risk outcomes and risk consequences of
any activity• model the risk events as negations of preconditions of the activity• model the risk outcomes as negations of postconditions of the activity• model the risk consequences, risk effect and utility loss as alternative place-
transition sequences in the TCPN representation, in order to deal with the risk(this will be done at the appropriate places which are the pre-sets of the transitionrepresenting the activity in question)
102
4.0 Scheduling Algorithm
4.1 Introduction to Scheduling
Scheduling basically involves assigning tasks to resources. Typically, before onebegins the process of scheduling, the basic assumption is that an initial plan of theproject is in place, so that an initial schedule can be drawn up. Hence planning andscheduling inherently follow each other in an iterative fashion, until a satisfactoryplan and schedule is reached.
There are typically two basic scheduling approaches [9];• Profile-based approaches: these approaches typically consist of characterizing
resource demand as a function of time, and incrementally performing "levelingactions" to (hopefully) ensure that resource usage peaks fall below the totalcapacity of the resource
• Clique-based approaches: given a current schedule, this approach builds a"conflicts graph" whose nodes are activities and whose edges representoverlapping resource capacity requests of the connected activities. Fullyconnected subgraphs (cliques) are identified and if the number of nodes in theclique is greater than the resource capacity, then we have a conflict
In the context of Petri Nets, some work on Petri Net based scheduling has beendone in [4]. This technique uses a Timed Colored Petri Net formalism very similar toours. In order to represent scheduling, a reachability graph is generated. The nodes ofthis graph are the states in which a Petri Net can exist, and two nodes are connectedby a directed edge if one node is reachable from the other by a state change. Hence,reachability graphs can be used to generate feasible schedules. Since there is no timedelay for transitions in our TCPN formalism, all our schedules are eager schedules,i.e., schedules where resource assignment to tasks happens immediately. Hence, since[4] has shown that the reachability graph can generate all eager schedules, we can usethe reachability graph algorithm described therein. In Fig.2, below, we present anexample of a reachability graph.
Fig. 2
103
If we map the above concepts to the software domain, we see the following (someof these have already been observed by the authors from their own experiences):• Conflict detection and resolution are more important than mere resource leveling;
this is due to the fact that in software projects, a certain amount of "overloading"is tolerated and sometimes even necessary (due to the demanding, dynamic andsemi-chaotic nature of software development)
• Since historical data and past experience data is usually available with mostsoftware project teams, either in a database (see [3]) or can be deduced from thepast experiences of team members, there is always some level of initialscheduling that can be done by the project team
Hence, we select the clique-based approach, and assume that an initial scheduleexists. This schedule is prepared based on the plan derived in Section 3 using the OCPalgorithm. Let us assume that this is not consistent, i.e., that there are conflictingrequirements on resources.
The generic solver that we use, is based on the one described in [9], and a basicalgorithmic template is described briefly here. The template identifies three basicsteps that require instantiation:• Exists-Unresolvable-Conflict, which detects an unresolvable conflict,• Select-Conflict-Set, which identifies the set of activities included in the resource
conflict to be considered next, and• Select-Leveling-Constraint, which chooses a temporal ordering constraint to
solve the conflict by reducing (leveling) resource requirements in conflict.
Before we apply the generic solver to the clique-based approach that we havechosen here, we first describe what a clique is. A clique in a graph G(V,E) is acompletely connected subset C of V. The size of C is the number of vertices in C. Theclique in G with maximum size is called the maximum clique. For any vertex vi, thewe denote by Ji the set of vertices connected with vi.
Along with the clique information, we need to maintain two graphs for eachresource rj. The first graph is the Possible Intersection Graph (PIGj), whose verticesare the activities requiring rj and whose edges represent the fact that the executionintervals of its two vertices may overlap/intersect in the current solution. The secondgraph is the Definite Intersection Graph (DIGj), whose vertices are the activitiesrequiring rj and whose edges represent unresolvable conflicts as described in Exists-Unresolvable-Conflict . It is clear that DIGj is a subset of PIGj.
N.B: The "execution intervals" mentioned are nothing but the starting and endingtimes for each transition, i.e., the starting and ending times taken for activities in theproject, and these are in the time set TS defined in Section 2.
If the resource rj has capacity cj, then a clique of size at least cj + 1 in the graphPIGj is called a critical clique in G, and represents a potential resource conflict in thecurrent solution.
104
The algorithm for determining the cliques is as follows:• Input parameters are the following: a current clique C and a set of vertices I∆ used
to enlarge the current clique C as the search progresses• Given G = (V,E) the algorithm starts with C = Φ and I∆ = V; this corresponds to
the search level i = 0.• At any level i of the search tree, the set C is a clique with i vertices C = {v1, v2,
…, vi} and the set I∆ is obtained by the incremental intersection of V, J1, J2, …, Ji,where the Ji have been defined above.
• At each step of the algorithm, any of the following conditions hold:Ø The current clique C has size less or equal to cj, and it is not possible to
enlarge it over the threshold - in this case, the search ends in failureØ The set C U {vi} is a clique with size greater than cj, in which case the clique
with size cj + 1 is collected into the set of cliquesØ In any other case, the algorithm is recursively invoked on the parameters C
U {vi} and I∆-new to check for larger cliques.
The predicate Exists-Unresolvable-Conflict is realized by determining the minimalcritical sets, i.e, the minimal set of activities that may potentially conflict, using theDIGj. This is done for each resource rj. If no such minimal critical sets exist, then allthe conflicts are solvable.
The function Select-Conflict-Set is executed by implementing what [9] calls a"least commitment strategy". That is, the set of activities with the least temporalflexibility (i.e., a function of the degree to which the activities can be reciprocallyshifted in time) is selected. In other words, the less the temporal flexibility, the morecritical it is to resolve first.
The function Select-Leveling-Constraint simply chooses the appropriate levelingconstraint according to the least commitment strategy described above.
4.2 Mapping onto the TCPN Formalism
We now map the scheduling algorithm described above, to our TCPN formalism.
Recall that we have seen that we can use the reachability graph to generate alleager schedules. Hence, each path in the reachability graph from the root to any leafnode represents a possible schedule. The question that we need to answer therefore,is, how to generate the next state from any node in the tree? Since the reachabilitygraph could potentially become infinitely large, the other question to answer is, howto limit the combinatorial explosion?
This is where the scheduling algorithm described in Section 4.1 can be used. Theconstraints and possible resource conflicts detected during the course of executingthat algorithm will limit the number of reachable states from any node in thereachability graph. Hence, the scheduling algorithm of Section 4.1 can be run at every
105
node in the reachability graph, and the next set of reachable states can be derived bynot considering those states resulting in conflicts.
5.0 Handling Adaptivity in Software Projects
The previous sections of our paper described our TCPN formalism and showed how ageneral planning and a general scheduling algorithm can be mapped onto ourformalism. However, software projects are highly adaptive and semi-chaotic, henceany planning and scheduling architecture for software projects needs to incorporateadaptivity into it.
In [1], we have shown three levels of adaptivity in the workflow context (inincreasing order of impact on the software organization), which are also applicable tosoftware projects:Ø Adaptivity at process level, i.e., changing certain processes in order to improve
project executionØ Adaptivity at lifecycle level, i.e., changing the very delivery lifecycle in order to
make substantial changes in the way the software product is developedØ Adaptivity at goal level, i.e., changes in goals resulting in complete re-
engineering and re-orientation of the software projects themselves
It stands to reason that adaptivity can be handled efficiently by focussing only onincremental replanning and rescheduling, i.e., only for those portions of the softwareprocesses that are actually affected by the change. Hence, our approach to incrementalreplanning and rescheduling is as follows:• If the change involves changes in the constraints on the activities, then replanning
needs to be looked into first. We first need to determine at what point in thelifecycle the change will begin to affect; we call this the "starting stage". Forexample, a change in the project requirements may necessitate repeating thedesign step, or may affect only the coding step. Another example, would be achange in the quality requirements, that may impact only the testing activity,resulting in (perhaps) a minor change to the test plan.
The next step is to propagate the changed constraints downstream from thestarting stage, and determine how much of the rest of the lifecycle is affected bythe change. The last activity that is affected by the change, is called the "endingstage".
In such a situation, we need to rerun the OCP algorithm from the starting stageto the ending stage, with the constraints at the starting stage being the startconstraints, and the constraints at the ending stage being the goal conditions ofthe OCP algorithm.
• If the change does not involve changes in constraints on activities, or if the abovestep results in changes in constraints on resources, then the scheduling algorithmdescribed in Section 4 needs to be invoked on the portion of the Petri Net that is
106
between the starting and ending stages. Again, this results in redeveloping thereachability graph between the highest node (in the reachability graph)corresponding to the starting stage, and the lowest node (in the reachabilitygraph) corresponding to the ending stage, as per the algorithm in Section 4.
• The above two steps need to be iterated until a feasible solution is found.
In software projects, the other aspect of adaptivity, is the need to suitably "change-proof" the software lifecycle model, so that future changes to the project areanticipated and taken into account. This can be done using the risk modeling approachdescribed in Section 3.3. As is common in most software organizations, all the mostcommon types of possible risks can be modeled in a risk database (similar to the onedescribed in [3]) and can be used to suitably build in risk management while planningand scheduling. Hopefully, this will minimize replanning and rescheduling.
6.0 An Example - Introduction
The example that we have chosen, is simple enough to be used in this paper as anillustration, but it is also derived from a real-life software project in our organizationthat exhibited all the characteristics that make software project planning andscheduling a complex and demanding activity.
The project, which we will call ABC, is essentially to develop a set of modules thatwill emulate the behavior of one operating system on another one. The ABC projectpossesses the following characteristics:• The requirements are not clearly defined by the customers, who are themselves
not very sure of what is to be expected; hence the project team needs to makeassumptions which could be invalidated at any time by the customers
• Like any typical software project, ABC’s schedule is quite tight. However,resources are more flexible, since project team members have offered to workovertime if necessary to get the job done, especially since this project isconsidered to be crucial to the long-term success of the organization.
The project’s lifecycle can be evolutionary, consisting of several basic three-phasewaterfall models comprising design, coding and testing. Hence the project consists ofdesign-coding-testing cycles executed one after another. Of course, this is done permodule, hence the project lifecycle will be a set of design-coding-testing cyclesexecuted both sequentially and in parallel. Needless to say, since all the modules aresupposed to interact with each other, there will also be dependencies/interactionsamong the 3-phase cycles corresponding to the modules. A representation of theproject, for two parallel but interdependent modules, and for one cycle in the overallevolutionary lifecycle, is given in Fig.3 below. Please note the two arrows originatingfrom transitions in Module #2 and ending in places in Module #1 - they depict thedependencies/interactions among the two 3-phase cycles.
107
Fig.3
i
o
design
coding
testing
Module#1
Module#2
Release readiness review
108
6.1 Planning Algorithm Implementation
The first step in planning the ABC project, is to identify the following, as per theOCP algorithm:• Object Classes: The object classes for our example, are the followingØ Project ManagerØ EngineerØ Project Quality Interface (he/she is the individual who interfaces with the
central SEPG and SQA groups, and helps the PM in coordinating the SEPGand SQA functions in the project team)
• Objects: The objects in the ABC project, are the Project Manager (PM) and the 4engineers
• Invariants: There are certain invariants on the activities in the ABC project.Some of them are:Ø All the activities in any 3-phase cycle will have to be executed sequentiallyØ Certain dependency invariants exist between modules, which are depicted as
constraints. For example, Module #1 cannot be completed until the interfaceof Module #2 is completed, since Module #2 needs to interact with Module#1 using the interface
Ø We can (and in fact, we should) also have invariants derived from historicaldata from past projects in a historical database [3]; this helps during planningand scheduling, since it minimizes the combinatorial explosion
• Operators: These are essentially the activities executed by the project team,which changes the substates of each of the artifacts in the project
• Predicates: Predicates are used to denote preconditions and postconditions of anactivity. For example, for a coding activity for a module in any 3-phase cycle tostart, the following could be the preconditions:Ø The design should have been completed, reviewed and baselinedØ The module's interface dependencies with all other modules are also part of
the design which has been reviewed and baselined
The postconditions could be the following:Ø The code has been reviewed and baselinedØ The code is consistent with the design at the time of coding
• Substates: The substate of the project at any given time, is the substate of itsencoded TCPN representation
Basically, the planning algorithm can be implemented as explained in Section 3.2.We start with the design activity in any module (which is an object in our adaptedOCP algorithm), and check the extent to which it meets the goal conditions. We notethe difference between the goal conditions and the current state of the module, and
109
select an operator (or operator sequence) that reduces the difference. In this case,there could be several operators to choose from (i.e., one or all of the following):• Coding the module• Developing the interface to the other modules in the system• Leaving this module as it is, and designing and/or coding any other module
In case no operator is applicable, we choose the one that generates the weakestprecondition (i.e., the operator that violates the predicates the least) and it is used toopen a new node in our search space.
So far, we have not mentioned risk management in this planning exercise. Somepossible risks to this project are:• Sudden changes in customer requirements• Attrition• Lack of understanding of the domain, which could render the planning estimates
useless
These risks are modeled using the modified Riskit methodology described inSection 3.3. This can be done by adding alternate paths in the completed TCPN afterthe planning algorithm is implemented.
6.2 Scheduling Algorithm Implementation
As explained in Section 4.1, we assume that a preliminary schedule exists, and weselect the clique-based approach. The search procedure is essentially the onedescribed in [4], and involves generation of the reachability graph. The PossibleIntersection Graphs (PIG) and Definite Intersection Graphs (DIG) are used in order tocurtail the size of the reachability graph, as described in Section 4.1.
6.3 Handling Adaptivity
6.3.1 Replanning
Due to the evolutionary nature of the ABC project, it is clear that change is a constantin this project. Since software development is a multi-dimensional activity, thefollowing are some of the changes encountered by the team:• The customer reorders the priority of certain modules in the system, thus forcing
the project team to replan and reschedule from where they were before thereordering
• One of the team members falls ill and is absent for a week, forcing others tomake up for this loss. This may not cause a replanning per se, but causes arescheduling of activities among the existing team members, which in turn resultsin replanning the activities that the sick team member is supposed to accomplish
110
• The organizational SQA group announces an unscheduled audit, due to adirective from senior management; this results in significant replanning andrescheduling, since even the 10% overtime is not sufficient for the audit
We will illustrate the first change, i.e., customer reordering, only. In this case, theOCP algorithm must be re-implemented from the stage when the change was ordered.There are essentially three cases here:• Completed activities: since these activities have already been completed, the
postconditions of these activities can be used as preconditions for future activitiesthat will be planned
• Activities yet to be started: these will be invalidated by the reordered priorities,since they should be replanned afresh
• Activities in progress: the fate of these activities has to be decided after thereplanning is done. If these activities are to be executed (i.e., if the operatorsequence contains these activities), then the project team can simply continuewhere they left off and complete these activities. Otherwise, the activities willhave to be scrapped in favor of the new set of activities.
6.3.2 ReschedulingIn the case of rescheduling, the reachability graph needs to be modified from the
"starting stage" to the "ending stage", as explained in Section 5. This will also involvemodifying the PIGs and DIGs for those resource that are affected. Once again, thereare three cases:• Resources that are not needed between the "starting" and "ending stages" ; the
constraints on the state of the reachability graph at the "starting stage" for theseresources remain unchanged
• Resources that are yet to be used : these will be invalidated by the change, andwill have to rescheduled afresh
• Resources that are in the process of being used: here, the extent to which theseresources have to be reassigned, will depend on the extent of the schedulingchange. Some of the activities being executed by these resources may need to bemodified - this may in turn trigger a replanning, depending on the effect it willhave on the currently running set of activities (i.e., operator sequence asmentioned in Section 6.3.1).
7.0 Conclusions and Future Work
In this paper, we presented a Timed Colored Petri Net (TCPN) formalism forrepresenting processes in software projects. We also showed how planning andscheduling algorithms from outside the Petri Net community can be incorporated intoour formalism, thereby enhancing the power and usefulness of our formalism. Wehave also shown how this can also serve as an Adaptive Planning and Schedulingarchitecture, by aligning it with an adaptive process framework from [1]. We havealso illustrated the algorithms with a real-life example from a software project.Although this paper has not described the TCPN formalism itself in any detail, we
111
believe that our major contribution is that we have shown how planning andscheduling algorithms from outside the Petri Net or Software EngineeringCommunity can be used to plan and schedule software processes using Petri Nets.
Our paper brings up several avenues for future work:• Efficient implementation of our idea, and experimentation with several real-life
examples• A more mathematically rigorous characterization of software processes,
including deriving properties similar to those derived in [5] for workflow nets.Also, since Petri Nets are most suited for performance modeling, another openissue is how to appropriately model and analyze the performance of softwareprocesses, perhaps using stochastic models [14].
• Modeling of our TCPN formalism in a distributed environment, andimplementation thereof; that is, distributing portions of the TCPN and itsassociated planning and scheduling algorithms among different servers, and thecoordination issues resulting therein. Also, how can our ideas be embedded intoan agent-based environment such as the one described in [13], where the TCPNfor each agent (which will describe the agent's execution methodology) candynamically adapt to changed circumstances. This also brings up the issue ofimplementing adaptive planning and scheduling (as in Section 5) amongdistributed servers. A beginning has been made in [11], but more remains to bedone.
8.0 Acknowledgments
The authors wish to acknowledge Akshya Prakash, Padma Ravichander and V.S.Subrahmanyam for supporting their work.
References
[1] N.C. Narendra, “Adaptive Workflow Management – An Integrated Approachand System Architecture,” ACM Symposium on Applied Computing 2000, to appear
[2] N.C. Narendra, “Goal-based and Risk-based Creation of Adaptive WorkflowProcesses,” American Association for Artificial Intelligence (AAAI) SpringSymposium 2000, to appear
[3] Rajesh Bhave and N.C. Narendra “An Innovative Strategy for OrganizationalLearning,” World Congress on Total Quality (WCTQ) 2000
[4] W.M.P. van der Aalst, "Petri Net Based Scheduling," Computing ScienceReports 95/23, Eindhoven University of Technology, Eindhoven, 1995, also availablefrom http://wwwis.win.tue.nl/~wsinwa/orspec.ps
[5] W.M.P. van der Aalst, "How to Capture Dynamic Change and ManagementInformation? An Approach Based on Generic Workflow Models," Technical Report,UGA-CS-TR-99-01, University of Georgia, Department of Computer Science,Athens, USA, 1999, also available from http://wwwis.win.tue.nl/~wsinwa/genwf.ps
112
[6] W.M.P. van der Aalst, "Petri-net-based Workflow Management Software", InA. Sheth, editor, Proceedings of the NFS Workshop on Workflow and ProcessAutomation in Information Systems, pages 114--118, Athens, Georgia, May 1996.
[7] Ellis, C., Keddara, K., and Wainer, J., "Modeling Workflow Dynamic ChangeUsing Timed Hybrid Flow Nets", Proceedings of the Petri Net Workshop onWorkflow Management: Net Based Concepts, Models, Techniques and Tools, June1998.
[8] D.E. Kitchin and T.L. McCluskey, "Object-Centered Planning," 15thWorkshop of the UK Planning and Scheduling Special Interest Group, Liverpool JohnMoores University, Liverpool 1996; available fromftp://helios.hud.ac.uk/pub/artform/sig_96.ps
[9] A. Cesta, A. Oddi and S.F. Smith, "Scheduling Multi-Capacitated Resourcesunder Complex Temporal Constraints," Technical Report CMU-RI-TR-98-17,Robotics Institute, Carnegie-Mellon University, 1998; available fromhttp://www.cs.cmu.edu/afs/cs/project/ozone/www/PCP/publications/cl-pro-techrpt.html
[10] C. Cheng and S.F. Smith, "Generating Feasible Schedules under ComplexConstraints," in Proceedings of 12th National Conference on AI (AAAI-94), 1994.
[11] T. Bauer and P. Dadam, "Efficient Distributed Control of Enterprise-Wide andCross-Enterprise Workflows," Proceedings Workshop Enterprise-wide and Cross-enterprise Workflow Management: Concepts, Systems, Applications, 29.Jahrestagung der GI (Informatik '99), S. 25 - 32, 1999; available fromhttp://www.informatik.uni-ulm.de/dbis/papers/1999/BaDa99a.pdf
[12] J. Kontio, D. Getto and D. Landes, "Experiences in improving riskmanagement processes using the concepts of the Riskit method," available fromhttp://mordor.cs.hut.fi/~jkontio/fse6-rm.pdf
[13] Q. Chen, P. Chundi, U. Dayal and M. Hsu, "Dynamic Agents", InternationalJournal of Cooperative Information Systems, 1998
[14] M. Silva and J. Campos, "Structural Performance Analysis of Stochastic PetriNets," In Procs. IEEE Intern. Computer Performance and Dependability Symp., pp.61-70, Erlangen, Germany, April 1995; available fromhttp://www.cps.unizar.es/~jcampos/
113
114
Towards Modelling and Veri�cation of
Concurrent Ada Programs
Using Petri Nets
A. Burns1, A.J. Wellings1, F. Burns2, A.M. Koelmans2
, M. Koutny2, A. Romanovsky2, and A. Yakovlev2
1 Real-Time Systems Research Group
Department of Computer Science
University of York, U.K.2 Asynchronous Systems Laboratory
Department of Computing Science
University of Newcastle upon Tyne, U.K.
Abstract. Ada 95 is an expressive concurrent programming language
with which it is possible to build complex multi-tasking applications.
Much of the complexity of these applications stems from the interactions
between the tasks. This paper argues that Petri nets o�er a promising,
tool-supported, technique for checking the logical correctness of the task-
ing algorithms. The paper illustrates the e�ectiveness of this approach
by showing the correctness of an Ada implementation of the atomic ac-
tion protocol using a variety of Petri net tools, including PED, PEP and
INA for P/T nets and Design/CPN for Coloured Petri nets.
1 Introduction
As high-integrity systems become more sophisticated, the resulting complexityis easier to manage if the applications are represented as concurrent processesrather than sequential ones. Inevitably, the introduction of concurrency bringsproblems of process interaction and coordination. In trying to solve these prob-lems, language and operating system researchers have introduced new high-levelprogramming constructs. These design abstractions are often closely related tothe speci�c domain being addressed. For example, in the world of software fault-tolerance, the notion of conversations [24] and atomic actions [11, 19] are in-troduced to facilitate the safe and reliable communication between a group ofprocesses in the presence of hardware and software failures, in addition to pro-viding a structuring technique for such systems. Research languages such asConcurrent Pascal have been used as the basis for experimentation [18], or a setof procedural extensions or object extensions have been produced. For exam-ple, Arjuna uses the latter approach to provide a transaction-based toolkit forC++ [29]. However, it is now accepted that the procedural and object exten-sions are unable to cope with all the subtleties involved in synchronisation andco-operation between several communicating concurrent processes.
115
The main disadvantage of domain-speci�c abstractions is that they seldommake the transition into general-purpose programming languages or operatingsystems. For example, no mainstream language or operating systems supportsthe notion of a conversation [9]. The result is that all the hard-earned researchexperience is not promulgated into industrial use.
If high-level support is not going to be found in mainstream languages,the required functionality must be programmed with lower-level primitives thatare available. For some years now we have been exploring the use of the Adaprogramming language as a vehicle for implementing reliable concurrent sys-tems [32]. The Ada 95 programming language de�nes a number of expressiveconcurrency features [1]. Used together they represent a powerful toolkit forbuilding higher-level protocols/design abstractions that have wide application.For example, [32] recently showed how Ada 95 can be used to implement AtomicActions. And, as such an abstraction is not directly available in any current pro-gramming language, this represents a signi�cant step in moving these notionsinto general use. An examination of this, and other applications, shows that anumber of language features are used in tandem to achieve the required result.Features include:
{ Tasks - basic unit of concurrency.{ Asynchronous Transfer of Control (ATC) - an asynchronous means of a�ect-ing the behaviour of other tasks.
{ Protected Types - abstract data types whose operations are executed inmutual exclusion, and which supports condition synchronisation.
{ Requeue - a synchronisation primitive that allows a guarded command tobe prematurely terminated with the calling task placed on another guardedoperation.
{ Exceptions - a means of abandoning the execution of a sequential programsegment.
{ Controlled types - a feature that allows manipulation of object initialisation,�nalisation and assignment.
The expressive power of the Ada 95 concurrency features is therefore clear.What is not as straightforward is how to be con�dent that the higher-levelabstractions produced are indeed correct. As a number of interactions are asyn-chronous this presents a signi�cant veri�cation problem. The idea of veri�cationusing Model Checking with a �nite state model (FSM) of an Ada program was�rst presented in [10]. This method constructed a set of FSMs of individualtasks interacting via channels, and applied analysis of the interleaving seman-tics of the product of FSMs using the software tool Uppaal. In this paper, weinvestigate a complementary approach based on Petri nets and their power tomodel causality between elementary events or actions directly. This can be ad-vantageous for asynchronous nature of interactions between tasks. Petri nets,both ordinary [26] and high level (e.g. coloured nets [17]) o�er a wide range ofanalysis tools to model and verify the logical correctness according to two cru-cial kinds of properties: (i) safety - an incorrect state cannot be entered (from
116
any legal initial state of the system); and (ii) liveness - a desirable state will beentered (from all legal initial states of the system).
Petri nets have generally been applied to the veri�cation of Ada programs,e.g. [28, 23, 8]. This work has mostly been focused on the syntactic extractionof Petri nets from Ada code in such a way that the veri�cation of properties,such as deadlock detection, could be done more eÆciently. To alleviate statespace explosion techniques like structural reduction [28] and decomposition [23]of `Ada nets' have been proposed.
Our research is based on applying Petri nets to model concurrent Ada code,and using Petri nets tools, such as PEP and Design/CPN, to verify its correct-ness. However, we propose to deal with the unavoidable complexity of the result-ing programs within a compositional approach employing a versatile library ofdesign abstractions with well understood and formally veri�ed properties. Con-�dence in the abstraction can be signi�cantly increased and the developmentactivity itself supported by modelling, simulation and analysis of the dynamicbehaviour of the Petri net model; the behaviour can be analysed either by ex-ploring the set of reachable states of the net or its partial order semantics, suchas the unfolding pre�x. This library can then be used to tackle the veri�cationof complex designs. Thus, while we are ultimately interested in eÆcient modelchecking too, the main focus of this paper is on the semantic modelling of salienttask interaction mechanisms from Ada 95. To the best of our knowledge, therehas been no attempt of using Petri nets to analyse Ada 95 models of Atomic Ac-tions, particularly with ATC and exceptions. However, some work on analysingAda 95 programs (with ATC, protected objects, and requeue statement) withPetri nets has been recently reported in [15].
This paper is organised as follows. An introduction to model checking basedon Petri nets is given in the next section. We use our existing study of AtomicActions to illustrate the adopted procedure. A simple model is introduced inSection 3 and its re�nement in Section 4. Conclusions are presented in Section 5.
2 Model Checking using Petri Nets
Model checking is a technique in which the veri�cation of a system is carried outusing a �nite representation of its state space. Basic properties, such as absenceof deadlock or satisfaction of a state invariant (e.g. mutual exclusion), can beveri�ed by checking individual states. More subtle properties, such as guaranteeof progress, require checking for speci�c cycles in a graph representing the statesand possible transitions between them. Properties to be checked are typicallydescribed by formulae in a branching time or linear time temporal logic [13].
The main drawback of model checking is that it su�ers from the combina-torial explosion problem. That is, even a relatively small system speci�cationmay, and often does, yield a very large state space which despite being �nite re-quires computational power for its management beyond the e�ective capabilityof available computers. To help cope with the state explosion problem a num-ber of techniques have been proposed which can roughly be classi�ed as aiming
117
at implicit compact representation of the full state space of a reactive concur-rent system, or at an explicit representation of a reduced, yet suÆcient, statespace of the system. Examples of the former are algorithms based on the bi-nary decision diagrams (BDDs) [7]. Techniques aimed at reduced representationof state spaces are typically based on the independence of some actions, whichis a characteristic feature of reactive concurrent systems, often relying on thepartial order view of concurrent computation. Brie y, in a sequential system,it is the actual order of the execution of individual actions which is usually ofimportance, whereas in a concurrent system the actual order in which, say, twomessages were sent and then received may be irrelevant to the correctness of thewhole system. Examples include partial order veri�cation [16, 21] and stubbornset method [31]. The partial order view of concurrent computation is also thebasis of the algorithms employing McMillan's unfoldings [14], where the entirestate space is represented implicitly using an acyclic directed graph representingsystem's actions and local states.
Model checking is a technique that requires tool support. For Petri nets,there are many tools of di�erent maturity available. These tools are categorisedaccording to many parameters [33]. In our study, we used three relatively ma-ture tools. One is PEP [2, 3], which uses ordinary Place/Transition nets and anumber of model checking methods, such as reachability analysis and unfold-ing pre�x. The second one is INA (Integrated Net Analyzer) [27]. The third isDesign/CPN [34], which is based on the Coloured Petri nets and has extensivefacilities for simulation and occurrence (reachbility) graph analysis.
2.1 The PEP Tool
The PEP tool [2, 3, 22] provides a modelling and veri�cation environment basedon Petri nets, however, its principal method of inputting large designs is to use asimple concurrent programming language. The tool compiles a program into aninternal representation in terms of a 1-safe Petri net which can then be veri�edfor correctness using a variety of techniques, including ones supported by othermodel checking tools, such as SPIN or SMV. The relevant correctness properties,can be speci�ed in a general-purpose logic notation, such as CTL* or S4. ThePEP system incorporates model checkers based on unfolding and structural nettheory.
The PEP tool's additional advantage is that it is based on a compositionalPetri net model, both P/T-net based and high-level net based [4{6]. It thereforeprovides a sound ground to develop a compositional model supporting designabstractions.
2.2 The INA Tool
The INA tool is an interactive analysis tool which incorporates a large numberof powerful methods for analysis of P/T nets. These methods include analysis of:(i) structural properties, such as state-machine decomposability, deadlock-trapanalysis, T- and P-invariant analysis, structural boundedness ; (ii) behavioural
118
properties, such as boundedness, safeness, liveness, deadlock-freeness, dynamiccon ict-freenes; (iii) speci�c user-de�ned properties, such as those de�ned bypredicates and CTL formulas and traces to pre-de�ned states. These analysesemploy various techniques, such as linear-algebraic methods (for invariants),reachability and coverability graph traversals, reduced reachability graph basedon stubborn sets and symmetries.
The INA tool uses a combination of interactive techniques, where the user isprompted for various speci�cations and queries, and �le-processing techniques.The basic Petri net �le format is compatible with other tools, such as PED andPEP, using Petri net graphical editors.
2.3 The Design/CPN Tool
Coloured Petri Nets (CP-nets) are an extension of the basic Petri Net model [17].A CP-net model consists of a collection of places, transitions, and arcs betweenthese places and transitions. The model contains tokens that ow around themodel and are stored in the places. The essential feature of CP-nets is thatthey allow complex data types, i.e. objects, to be attached to the tokens. Theseobjects contain attributes re ecting the system being modelled. The ow ofthe tokens is determined by so called guards, which are conditions, attached tothe arcs of the model, that determine whether a transition is allowed to �re.These guards therefore determine the dynamic behaviour of the model; theyallow sophisticated behavioural properties to be modelled. The only software toolcurrently capable of simulating and analysing CP-Net models and generating anexecutable code (in the ML programming language) is Design/CPN [34]. In theDesign/CPN system, guards are speci�ed in ML. Crucially, Design/CPN allowsentry of hierarchical models, which greatly aids in the understanding of complexmodels.
3 Model of Simple Atomic Actions
3.1 Atomic Actions
An atomic action is a dynamic mechanism for controlling the joint execution ofa group of tasks such that their combined operation appears as an indivisible
actions [19, 25]. Essentially, an action is atomic if the tasks performing it candetect no state change except those performed by themselves, and if they do notreveal their state changes until the action is complete. Atomic actions can beextended to include forward or backward error recovery. In this paper we will fo-cus only on forward error recovery using exception handling [11]. If an exceptionoccurs in one of the tasks active in an atomic action then that exception is raisedin all processes active in the action. The exception is said to be asynchronousas it originates from another process.
119
3.2 Atomic Actions in Ada
To show how atomic actions can be programmed in Ada [32], consider a simplenon-nested action between, say, three tasks. The action is encapsulated in apackage with three visible procedures, each of which is called by the appropriatetask. It is assumed that no tasks are aborted and that there are no desertertasks [18].
package simple_action is
procedure T1(params : param); -- from Task 1
procedure T2(params : param); -- from Task 2
procedure T3(params : param); -- from Task 3
end simple_action;
The body of the package automatically provides a well-de�ned boundary,so all that is required is to provide the indivisibility. A protected object, Con-troller, can be used for this purpose. The package's visible procedures call theappropriate entries and procedures in the protected object.
The body of the package is given below.
with Ada.Exceptions; use Ada.Exceptions;
package body action is
type Vote_T is (Commit, Aborted);
protected controller is
entry Wait_Abort(E: out Exception_Id);
entry Done;
entry Cleanup (Vote : Vote_t; Result : out Vote_t);
procedure Signal_Abort(E: Exception_Id);
private
entry Wait_Cleanup(Vote : Vote_t; Result : out Vote_t);
Killed : boolean := False;
Releasing_cleanup : Boolean := False;
Releasing_Done : Boolean := False;
Reason : Exception_Id;
Final_Result : Vote_t := Commit;
informed : integer := 0;
end controller;
-- any local protected objects for communication between actions
protected body controller is
entry Wait_Abort(E: out Exception_id) when killed is
begin
E := Reason;
informed := informed + 1;
if informed = 3 then
Killed := False;
120
informed := 0;
end if;
end Wait_Abort;
entry Done when Done'Count = 3 or Releasing_Done is
begin
if Done'Count > 0 then
Releasing_Done := True;
else
Releasing_Done := False;
end if;
end done;
entry Cleanup (Vote: Vote_t;
Result: out Vote_t) when True is
begin
if Vote = Aborted then
Final_result := Aborted;
end if;
requeue Wait_Cleanup with abort;
end Cleanup;
procedure Signal_Abort(E: Exception_id) is
begin
killed := True;
reason := E;
end Signal_Abort;
entry Wait_Cleanup (Vote : Vote_t; Result: out Vote_t)
when Wait_Cleanup'Count = 3 or Releasing_Cleanup is
begin
Result := Final_Result;
if Wait_Cleanup'Count > 0 then
Releasing_Cleanup := True;
else
Releasing_Cleanup := False;
Final_Result := Commit;
end if;
end Wait_Cleanup;
end controller;
procedure T1(params: param) is
X : Exception_ID;
Decision : Vote_t;
begin
select
Controller.Wait_Abort(X);
raise_exception(X);
then abort
begin
121
-- code to implement atomic action
Controller.Done; --signal completion
exception
when E: others =>
Controller.Signal_Abort (Exception_Identity(E));
end;
end select;
exception
-- if any exception is raised during
-- the action all tasks must participate in the recovery
when E: others =>
-- Exception_Identity(E) has been raised in all tasks
-- handle exception
if handled_ok then
Controller.Cleanup(Commit, Decision);
else
Controller.Cleanup(Aborted, Decision);
end if;
if Decision = Aborted then
raise atomic_action_failure;
end if;
end T1;
procedure T2(params : param) is ...;
procedure T3(params : param) is ...;
end action;
Each component of the action (T1, T2, and T3) has identical structure. Thecomponent executes a select statement with an abortable part. The triggeringevent is signalled by the controller protected object if any component indicatesthat an exception has been raised and not handled locally in one of the com-ponents. The abortable part contains the actual code of the component. If thiscode executes without incident, the controller is informed that this componentis ready to commit the action.
If any exceptions are raised during the abortable part, the controller is in-formed and the identity of the exception passed.
If the controller has received noti�cation of an unhandled exception, it re-leases all tasks waiting on theWait Abort triggering event (any task late in arriv-ing will receive the event immediately it tries to enter into its select statement).The tasks have their abortable parts aborted (if started), and the exception israised in each task by the statement after the entry call to the controller. If theexception is successfully handled by the component, the task indicates that it isprepared to commit the action. If not, then it indicates that the action must beaborted. If any task indicates that the action is to be aborted, then all tasks will
122
raise the exception Atomic Action Failure. Figure 1 shows the approach using asimply state transition diagram.
Executing andwaiting for an abort
Signal abortAction component
doneAbort triggered andRaising an exception
Exception handled
Waiting cleanup
Enter Action
Exit Action Failed Exit Action Normally
Fig. 1. Simple state transition diagram illustrating Atomic Action with forward error
recovery for the system with two tasks
3.3 Modelling the Ada Implementation in P/T nets
We now consider Petri nets for this Ada code. For the sake of simplicity, weconsider only two tasks here. We �rst look at ordinary P/T nets, i.e. nets withouttoken typing. Each of the client tasks will have an identical PN, specialised onlyin its labelling of transitions and places. The controller will also be modelledas a single Petri net. Graphical capturing of Petri nets is done using Petri neteditor PED [20], which allows hierarchical and fragmented construction of P/Tnets, and export to an extensive range of formats including those accepted byanalysis tools such as PEP and INA. Figure 2 presents the task model (a) andthe controller model (b).
Places and transitions which are not shaded, such as start1 and arr1 areindividual for the task net (we show the net for Task 1). Those places andtransitions which are shaded are so called logical places and transitions { theyare used to interconnect subnets to form larger nets. In other words, by declaringplaces or transitions in di�erent subnets as logical, we virtually merge such placesand transitions in the overall net provided that they have the same label, e.g.waitAbort and sigAbort1. Note that the net models use test or read-only arcs,
123
commitAlldoneAll
abortAll
restart12
sendAbComm1
restart11
sendComm1sendAbort1
except12
sigAbort1
except11done1
arr1
voteAbort
voteNotAbort
noIntTasks
Killed
notKilled
waitAbort
fail1success1
voted1
handling1
locDone1
comp1
start1
2
2
sigAbort2sigAbort1
doneAll
abortAll
commitAll
sync
voteAbort
voteNotAbort
start
synced
noIntTasks
Killed
notKilled
waitAbort
Fig. 2. P/T net models: (a) Task model (b) Controller model
which are represented graphically by arcs with a black dot at the transition end,and weighted arcs. The former are used to show the fact that transitions in thetask net can test the state of shared variable, such as Killed , which is modelledby two complementary places notKilled and Killed in the controller net.
Our basic idea of modelling the Ada code for the Atomic Action behaviourwith P/T nets is as follows. We represent states of each task as unshaded placesand key actions local to the task as unshaded transitions. Arriving in the AtomicAction by the task is represented by transition arr1. This also generates a tokenin the place waitAbort, which belongs to the controller and counts the number oftasks that have actually entered the Atomic Action. The place labelled comp1
corresponds to the state of the task in which the task performs normal compu-tation. From this state the task may either: (a) execute transition done1 and goto the Local Done state of normal completion of the action (place locDone1),or (b) it may raise an exception by �ring transition sigAbort1 (this correspondsto executing the Signal Abort procedure, which switches the state of the Killed ag from false to true { a token is toggled from place notKilled to Killed), or(c) it may be forced to go to the Error-Handling state (place handling1), eitherfrom the Normal Computation state or from the the Local Done state becauseof some tasks (including itself) has raised an exception, in which case transitionexcept12 will be �red.
Subsequent action of the task depends on whether the task ends in the LocalDone or in the Error-Handling state. If the former, the task provides a condi-tion for the controller to �re a shared transition doneAll (corresponding to the
124
execution of the Done entry by all tasks). If the task is in the Error-Handlingstate, it handles the exception, and, depending on the result of the handling,votes either for Action Commit or Action Abort.
The voting mechanism used in Atomic Actions allows one task voting forAbort to force the entire operation into Failure. In our Petri net model, this isachieved by using three transitions sendAbort1, sendComm1 or sendAbComm1,individual to the task. These transitions are connected to two complementaryplaces voteNotAbort and voteAbort in the controller net. Initially, when the vot-ing begins, a token is assumed to be placed into place voteNotAbort. While noneof the tasks vote for Abort, the token remains in this place, and if the task votesfor Commit, which corresponds to the handling ok ag being set in the task,transition sendComm1 �res due to the reading arc from place voteNotAbort. Assoon as one of the tasks votes for Abort, transition sendAbort1 is �red, which tog-gles the token from voteNotAbort to voteAbort in the controller. This correspondsto assigning the state of the global ag Final result to aborted in the Cleanup
entry. After that, in all tasks, regardless of their individual voting, transitionsendAbComm1 will �re due to the reading arc from place voteAbort.
Voting is complete when the task is in the state where it is ready to check thevalue of the decision ag. This corresponds to a token in the voted1 place. Atthis point all tasks synchronise on �ring shared transitions commitAll or abortAll,which are respectively preconditioned by the controller's places voteNotAbort
and voteAbort. If the former �res it puts a token in the local success1 place,otherwise the local fail1 is marked. The task subsequently �res one of the twopossible restart transitions which corresponds to bringing the task to the statewhere it is ready to execute the Atomic Action again.
Using the PED tool we constructed the model of the system from the task andcontroller fragments. Once the appropriate places and transitions are merged theactual behavioural interaction between task and controller is achieved throughthe following two main mechanisms:
{ (i) synchronisation on shared transitions, which is similar to rendez-vous(blocking) synchronisation, and
{ (ii) communication via shared places, which is similar to asynchronous (non-blocking) communication.
3.4 Veri�cation of the P/T-net model
This P/T net model of the Ada code can be exported from PED to analysistools, such as INA or PEP. We used PEP, in which we could simulate the tokengame and perform reachabilty analysis to verify by Model Checking the keyproperties of the algorithm. First, if `Task1' is in place success1 then it must notbe possible for any of the other tasks (say 2) to be in fail2. This is presented tothe reachability analysis tool by the following logic statement:
success1,fail2
125
This test gives the <NO> result, i.e. such a marking in which these two placesare marked is not reachable.
Similarly, to the test for reachability of a marking in which both tasks endin success state:
success1,success2
the tool reacts with <YES> and produces:
_SEQUENCE:
arr2,done2,arr1,done1,doneAll
which is a �ring sequence leading to the global success state.
When setting the option Calculate all paths to true, the tool producesthe following list of �ring sequences:
_SEQUENCE:
arr2,done2,arr1,done1,doneAll
arr2,arr1,done2,done1,doneAll
arr1,arr2,done2,done1,doneAll
arr1,done1,arr2,done2,doneAll
arr2,arr1,done1,done2,doneAll
arr1,arr2,done1,done2,doneAll
This set, however, includes only those paths which go through the locDone
states, but not those which are the result of succcesful handling and overallCommit voting. This is caused by the fact the system searches for all pathssatisfying the shortest length criterion.
The e�ect of a coherent error handling can be tested by:
fail1,fail2
This results in:
_SEQUENCE:
arr1,done1,arr2,sigAbort2,except21,sendAbort2,except12,sendAbComm1,sync,abortAll
arr2,arr1,done1,sigAbort2,except21,sendAbort2,except12,sendAbComm1,sync,abortAll
...
all together over 600 paths. These assertions imply inconsistency is not possible.
We have also used tool INA to verify the various behavioural (safety andliveness) properties. The results of this analysis are:
Safety Properties:
Safe - No
Bounded - Yes
Dead State Reachable - No
Covered by Transition-Invariants - Yes
126
These results mean that several tasks can enter the controller simultane-ously, but that the total number of tasks is bounded. All transitions belong toa transition-invariant, which means that the net is structurally live, i.e. it issuÆciently rich in connections to make it live.
Resettable, reversable (to home state) - Yes
Dead transitions exist - No
Live - Yes
Live and Safe - No
The computed reachability graph has 76 states.The INA tool allows to state properties in the form of CTL (Computa-
tional Tree Logic) [12] formulas. We can formulate properties of interest, suchas whether there exists a path which leads to a state where one task ends insuccess while the other in fail:
EF((P18&P21 )V(P19 &P20 ))
Here P18 (P19) stands for success1 (success2) and P21(P20) for fail2 (fail1).The result of the check is:
s1 sat EF((P18 &P21 )V(P19 &P20 )):FALSE
Another interesting property would be, whether there is a path that leads toa state in which both tasks end in success but the ag Killed (place P7 below)has been set to true:
s1 sat EF(P7&(P18 &P19 )): FALSE
For comparison, we have tried a modi�ed net model for a task { we omitted aread arc leading to transition done1 which tests ag notKilled. This modi�cationmay correspond to allowing the code for a task to be non-sequential { a taskmay signal abort and at the same time pass to Local Done (the e�ect of inertiaor delay in reacting to the abort). Interestingly, such a modi�cation does notlead to the violation of deadlock-freeness or the property of both tasks endingeither in success or fail. But for the last property above it returns:
s1 sat EF(P7 &(P18 &P19 )): TRUE
4 CPN Modelling and Analysis
We modelled Atomic Actions using Coloured Petri nets (CPNs) and analysedthe model using the Design/CPN tool. The three main CPNs for the model areshown in Figures 3, 4 and 5.
They capture the system hierarchically, as a composition of the controllerand task nets. Due to the ability of CPNs to distinguish objects by their tokencolours and values, we can use the same net structure for all tasks and encode
127
VoteNAVote
Start_nTask
1‘{tsk=task(1),flg=true}++1‘{tsk=task(2),flg=true}
WaitAbort
Wait
NotKilledWait s
KilledWait
NoIntTasksWait LocDone_
n
Done
VoteAVote
Voted_nVoted
SigAbort_n
Wait
Tasks
H Tasks#2
Control
H Control#3
ar
wt
wt
ex
n‘sydn
vc
va
va1‘va++1‘vc
vt
vt
1‘da++1‘dc
ex
ex
ex
n‘dw
sy
vt
ab
vt
vt
init_task
Fig. 3. CPN model of the Atomic Action: Top Hierarchy level
Arr_n
Comp_nComp
SigAbort_n
Except_na Except_nb Done_n
HandlenHandle
SendCom_nC
SendAb_nC
SendAbCom_n C
SigAbort_n
WaitP Ou
VoteA
VoteP I/O
VoteNA
VoteP I/O
Voted_nVotedP Ou
LocDone_n
DoneP I/O
NoIntTasksWaitP Ou
KilledWait
P I/O
NotKilledWaitsP I/O
WaitAbort
WaitP I/O
Start_nTask
1‘{tsk=task(1),flg=true}++1‘{tsk=task(2),flg=true}
P In
ar
wt
wt
wt
ar
sn
cp cp
ex hadn
cpcp
sc sa sa
vc
vava
vt
vt
vt
ex
ex
ex
dw
aa
ex
ex
ab
Fig. 4. CPN model of Tasks
128
individual tasks simply by their token values. Another advantage of this type ofmodelling is that we can parameterise a system model with n tasks and analyse itfor di�erent number of tasks by simply setting the n parameter to an appropriatevalue.
The list of colour de�nitions (with parameter n = jTasksj set to 2) is:
val n=2;
color Flag = bool;
color Taskn = index task with 1..n;
color Task = record tsk : Taskn * flg : Flag;
color Signal = with s;
var ar, re, ts, cp, sn, sn_, va, vc : Task;
var ca, vt : Signal;
var ab, dw, ex, sy, wt, aa, te : Signal;
var ha, sa, sc, da, dc, dn : Task;
val init_task = 1`{tsk=task(1),flg=true}++
1`{tsk=task(2),flg=true};
Here we show the results of the analysis using Design/CPN. Most of thestatistics we produced using functions directly available from the Design/CPNmenus.
From the Statistics it can be seen that the O-graph (Occurrence Graph, i.e.reachability graph) for n = jTasksj = 2 has 63 nodes and 114 arcs. The numberof strongly connected components (Scc-graph) are less than the O-graph nodes,implying that an in�nite occurrence sequence exists.
Statistics
----------
Occurrence Graph Scc Graph
Nodes: 63 Nodes: 13
Arcs: 114 Arcs: 14
Secs: 0 Secs: 0
Status: Full
For the Boundedness Properties Integer bounds are as expected. The Signalnodes can never be more than one and the Task nodes never exceed two. Wealso show some of the best Upper Multi-set Bounds to show the task and signaldistribution. The best Lower Multi-set Bounds are all empty.
Boundedness Properties
-------------------------------------------
Best Integers Bounds Upper Lower
Control'Fail_n 1 1 0
Control'Killed 1 1 0
Control'LocDone_n 1 2 0
...
Best Upper Multi-set Bounds:
129
Control'Fail_n 1 1`s
Control'Killed 1 1`s
Control'LocDone_n 1 1`{tsk=task(1),flg=true}++1`{tsk=task(2),flg=true}
Control'NoIntTasks 1 2`s
...
SigAbort
StartWait s
Restart_nsRestart_nf
Fail_nTest
Success_nTest
AbortAll
[#flg va=false orelse #flg vc=false]
DoneAll
CommitAll
[#flg va=true andalso #flg vc=true]
SyncedSync
Sync
VoteAVote
P In
SigAbort_n
WaitP In
VoteNAVote
P I/O
NotKilledWait
sP Ou
WaitAbort
WaitP In
KilledWait
P In
LocDone_n
DoneP In
Start_nTask
1‘{tsk=task(1),flg=true}++1‘{tsk=task(2),flg=true}P Ou
Voted_nVotedP In
NoIntTasksWait
P In
n‘sy
sy
1‘va++1‘vc
te
te
te
te
te
1‘da++1‘dc
sy
n‘dw
sy
1‘va++1‘vc
aa
aa
ab
vt
ab
vt
vt
ca
ca
init_task init_task
Fig. 5. CPN model of Controller
The Home Properties show that it is possible to reach any marking from anyother marking in the O-graph. The Liveness Properties show there are no DeadMarkings. Some of the Fairness Properties of the O-graph are shown below.Only Arr n is Impartial which implies that repeated cycles of the whole graphrequire occurence of of �ring of this node.
Liveness Properties Fairness Properties
------------------------------- -------------------------
Dead Markings: None Control'AbortAll 1 Fair
Live Transitions Instances: Control'CommitAll 1 Fair
130
Control'DoneAll 1 Fair
Control'AbortAll 1 Control'Restart_nf 1 Fair
Control'CommitAll 1 Control'Restart_ns 1 Fair
Control'Restart_nf 1 Control'SigAbort 1 Fair
Control'Restart_ns 1 Control'Sync 1 Fair
Control'SigAbort 1 Tasks'Arr_n 1 Impartial
Control'Sync 1 Tasks'Done_n 1 Just
...
The following are examples of the testing of more speci�c properties formu-lated as Queries to O-graph and its nodes. These queries are based on functionsthat are de�ned in ML.
Function Success tests all markings in which the Success n node is active.A function Fail can be de�ned in a similar manner.
Function
---------------------------------------
fun Success_ (s: Test) : Node list
= PredAllNodes (fn n =>
cf(s, Mark.Control'Success_n 1 n) > 0);
-----------------------------------------
The following tests can be run using these functions:
Test Result
---------------------------------------- -------------------------------
Success_(s); val it = [29] : Node list
Fail_(s); val it = [63] : Node list
Success_(s) <> Fail_(s); val it = true : bool
length(Success_(s))+length(Fail_(s))=2; val it = true : bool
----------------------------------------- -------------------------------
This means that Success and Fail do occur, that they cannot occur si-multaneously, and that there can be only one of each. All these results are asexpected.
We can test for speci�c occurrences of the Success n node (node 29) to beactivated. It shows that there are only two possible occurrences that can leadto this happening, i.e. one from Voted causing Commitall (node 60) or Doneall(node 20).
Functions and Tests Result
----------------------------------------- -------------------------------
Success_(s); val it = [29] : Node list
InNodes(29); val it = [60,20] : Node list
OutNodes(60);OutNodes(20); val it = [29] : Node list
val it = [29] : Node list
----------------------------------------- -------------------------------
State or occurrence 60 represents transition CommitAll being activated whichleads to Success n. State or occurrence 20 represents transition DoneAll beingactivated which also leads to Success n. There are no other such occurrences.
131
Finally, the following table shows how the Occurence graph increases as thenumber of Tasks is increased.
--------------------------------------------------------------
Size of Occurence Graph with number of Tasks
--------------------------------------------------------------
|Tasks| Nodes Arcs |Tasks| Nodes Arcs
--------------------------------------------------------------
2 63 114 5 7568 25883
3 298 689 6 39331 158444
4 1481 4220 7 207667 969677
---------------------------------------------------------------
5 Conclusion
We have shown that a relatively complicated Ada program using tasking canbe modelled and veri�ed using Petri nets (ordinary P/T nets and Coloured)and Model Checking. This signi�cantly improves con�dence in the correctnessof higher-level abstraction such as atomic actions.
This paper is a preliminary attempt in pursuing our chosen direction of re-search, in which we would like to develop a more comprehensive methodologyfor verifying high-integrity systems built of Atomic Actions and implemented inAda 95.
The major new aspects of this work, which also reveal the potentially ex-ploitable advantages of the Petri net approach over the State Machine one [10],are:
{ Re�nement of both states and transitions;{ Analysis of behaviour at the true concurrency and causality level;{ High-level aspects of modelling, such as parametrisation, are possible usinghigh-level Petri nets.
For example, if re�nement with threads (e.g., task spawning), recursive atomicactions, etc. were possible in the modelled systems, then Petri nets would providea much more eÆcient way of modelling than state machines.
We have only shown ways of modelling interaction mechanisms at the seman-tical level. Part of the intended future work would be to develop new methodsof extracting Petri nets from the Ada 95 syntax.
Although this paper has not introduced real-time issues, the choice of tooland modelling technique implies that the approach can be extended to a timedPetri net approach.
References
1. Ada 95: Information technology - Programming languages - Ada. Language and
Standard Libraries. ISO/IEC 8652:1995(E), Intermetrics, Inc., 1995.
132
2. E.Best: Partial Order Veri�cation with PEP. Proc. of POMIV'96, Partial Order
Methods in Veri�cation. G. Holzmann, D. Peled, V. Pratt (eds), Am. Math. Soc.
(1997) 305-328.
3. E.Best and B.Grahlmann: PEP - more than a Petri Net Tool. Proc. of Tools and Al-
gorithms for the Construction and Analysis of Systems, 2nd International Workshop,
TACAS'96, Passau, March 1996, T. Margaria, B. Ste�en (eds). Springer-Verlag, Lec-
ture Notes in Computer Science 1055, Springer-Verlag (1996) 397-401.
4. E.Best, R.Devillers, J.Hall: The Petri Box Calculus: a New Causal Algebra with
Multilabel Communication. Advances in Petri Nets 1992, Lecture Notes in Com-
puter Science 609, Springer-Verlag (1992) 21-69.
5. E.Best, R.Devillers, and M.Koutny: Petri Nets, Process Algebras and Concurrent
Programming Languages. Lectures on Petri Nets II: Applications, Advances in Petri
Nets. Lecture Notes in Computer Science 1492, Springer-Verlag (1998) 1-84.
6. E.Best, H.Fleischhack, W.Fraczak, R.P.Hopkins, H.Klaudel and E.Pelz: M-nets: An
Algebra of High-level Petri Nets, with an Application to the Semantics of Concurrent
Programming Languages. Acta Informatica 35 (1998) 813-857.
7. R.E.Bryant: Symbolic Boolean Manipulation with Ordered Binary-decision Dia-
grams. ACM Computing Surveys 24 (1992) 293-318.
8. D.Buchs, C.Bu�ard and P.Racloz: Modelling and Validation of Tasks with Algebraic
Structured Nets. Proc. of Ada in Europe'95, Lecture Notes in Computer Science
1031, Springer-Verlag (1995) 284-297.
9. A.Burns and A.J.Wellings: Real-Time Systems and Programming Languages (Sec-
ond edition) Addison Wesley (1996).
10. A.Burns and A.J.Wellings: How to Verify Concurrent Ada Programs - The Appli-
cation of Model Checking. Ada Letters, Volume XIX, Number 2 (1999) 78-83.
11. R.H.Campbell and B.Randell: Error Recovery in Asynchronous Systems. IEEE
Transactions on Software Engineering SE-12 (1986) 811-826.
12. E.M.Clarke and E.A. Emerson: Synthesis of synchronization skeletons for branch-
ing time temporal logic. In Dexter Kozen, editor, Logic of Programs: Workshop,
LNCS, vol. 131, Springer-Verlag, 1981.
13. E.M.Clarke and J.Wing: Formal Methods: State of the Art and Future Directions.
Report, Carnegie Mellon University (June 1996).
14. J.Esparza: Model Checking Based on Branching Processes. Science of Comp. Prog.
23, 151-195 (1994).
15. R.K. Gedela and S.M. Shatz. Modeling of advanced tasking in Ada-95: a Petri
net perspective. Proc. 2-nd Int. Workshop on Software Engineering for Parallel and
Distributed Systems (PDSE'97), Boston, MA, pp. 4-14 (May 1997).
16. P.Godefroid and P.Wolper: A Partial Approach to Model Checking. Information
and Computation, 110(2), 305-326 (1994).
17. K.Jensen:Coloured Petri Nets. Basic Concepts. EATCSMonographs on Theoretical
Computer Science (1992).
18. K.H.Kim: Approaches to Mechanization of the Conversation Scheme Based on
Monitors. IEEE Transactions on Software Engineering SE-8 (1982) 189-197.
19. D.B.Lomet: Process Structuring, Synchronisation and Recovery using Atomic Ac-
tions. Proc. of ACM Conference Language Design for Reliable Software. SIGPLAN
(1977) 128-137.
20. PED. http://www-dssz.Informatik.TU-Cottbus.DE/~wwwdssz/ { the home page
of PED (a Hierachical Petri Net Editor).
21. D. Peled: Combining Partial Order Reductions with On-the- y Model-checking.
Formal Methods in Systems design 8(1), 39-64 (1996).
133
22. PEP. http://www.informatik.uni-hildesheim.de/~pep/HomePage.html { the
home page of PEP (a Programming Environment Based of Petri Nets).
23. M. Pezze, R.N. Taylor and M. Young: Graph Models for Reachability Analysis of
Concurrent Programs. ACM Transactions on Software Engineering and Methodol-
ogy 4/2 (April 1995) 171-213.
24. B. Randell: System Structure for Software Fault Tolerance. IEEE Trans. on Soft-
ware Engineering 1(2) 220-232 (1975).
25. B. Randell, P. Lee and P. Treleaven: Reliability issues in computing systems design.
ACM Computing Surveys 10(2): 123-165 (1978).
26. W.Reisig: Petri Nets. An Introduction. Springer-Verlag, EATCS Monographs on
Theoretical Computer Science Vol.3, (1985).
27. S. Roch and P.H. Starke: INA: Integrated Net Analyzer, Version 2.2, Manual
Humboldt-Univerit�at zu Berlin, Instutut f�ur Informatik, April 1999.
28. S.M. Shatz, S. Tu, T. Murata and S. Duri: An Application of Petri Net Reduc-
tion for Ada Tasking Deadlock Analysis. IEEE Trans. on Parallel and Distributed
Systems 7 (12), 1309-1324 (December 1996).
29. S.K.Shrivastava, G.N.Dixon and G.D.Parrington: An Overview of the Arjuna Dis-
tributed Programming System. IEEE Software 8 (1991) 66-73.
30. S.Tu, S.M.Shatz and T.Murata: Theory and Application of Petri Net Reduction for
Ada-Tasking Feadlock Analysis. TR 91-15, EECS Dept., Univ. of Illinois, Chicago
(1991).
31. A.Valmari: The State Explosion Problem. Lectures on Petri Nets II: Applications,
Advances in Petri Nets. Lecture Notes in Computer Science 1492, Springer-Verlag
(1998) 429-528.
32. A.J.Wellings and A.Burns: Implementing Atomic Actions in Ada 95, IEEE Trans-
actions on Software Engineering 23 (1996) 107-123.
33. The Home page of Petri net Tools on the Web:
http://www.daimi.aau.dk/~petrinet/tools/
34. The Home page of the Design/CPN tool: http://www.daimi.au.dk/designCPN/
134
COALA: A Design Language for Reliable Distributed Systems Engineering
Julie Vachon1, Nicolas Guelfi 2
1 Swiss Federal Institute of Technology,Programming Methods Laboratory, 1015 Lausanne Ecublens, Switzerland
email: [email protected] Luxembourg University of Applied Science, Software Engineering Competence Center,
L-1359 Luxembourg-Kirchberg, Luxembourgemail: [email protected]
Abstract This paper presents COALA, a language for the formal design of faulttolerant distributed systems. Advanced transaction models have already provedtheir interest for the design of reli able distributed systems. Unfortunately, thesemodels often consist in low level algorithmic approaches which are not enoughrigorously defined nor supported by a development methodology. In the field offormal approaches for distributed systems, we believe that effort is not suffi -ciently directed towards practical engineering where rigor is of interest. Theprincipal contributions of this work are twofold: (1) it provides the CoordinatedAtomic Action transaction model with a formal engineering framework; (2) itdemonstrates the practical interest of the Petri net based object-oriented specifi -cation formalism CO-OPN/2 as an underlying tool all owing rigorous and meth-odological engineering of complex reli able distributed systems. This paper alsoshortly introduces a concrete example where high level Petri nets appear to be avery useful development tool when integrated in the software lif e cycle of com-plex distributed systems.
Keywords: distributed systems design, development methodology, formal meth-ods, object orientation, Petri nets, fault tolerance, advanced transaction models.
1 Introduction
The concept of transaction has been developed to deal with the eventual loss of databaseintegrity when concurrent programs operate on it. Indeed, these programs can bestopped due to hardware/software failures or can interfere with each other. In general,concurrency and failures are the two sources of potential errors that lead to database in-consistencies. For this reason, the transaction model is used as a basic unit of consistentand reli able computing within the database domain. Managing transactions is not aneasy task and the subject has been studied thoroughly ([1], [17], [7]). Transaction man-
135
agement must deal with problems related to running sets of operations, that read ormodify shared data, while always keeping the database in a consistent state, even whenconcurrent accesses and failures occur.
In order to increase the fl exibil ity of the traditional transaction model some advancedmodels have been proposed. More flexibility is required particularly in contexts wherelong-lived and open-ended activi ties occur (such as in computer-aided design and man-ufacturing projects (CAD/CAM)). The ACID properties (atomicity, consistency, isola-tion, and durabil ity) of the traditional model seem to strong and sometime inadequatefor long duration activi ties which need to cooperate. Long lived activi ties are more in-clined to conflicts since they often maintain locks for long period of time on numerousobjects. Short transactions, waiting for lock resources, must be delayed. Long durationactivities are also more vulnerable to fail ures. Al l these facts unfortunately tend to in-creases the risks for deadlocks and abortions. Hence, aborting a long transaction isclearly undesirable for a large quantity of important work might be lost. Moreover, theisolation property of the traditional model goes against the cooperation needs of theseactivities. The objectives of new models are of many kinds. Most of them try to stati-cally divide or to dynamicall y restructure long transactions into smaller subtransactionsso as to: increase concurrency and cooperation between transactions; relax the isolationproperty; and, in case of cancellation, propose alternative solutions other than comingback to the initial state.
Coordinated atomic actions (CA actions) present a general technique for achieving faulttolerance by integrating the concepts of conversation (that encloses cooperative activi -ties), transaction (that ensures consistent access to shared objects), and exception han-dling (for error recovery) into a uniform structuring framework. More precisely, CAactions ([19],[20],[21],[23],[24]) use conversations as a mechanism for controlling con-currency and communication between threads that have been designed to cooperatewith each other. Concurrent accesses to shared objects that are external to a CA actionare controlled by the associated transaction mechanism that guarantees the ACID prop-erties. In particular, objects which are external to a CA action, and can hence be sharedwith other concurrent CA actions, must be atomic and individually responsible for theirown integrity. In a sense CA actions can be seen as a disciplined approach to using mul-ti-threaded nested transaction while providing them with well-structured exception han-dling.
Although some efforts have been devoted to the formalization of advanced transactionmodels, this work clearly appears to be insuffi cient. To ensure the deli very of reli ablecomplex distributed systems, it is important that formali zation li es within the scope ofa complete development process covering the whole software li fe cycle. This projecttherefore aims at providing the CA action model with a complete formal basis allowingsystem development according to a safe and methodological software engineering ap-proach. To realize this, we fi rst decided to provide the CA action model with a formaldesign language called COALA. COALA is meant for the definition of CA actionswhich are used to design complex distributed applications. COALA has a clear and sim-
136
ple syntax as well as a formal semantics which precisely defines the CA action model.COALA’s formal semantics is expressed in the Petri net-based object oriented specifi -cation formalism CO-OPN/2 ([2],[3],[4]). CO-OPN/2 is a specifi cation formali smwhich all ows modular description, refinement, prototype implementation and testing.The main reason motivating the choice of CO-OPN/2 as the target language of COA-LA’s semantics is that it includes most of the essential characteristics ([14]) necessaryto provide formal, structured and operational semantics for distributed systems in whichconcurrency, atomicity and consistency of data structures are to be considered. A soft-ware engineering framework has been developed for CO-OPN/2 in order to providemethods and techniques supporting the main phases of the software li fe cycle (analysis,design, implementation, verification and validation). Even if all these techniques are notyet fully integrated in this project, they represent a good framework for the defini tionof a valuable development methodology for COALA. A major contribution of this pa-per is to show that high level Petri nets can provide useful semantic and methodologicalmeans for the development of high level transaction models li ke CA actions.
This paper is organised as follow; the second section presents the state of the art of newadvanced transaction models for distributed systems, the third and fourth sections ex-plain the syntax and semantics of COALA while the fi fth section introduces a smallbanking example. The paper ends by shortly summarizing the development methodol-ogy we propose for COALA.
2 State of the Art
2.1 Traditional Transaction Systems
The main four properties associated with transactions are commonly known as the«ACID» properties. (1) Atomicity: a transaction is treated as a unit of operation, the effects of all the oper-ations of a transaction persist or none do; (2) Consistency: a transaction is a programwhich must map one consistent database to another; (3) Isolation: concurrent transac-tions must be executed as if they were executed serially, in isolation (serializabili ty),other transactions must not see the effects of any uncommitted transaction (failure iso-lation); (4) Durability: the effects produced by a transaction must be made visible andpermanent as soon as the transaction commits.
A transaction system satisfying these properties reli eves the user from many hard prob-lems related to the maintenance of the database consistency. Different algorithmic so-lutions exist which all ow controlled access to shared data objects. The most well-knownmethods are the strict two-phase locking, the timestamp ordering and the optimisticconcurrency control strategies. These methods differ in the strategy used to ensure se-rializability and recoverability of the concurrent transaction operations applied toshared data ([1],[7]).
137
2.2 Advanced Transaction Models
Nested transactions ([15]) are an intrinsically recursive model which provides for finergrained recovery and better control of reliable transaction execution. Appropriate de-sign of subtransactions can help localize failures within a (parent) transaction. Parallel-ism and modularity can be exploited within transactions so as to enhance performance.The simplicity and the structuring capabilities of this model help managing the com-plexity of systems. On the other hand, the nested transaction model remains quite con-servative regarding solutions proposed to control concurrency and to maintain dataconsistency. The split-transaction model ([16]) was proposed as an answer to some specifi c trans-action problems encountered in open-ended activi ties. The main objective is to allowdynamic reconfi guration of long transactions and to restructure them so as to reflectsome possible dynamic change in the (user or application) requirements. In the split-transaction model, partial results (that will not change) can be committed, thus prevent-ing or reducing loss of work in case of fail ure. This early releasing of committed re-sources allows more concurrency while reducing isolation between transactions andsti ll ensuring serializable accesses to resources for all transactions. However, for non-interactive applications, the usefulness of this model is less obvious. The saga model ([13]) relaxes the requirement that a long transaction be executed as asingle atomic action. Since shorter transactions reduce probabilit ies of conflicts, fail-ures, deadlocks and abortions, a saga is defined as a set of component subtransactionsexecuted in sequence or in parallel. Isolation being limited to subtransactions (not to thewhole saga), this model allows more fl exible cooperation between long activities rep-resented by sagas. Moreover, the concept being relatively simple, the saga model doesnot require very complex or novel implementation mechanisms. Contrarily to nestedtransactions, this model all ows only two levels of nesting and the outer level (saga)doesn't provide full atomicity. Sagas must be designed staticall y and do not allow dy-namic restructuring. There is no high-level support (loop, branch, etc.) to control the ex-ecution fl ow of component subtransactions within a saga, neither are there mechanismsallowing conditional creation of component subtransactions. As for recovery, the modeldoesn't deal with the failure of compensating transactions and hence does not guaranteetheir successful completion.The flex transaction model ([12]) solves transaction processing problems involvingdata in multiple autonomous an possibly heterogeneous database systems. Transactionsaccessing multiple database are often long-lived and may need to cooperate. Proposedfeatures contribute to a more fl exible and precise ordering of subtransactions execution.However, with regards to sagas, the Flex model neither reall y increases cooperation norameli orate consistency maintenance. Unfortunately, as for sagas, structuring possibil i-ties remain limited to a two-level nesting, while fail ure and concurrency atomicity aresti ll not ensured at the outmost level.The ConTract model ([22]) proposes mechanisms to facili tate persistence, consisten-cy, recovery, semantic synchronization and cooperation. Failure and concurrency ato-micity is not ensured at the ConTract level but the model proposes some alternativesolutions more adapted to the requirements of long lived activities: recovery mecha-nisms based on context management (saving/restoring), consistency control using com-
138
pensation and semantic synchronization, etc. Contrarily to former models presented inthis section, inconsistency problems due to the relaxation of the isolation property havebeen addressed. However, the ConTract model stil l leaves place for inconsistency, butthis seems the price to pay when isolation isn't guaranteed any more and when actionsneed to be compensated instead of being aborted.
2.3 Discussion: CA Actions and Advanced Transaction Models
CA actions exhibit all the ACID properties and thus ensure the maintenance of objectconsistency. As for nested transactions, CA actions provide modularity, safe concurren-cy and fi ner grained recovery. Since CA actions are multi-threaded units of work, co-operation is encapsulated inside the action: threads cooperate inside a CA action byexchanging information through internal objects. There is therefore no need to break orrelax the isolation property to allow for more cooperation. Cooperation is made easyand safe. Contrarily to most of the models introduced, control flow between subtrans-actions can be specifi ed: inside a CA action, threads execute sequential instructions andcan thus control the execution of subtransactions using sequence and conditional in-structions for example. Long transactions can easily be designed and divided into sub-transactions so as to release resources earlier for other competing subtransactions andto allow for fi ner grained recovery in case of failure. The CA action model also providesmeans for coordinated forward error recovery, thus allowing alternative solutions to beexecuted (by the participating threads of a CA action) instead of aborting and comingback to the initial state. The model also allows for persistency issues and recovery fromsystem failures. Finally, and similarly to the ConTract model, CA actions must not beconsidered as yet another transaction model but as a new comprehensive frameworkwhich aims at providing all the adequate mechanisms necessary to ensure both the mod-ular design and the safe execution of large reli able distributed systems. CA action con-cepts are introduced in Section 3 through the presentation of COALA.
2.4 Formalization and Methodology
Reli able distributed systems development is a complex and costly activi ty. We believethat a formal and methodological framework can be of great use for engineers. Formalization is an important step in language and model design which contributes toclarify concepts, syntax and semantics; it can help classifying models and facilitatesformal reasoning. Transaction systems presented in the previous section have more orless been formali zed. Nested transactions and split-transactions have shortly been spec-ified in ACTA ([5]). Atomic actions and sagas have also been characterized usingACTA in [6], which allowed better comparison of some of these models’ properties. Asfor ConTracts, mechanisms to describe and execute their computations have been intro-duced in [18]. Finall y, Flex transactions have been formalized using Predicate PetriNets ([12]). As far as we know, formal development methodologies for advanced transaction mod-els have not been deeply investigated and work sti ll needs to be done in this area. Mostresearchers who have taken up the subject of advanced transaction models have lookedat it from an algorithmic and implementation point of view. Our work rather positions
139
itself at a higher level, trying to integrate the CA action transaction model into a formaland methodological engineering framework. We believe, as shown in this paper, thathigh level Petri nets and more precisely the CO-OPN/2 formalism, are a ideal tool forbuilding this framework.
3 The COALA Language
3.1 COALA Basic Concepts
This subsection shortly explains the main concepts of CA actions ([23],[24]) as they areconsidered in COALA ([19],[21]).
Roles. A CA action is viewed as a collection of roles, each of them being associatedwith a portion of code (a subprogram). The ultimate goal of a CA action consists in co-ordinating its roles so as to coherently manage all the system's software entities, i.e. thesystem's objects. An execution thread enters a CA action by activating the role it wantsto execute. When each role has been activated, the CA action starts and each thread thusexecutes its role. This execution is coordinated by the CA action which sees that allACID properties (which ensure the consistent state of objects) are respected.
Objects. The CA action concept defines two kinds of objects, namely internal and ex-ternal objects. An internal object is an object local to a CA action and it is shared be-tween all its roles. It is used for the coordination of roles or for other internalcomputations. An external object is a global object which can be modified by the rolesof different CA actions. Operations on external objects are constrained by the ACIDproperties. External objects may be shared simultaneously by several CA actions butthe effect of the operations applied to them must be the same as if the CA actions hadbeen executed one after another. In other words, the schedule of operations applied toexternal objects must be serializable. References on external objects are passed to rolesthrough their parameters. Internal objects are declared inside the CA action’s body.
Outcomes. The execution of a CA action consists in coordinating the execution of theits roles. A CA action ends with one of the following outcomes: • Normal outcome. The ACID properties were satisfied during execution and the CA
action commits its operations;• Exceptional outcome. The ACID properties were satisfied but an exception must be
signalled to the enclosing CA action; • Abort outcome. The CA action has aborted and has undone its operations while sat-
isfying the ACID properties;• Failure outcome. A major problem occurred, preventing the CA action not only
from committing but also from aborting (i.e. the CA action ends without guarantee-ing the satisfaction of the ACID properties).
All the roles of the CA action end with the same outcome; in the case of an exceptionaloutcome all the roles signal the same exception to the enclosing CA action.
140
Exceptions and Handlers. There are two types of exceptions in CA actions: internaland interface exceptions. Internal exceptions are local to a given CA action, which musttherefore handle them on its own; each role of a CA action has a set of subprograms,called handlers, to handle these internal exceptions or a combination of them. Internalexceptions are raised by roles. When some roles of a CA action raise different internalexceptions concurrently, all roles are interrupted and a resolution algorithm then deter-mines which handler must be activated by all the roles to handle these concurrent ex-ceptions. Handlers are subprograms which try to bring the system into a new consistentstate. Handlers are not authorized to raise internal exceptions during their execution. Asfor interface exceptions, they are signalled. When a role signals an exception, it stopsits current execution, waits for the other roles to end and agrees with them to propagatethe exception at the outside level, that is to say to the enclosing CA action. Both rolesand handlers can signal interface exceptions. When signalled exceptions are propagat-ed, the situation is the same as if these exceptions were raised at the level of the enclos-ing CA action. In addition, two default interface exceptions are made avail able to allCA actions: the Abort exception and the Fail exception. These exceptions can be raisedor signalled.
Behaviour of CA actions. The execution of a CA action always corresponds to one ofthe following scenario:(1) Each role executes and ends successfully. No exception is raised during executionof roles. The CA action ends with a normal outcome;(2) Some of the roles concurrently raise internal exceptions during the execution. Theseraised exceptions can be identical or different. In any case, the CA action uses a resolu-tion graph to decide which exception handler has to be executed to cope with these con-current exceptions. All the roles of the CA action are informed of the exceptions beingraised and of the exception handler which they must execute. Once handlers are activat-ed, the foll owing cases can occur:
* If all the exception handlers end successfully, the CA action ends with a normal outcome;* If some of the exception handlers signal an interface exception during their exe-cution and if these exceptions are the same, then the underlying system forces all the handlers to signal this exception to the enclosing CA action. The CA action is said to end with an exceptional outcome;* If some of the exception handlers signal an interface exception during their exe-cution but these exception are different, the underlyi ng system tries to abort the CA action. If i t succeeds, the CA action ends with the abort outcome and all the roles signal an Abort exception to the enclosing CA action; if the abort operation fails, the CA action ends with the failure outcome and a Fail exception is signalled to the enclosing CA action. The underlying system also tries to abort the CA action if an exception is raised in a handler program. For example, this case can occur when a nested CA action, called during the execution of a handler, signals an exception which is consequently raised at the handler level. Since raised exceptions are not allowed in handlers, the underlyi ng system must abort the action.
141
(3) Some of the roles signal an interface exception during their execution and these ex-ceptions are all the same. In this case, the underlying system forces all the roles to signalthis exception to the enclosing CA action. The CA action ends with an exceptional out-come;(4) Some of the roles signal an interface exception during their execution but these ex-ceptions are different. In this case, the underlyi ng system performs an abort operationand if it succeeds all the roles signal an Abort exception and end with an abort outcome;if i t fails, they all signal a Fail exception and end with an failure outcome;(5) A role signals an interface exception while another role raises an internal exception.The raised exception is ignored, and the CA action continues executing accordingly tocases (3) or (4).
3.2 COALA Syntax
COALA has a simple and clear syntax to define CA actions and their components (ex-ceptions, roles, handlers, etc.) However, for the definition of objects and expressions,COALA uses the CO-OPN/2 formal specification language. Each COALA programthus comprises a set of CO-OPN/2 modules which define abstract data types and objectclasses. We do not present CO-OPN/2’s syntax and in this part, but it can be found in([2]).
Interface and body. The COALA definition of a CA action is made of two parts: anInterface section, which is visible to other CA actions, and a Body section, which is pri-vate and hidden to the outside world. The Interface of a CA action has the followingshape:
CAA <CAAName>Interface
Use // The list of CO-OPN/2 modules (abstract <ModuleName1>, // data types and classes) which are used <ModuleName2,>, ... ; // in the Interface part of the CA action. Roles
// The list of its (parameterized) roles<RoleName1> : <Parameter type>, ...; <RoleName2> : <Parameter type>, ...; ...
Exceptions // The list of the (parameteri zed) interface exceptions which the CA action can // signal to an enclosing CA action
<ExceptionName> : <Parameter type>; ... ;Body
Use // The list of CO-OPN/2 modules (abstract data<ModuleName1>, // types and classes) which are used in
<ModuleName2>, ...; // the Body part of the CA action.Use CAA // The list of nested CA actions.
<CaaName1>, <CaaName2,>, ... ; Objects
// The list of the CA action's internal objects; the behaviour of // these objects are specifi ed in separate CO-OPN/2 specif ication modules.<Object1>:<type>; <Object2>:<type>; ...;
142
Exceptions // The list of the (parameterized) <ExceptionName> : <Parameter type>; // internal exceptions that can be
// raised within the CA action.Handlers// The list of the (parameteri zed) exception handlers of the CA action.<HandlerName1> : <Parameter type>, ...; <HandlerName2> : <Parameter type>, ...; Resolution<ExceptionName1>(<ParameterName,...>),<ExceptionName2>(<ParameterName,...>)
-> <HandlerName>(<ParameterName,...>);// The CA action resolution graph which li sts all the combinations// of internal exceptions which can be raised concurrently, together with the// handlers which must be activated in each case. If a combination of internal // exceptions can't be found in the list during execution, this means that no handler // was foreseen to handle the case: an abort exception must be signalled by the // underlying system.
Where <VarName1>: <TypeName1>; // Local variables and their types;<VarName2>: <TypeName2>; // Types are specif ied using CO-OPN/2.»...
Role <RoleName1> (<ParameterName>, <ParameterName>, ...);Begin <instructions>;End // Role program.Where <VarName>: <TypeName>; // Local variables and their types;
...Handler <HandlerName>;
Begin <instructions>; End // Role program.Where <VarName>: <TypeName>; // Local variables and their types;
...End <HandlerName>;
End <RoleName1>;
Role <RoleName2> (<ParameterName>, <ParameterName>, ...);....
End <CAAName>;
Roles and handlers instructions. The behaviour of a role or a handler is described byan instruction block, that is a sequence of instructions. COALA 's instructions may con-tain variables but also expressions and conditions which refer to CO-OPN/2 specifi ca-tion modules declared in the Use fields of a CA action. • Variable. Name to which a (typed) value is associated. A variable must be in the
scope of the instruction block where it is used. Variables are declared in the Where field of a role, a handler, a resolution graph, etc.
• Expression. Since COALA uses CO-OPN/2 specifications for the definition of data types and object classes, an expression is a term written over the global signa-ture of a CO-OPN/2 specifi cation and over some sorted set of declared COALA variables.
• Condition. Boolean expression based on the terms built over the CO-OPN/2 global signature.
• Instructions An instruction block is a non empty sequence of instructions delim-ited by Begin and End keywords. An instruction is either empty or is one of the fol-lowing:
1. Assign a To v; - Assigns expression a to variable v.2. Execute o.m(a1,..., an); - If method m of the object referenced by o can be exe-
143
cuted given parameters a1,..., an and according to the corresponding CO-OPN/2 specifi cation, then the instruction succeeds. If not, then an internal exception (i.e. a predefined exception raised by the underlyi ng system) is raised.
3. If c Then instructionBlock1 Else instructionBlock2; - If condition c is true (according to the model of the given CO-OPN/2 specifi cation), then instructionBlock1 is exe-cuted. If c is false, then instructionBlock2 is executed.
4. Raise exceptionName(a1,..., an); - All ows a role to raise an internal exception within a CA action. exceptionName must be the name of an internal exception defined in the body of the CA action or the Abort or Fail exceptions. a1,..., an are expressions which parameterize the exception raised.
5. Signal exceptionName(a1,..., an) - All ows a role or an exception handler to signal an interface exception to an enclosing CA action. The name of the exception (exceptionName) is either one of the exceptions defined in the interface of the CA action, or the Abort or Fail exception. When signall ing an exception, a role/han-dler interrupts its execution and waits for the other roles/handlers of the CA action to end so as to propagate the exception being signall ed.
6. Call roleName(a1,..., an) Of caaName - All ows the activation of role roleName of (nested) CA action caaName. If an instance of caaName already exists and its role roleName hasn't yet been fulfi ll ed, then roleName is activated with its actual parameters a1,..., an passed on. Otherwise, the underlying system first creates a new instance of caaName, (with its own internal objects), before activating the role roleName. The actual parameters a1,..., an are expressions which may contain variables referring to external objects. Note that this instruction is blocking and execution resumes only after CA action caaName is ended.
3.3 COALA Semantics
COALA's semantics ([20],[21]) is defined as a translation from COALA programs intotheir formal description in CO-OPN/2. Since objects and abstract data types of a COA-LA programs are already defined in CO-OPN/2, part of the semantics is directly ob-tained. The other part must deal with the semantic defini tion of CA actions coordinationmechanisms, of roles/handlers programs and of external objects atomicity. For this, wepropose a set of CO-OPN/2 generic classes specifying the general behaviour of (1) CAactions, (2) Roles and (3) Internal/External objects affected by CA actions. Each CA ac-tion, each role and each object of a COALA program is being semanticall y describedby a CO-OPN/2 object, which is an instance of one of the three generic classes or is aninstance of one of their subclasses. Indeed, particular instances and subclasses must becreated to express the precise semantics of a given COALA program.
• Class Caa describes all the coordination mechanisms of the CA action. This includes starting all the roles synchronously, solving distributed raised exceptions and man-aging how they must be handled, coordinating ending roles, signall ing exceptions, etc.
• Class Role describes how a role is started, how it ends and how it interprets the instructions which it has to execute (see instructions described in Section 3.2)
• Class IntExtObject describes how an object in a CA action processes the operation
144
requests it receives, while together ensuring respect of the operations' ACID prop-erties. Class IntExtObject refers to another CO-OPN/2 class called objVersion to keep trace of the different object state versions that each CA action sees at one given time. More precisely, these object state versions represent the different views that each individual CA action (operating on the object) has of the object's state. When a CA action commits, the view it has of the object's state becomes the current state of the object. If it aborts, no change is made to the object's current state.
This object-oriented approach adopted to build COALA's semantics presents many ad-vantages. Among others, this semantic defini tion is modular, generic, clear and quite in-tuitive. The semantics of a COALA program is obtained by extending the genericclasses introduced above and by creating the appropriate instances which represent theCA actions in the program and their components (roles, internal/external objects, etc.)Figure 1 ill ustrates an example of a CO-OPN/2 class hierarchy used for the semanticsof a COALA program. The genericity and modularity quali ties of this approach allowto translate COALA programs into a set of CO-OPN/2 objects by a simple extension ofthe generic classes (Caa, Role, IntExtObject) into specifi c subclasses and by creating ap-propriate instances of these subclasses.
We give below a short and partial il lustration of how roles are translated into CO-OPN/2 objects belonging to the abstract class Role which specifi es the generic mechanismsand the basic behaviour that any role must have. Roles specific to a CA action are de-scribed by individual classes which inherit from the abstract class Role. Each of thesesubclasses all ow the creation of role objects having a particular program to execute.A role object is a CO-OPN/2 object which is itself a high-level Petri net. As shown onFigures 2 and 3, a role object is composed of • a set of internal transitions (white rectangular boxes) which specify its internal
behaviour. The main internal behaviour of a role object consists in interpreting the instructions which the role has to execute.
• a set of methods (black rectangular boxes) which allow other CO-OPN/2 objects to modify its state. In the semantics Caa objects uses role object methods to act on them and coordinate their execution (to interrupt roles, to synchronize them, etc.)
As mentioned, the main internal transition of role objects is called eval and is used forinterpreting COALA instructions. Figure 2 ill ustrates the evaluation of the instruction"Call roleName(a_1,...,a_n) Of caaName". As shown on the picture, the instruction is readfrom place Instr. To interpret it, the evaluation context (containing the values assignedto variables) is required and is thus taken from place Ctxt and put back into it right after.When evaluating a Call instruction, transition eval puts the identity of the role to becalled along with its evaluated parameters in place RoleToCall. These values wil l be fetchfrom this place as soon as the CA action object whose role is being call ed can synchro-nize with the method callRole of the call ing object. This synchronization is il lustrated byFigure 3. On this figure, the Call instruction is performed by role object c while the roleobject being called is identified by r. The interpretation of this instruction consists inevaluating the arguments in the context and then putting the result together with the
145
identity of the role object to be called (i.e. r) in place RoleToCall . Appropriate tokens inthis place all ow method callRole of role object c to eventuall y fire. It does indeed as soonas the method startRoles of the caa object coordinating role r, tries to synchronize sequen-tially with (1) the method callRole of object c and (2) the method start of object r.
Role objects have many other methods (not shown on Figures 2 and 3) which are usedto define the exception handling mechanism, the way roles operate on CA actions ex-ternal objects, etc.
Figure 1 : Inheritance hierarchy and object instances for the semantics
146
Figure 2 : Role object c eva1uating a CallRole instruction
Figure 3 : Synchronisation between the calli ng role object c and the call ed role object r
147
4 Small Example
This section introduces a small banking example to il lustrate COALA concepts andsyntax. The complete COALA design of this example is given in [19]. Of course, thissimple example can not fully il lustrate the power of COALA and its interest for reli abledistributed systems engineering. For this purpose, [21] presents a complete case studywhere an Internet auction service is designed using COALA and is implemented usinga Java li brary especially designed for COALA. The example considered in this sectionillustrates a joint withdraw implicating two persons and two joint accounts. These twopersons own together two joint accounts and want to withdraw a certain amount of mon-ey from the joint account having the highest balance. The bank with which these two persons deal, offers its cli ents a special kind of accountcalled "joint account". A joint account is owned by two clients, called co-owners. Eachowner is given a personal identifi cation number (pin) which he must use to identifyhimself. The conditions applied to joint accounts and pins are the following: • A wi thdraw operation on a joint account requires the authorisation of both its co-
owners.• The balance of the joint account can be consulted by any co-owner (without the
authorisation of the other co-owner).• Money can be deposited (by anyone) on the joint account without any authorisa-
tion.• A client gives his authorisation for the execution of a transaction by providing his
pin, which must henceforth be validated. If he makes a mistake, vali dation fails and the operation is immediately aborted.
The COALA program corresponding to this banking example is made of two parts: • a COALA specification consisting of two main CA actions: JointWithdraw and With-
draw. These CA actions refer to three other small complementary CA actions (Wait-PIN, WaitInfoAmount and WaitReadAmount) which are simply used to force the synchronization of threads.
• a CO-OPN/2 specification (classes and data types) describing the objects used by the CA actions: IntegerContainer, PIN and Account.
CA action JointWithdraw. The JointWithdraw CA action presents two clients, namedclient1 and client2. They are the co-owners of two joint accounts, account1 and account2.Each joint account has an appointed co-owner who takes care of the main transactionsoperated on the account: client1 is responsible for transactions on account1 while client2 isresponsible for transactions on account2.In CA action JointWithdraw, role client1 describes the behaviour of a cli ent who wants towithdraw a certain amount of money out of one of two given joint accounts. More pre-cisely, the money must be withdrawn from the account having the greatest balance.Client1 thus informs the other co-owner, client2, about the amount to withdraw. Each cli-ent consults his appointed account and tells the other how much money there is left.Each cli ent henceforth knows on which account the money must be taken from. The cli-ent responsible for the account having the highest balance must perform the withdrawby calli ng role withdrawer of CA action Withdraw. On his side, the other client calls rolepartner of this same CA action.
148
However, if there is not enough money on a single account, the missing amount isdrawn out the other account. If some money is sti ll missing, the exception NotEnoughMon-ey must be signalled. Figure 6 partiall y describes the COALA design of CA action Join-tWithdraw. Figure 4 illustrates one of the normal (i.e. with no exception) execution of CAaction JointWithdraw. Boxes delimit the execution part under the control of each CA ac-tion. Circles represent objects. As for "X" symbols, they denote Execute instructions inthe role programs.
CA action Withdraw. As mentioned, a withdraw operation requires the authorisationof both co-owners. Hence, the client withdrawing the money (the withdrawer) must notonly give is own pin but must also get the pin of the other co-owner (his partner). Notethat clients have a single try to enter their pin when they are prompted for it. If the wrongpin is entered, then an Abort exception is raised, and the whole CA action Withdraw isaborted. If the pin vali dation process succeeds, two cases can occur: • There is enough money on the account. The required money is drawn out the
account and the balance is updated.• There is not enough money on the account. Al l the money on the account is drawn
out, the balance is thus put to 0 and the exception missing is raised. The withdrawer's exception handler takes up the execution and indicates the amount of missing money to the enclosing CA actions by assigning this amount to the external object commonAmount. If no problem occurs during this handling phase, CA action Withdraw simply ends with a normal outcome.
Figure 5 il lustrates the normal execution of CA action Withdraw.
CA actions WaitPin, WaitInfoAmount and WaitReadAmount. These nested CA ac-tions are used to coordinate the work of two threads, more precisely to synchronizethese two threads. They all have the same shape and achieve the same work: a fi rstthread enters the CA action by call ing one of the two roles; this thread is suspended untilthe second role is call ed by another thread. Since the body of the roles are empty, theseCA actions end (with a normal outcome) right after the initial synchronization of theroles.
149
.
Figure 4 : A normal execution of CA action JointWithdraw
Figure 5 : A normal execution of CA action Withdraw
150
Figure 6 : COALA design of CA action JointWithdraw
CAA JointWithdraw;InterfaceUse Account, Integers;Roles
client1 : accountType, integer;client2 : accountType;
ExceptionsNotEnoughMoney;
BodyUse Booleans;Use CAA Withdraw, WaitInfoAmount, WaitReadAmount;Object temp1,temp2,commonAmount: integerContainer;Handler
FailHandler; Aborthandler;Resolution
Abort -> Aborthandler;
Role client1 (account, amount);Begin Execute commonAmount.put(amount); Call first of WaitInfoAmount; Execute account.balance(money); Execute temp1.put(money); Call first of WaitReadAmount; Execute temp1.get(t1); Execute temp2.get(t2); If ((t1>=t2)=true) then Begin
Call withdrawer(account,commonAmount)
of Withdraw; Execute commonAmount.get(ca); If (ca > 0 = true) Then
Call partner of Withdraw; End Else Begin
Call partner of Withdraw end;Execute commonAmount.get(ca);If (ca > 0 = true) Then
Call withdrawer(account,commonAmount)
of Withdraw; End; Execute commonAmount.get(ca); If (ca > 0 = true) Then
signal NotEnoughMoney;End
Where t1, t2, ca, money, amount: integer; account: accountType;
Handler FailHandler;Begin Signal Fail; EndEnd FailHandler;
Handler Aborthandler;Begin Signal Abort; EndEnd Aborthandler;
End client1;
Role client2 (account);...
// The instruction block of this role isvery similar to the one found in roleclient1, it follows a symmetric pattern.Among others, client2 enters nested CAactions as client1 does, following thesame if-then-else scheme, but calling theopposite roles. Another difference is thatclient2 has only one parameter: noamount parameter. Indeed it is onlyclient1’s responsibili ty to indicate howmuch money must be withdrawn. Han-dlers are identical for both roles. //
End client2;End JointWithdraw;
Comments: (1) In CA action JointWithdraw,temp1, temp2 and commonAmount arelocal objects allowing roles client1and client2 to communicate betweeneach others. These objects behavelike buffers and thus provide meth-ods such as get and put to modifyand access their content.(2) CA actions WaitInfoAmount andWaitReadAmount are used to syn-chronize client1 and client2 so thatthey can get values of local objectsat the timely moment.(3) The commonAmount object con-tains the amount of money that mustbe withdrawn. It is passed as an ex-ternal parameter to CA action With-draw which decrements its valueaccordingly.
151
5 Development Methodology
COALA is a formal language for the design of distributed systems; it has a syntax, asemantics but no development methodology yet. One of the objectives of this work aimsat providing COALA with the development methodology developed for CO-OPN/2.CO-OPN/2’s development methodology is presented in detail s in [8], [9] and its appli-cation is shown in [10] and [11]. It provides an integrated formal framework designedespecially for this class of high level Petri nets which covers specifi cation, design, im-plementation, simulation and test. The work presented in this paper aims at adapting thisengineering framework to COALA. The development methodology for COALA wil lmainly consists in the following phases:• Definition of requirements (functional and safety requirements).• Abstract design in COALA.• Formal refinement of the design consisting in several steps and using an adapted
notion of a refinement function for COALA to progressively reach a detail ed design.
• Implementation carried out as a direct translation of the detail ed design into an implementation language (eventuall y using a set of predefined li braries)
• Test, using test sets allowing for the formal CO-OPN/2 semantics of the design written in COALA.
• Simulation, automatic generation of executable code based on the axiomatic semantics of CO-OPN/2.
Validation and verification could be partly addressed, in the COALA developmentmethodology, using the CO-OPN/2 notion of “contract”. A contract is assigned to eachCOALA design step (abstract or refined). Contracts must be preserved during the wholedevelopment process. Hence, properties expressed and satisfied at the abstract level wil lsti ll be present at implementation level. Formal and informal proofs are proposed toguarantee the preservation of this property. Contracts are means to address validationand verification issues.
6 Conclusions
This paper had two main objectives. First, we introduced COALA as a formal languagefor the design of reliable distributed systems based on the concepts provided by the Co-ordinated Atomic Action framework. Secondly, we have described the interest of theformal engineering framework of CO-OPN/2 to address semantic and methodologicalissues in the context of distributed systems development. This was made by defini ng anew design language, COALA, with a precise syntax and a semantics given in terms ofCO-OPN/2 specifi cations. We have then summarized how techniques avail able in theCO-OPN/2 framework could be exploited to provide COALA with an engineeringmethodology allowing formal development of distributed systems. This paper repre-sents a contribution which aims at increasing the level of rigor and methodology usedin the engineering of distributed systems designed using an advanced transactionscheme based on high level Petri nets.
152
7 Acknowledgments
This work has been partially supported by the Esprit Long Term Research Project20072 “Design for Validation” (DeVa) with the fi nancial support of the OFES (OfficeFédéral pour l'Education et la Science), and by the Swiss National Science Founda-tion'. We would like to thank our colleagues for all the helpful discussions and collabo-ration we had concerning this work.
References[1] P.A. Bernstein, V. Hadzil acos and N. Goodman. Concurrency control and recovery in
database systems. Addison-Wesley Series in Computer Science. Addision-Wesley, 1987.
[2] O. Biberstein. CO-OPN/2: An Object-Oriented Formalism for the Specification of Con-current Systems. PhD thesis, University of Geneva, Geneva, Switzerland, 1997. ThesisNo 2919.
[3] O. Biberstein, D. Buchs and N. Guelfi . Object-Oriented Nets with Algebraic Specifica-tions: The CO-OPN/2 formalism. InAdvances in Petri Nets on Object-Orientation, G.Agha and F. De Cindio (Ed.), Lecture Notes in Computer Science, Springer-Verlag,2000. To appear.
[4] D. Buchs and N. Guelfi . A concurrent object-oriented Petri nets approach for systemspecification. In M. Silva, editor, 12th International Conference on Application and The-ory of Petri Nets, pages 432–454, Aarhus, Denmark, June 1991.
[5] P.K. Chrysanthis and K. Ramamritham. Acta: a framework for specif ying and reasoningabout transaction structure and behavior. In Proceedings of the ACM Special InterestGroup on Management of Data (SIGMOD) 1990, pp 194-203, New York, 1990. ACMPress.
[6] P.K. Chrysanthis and K. Ramamritham. Acta: The saga continues. In Database Transac-tion Models for Advance Applications, chapter 10, p. 349-397, Morgan Kaufmann Pub-lishers, 1992.
[7] G. Coulouris, J. Dollimore and T. Kindberg. Distributed Systems: Concepts and Design.Addison-Wesley, second edition, 1994.
[8] G. Di Marzo Serugendo. A Formal Developement and Validation Methodology for Sys-tem Design. In Fifth International Conference on Information Systems Analysis and Syn-thesis (ISAS'99), 1999.
[9] G. Di Marzo Serugendo. Stepwise Refinement of Formal Specif ications Based on LogicalFormulae: from COOPN/2 Specif ications to Java Programs. PhD thesis, Swiss FederalInstitute of Technology (EPFL), Lausanne, Switzerland, 1999. Thesis No 2919.
[10] G. Di Marzo Serugendo and N. Guelf i. Using Object-Oriented Algebraic Nets for the Re-verse Engineering of Java Programs: A Case Study. In Proceedings of the InternationalConference on Application of Concurrency to System Design (CSD'98), IEEE ComputerSociety Press, 1998, pp. 166-176. Also available as Technical Report (EPFL-DI No 98/267).
[11] G. Di Marzo Serugendo, N. Guelf i, A. Romanovsky and A. F. Zorzo. Formal Develop-ment and Validation of Java Dependable Distributed Systems. In Fifth IEEE Internation-
153
al Conference on Engineeri ng of Complex Computer Systems (ICECCS'99), IEEEComputer Society Press, 1999.
[12] A.K. Elmagarmid, Y. Leu, W. Litwin and M. Rusinkiewicz. A multidatabase transactionmodel for interbase. In Proceedings of the 16th VLDB Conference, pages 507-518, Bris-bane, Australi a, 1990.
[13] H. Garcia-Molina and K. Salem. Sagas. In Proceedings of the ACM Special InterestGroup on Management of Data (SIGMOD) 1987, pages 249-259, San Francisco, may1987.
[14] N. Guelf i, O. Biberstein, D. Buchs, E. Canver, M-C. Gaudel, F. von Henke and D. Schw-ier, Comparison of Object-Oriented Formal Methods, Technical Report of the EspritLong Term Research Project 20072 ‘ ‘Design For Vali dation’ ’, University of NewcastleUpon Tyne, Department of Computing Science, 1997.
[15] J.E.B. Moss. Nested Transactions: An introduction, chapter 14, pages 395-425. Van Nos-trand Reinhold, New York, 1987.
[16] C. Pu, G. Kaiser and N. Hutchinson. Split-transactions for open-ended activit ies. In Pro-ceedings of the 14th international conference on VLDB, pages 26-37, Los Angeles, Sep-tember 1988.
[17] K. Ramamritham and P.K. Chrysanthis. Advances in concurrency control and transac-tion processing. Executive Briefi ng Serie. IEEE Computer Society Press, 1997.
[18] F. Schwenkreis. A formal approach to synchronize long-li ved computations. In Proceed-ings of the 5th Australasian Conference on Information Systems, Melbourne, 1994.
[19] J. Vachon, D. Buchs, M. Buffo, G. Di Marzo Serugendo, B. Randell , A. Romanovsky,R.J. Stroud and J. Xu. Coala - a formal language for coordinated atomic actions. In 3rdYear Report, ESPRIT Long Term Reaseach Project 20072 on Design for Validation.LAAS Francd, november 1998.
[20] J. Vachon, The Semantics of COALA in CO-OPN/2, Technical Report EPFL-DI No 98/300, Swiss Federal Institute of Technology in Lausanne, CH-1015, Lausanne, Switzer-land, June 1999.
[21] J. Vachon, COALA: A design language for reliable distri buted systems, PhD thesis, SwissFederal Institute of Technology (EPFL), Lausanne, Switzerland, 2000. To appear.
[22] H. Wachter and A. Reuter. The contract model. In Database Transaction Models for Ad-vance Applications, chapter 7, pages 219-263. Morgan Kaufmann Publishers, 1992.
[23] J. Xu, B. Randell, A. Romanovsky, R.J. Stroud, A.F. Zorzo, E. Canver and F. von Henke,Rigorous Development of a Safety-Critical System Based on Coordinated Atomic Ac-tions. In Proceedings of the 29th Int. Symp. on Fault-Tolerant Computing (FTCS-29),IEEE CS Press, Madison, WI, USA, June 1999.
[24] A. Zorzo, A. Romanovsky, J. Xu, B.Randell, R.J. Stroud, I. Welch, Using CoordinatedAtomic Actions to Design Complex Safety-Crit ical Systems: A Production Cell CaseStudy. In Software: Practice and Experience, 29(8), pp. 677-697, 1999.
154
Supervisory Plug-ins for Distributed Software
Michael Lemmon and Kevin X. He
Dept. of Electrical EngineeringUniversity of Notre Dame, Notre Dame, IN 46556
lemmon,[email protected]
Abstract. This paper demonstrates the use of supervisory control theory in syn-thesizing plug-ins for distributed software. The plug-ins are software objects thatsupervisean existing distributed system so that certain properties such as fairnessand deadlock freedom are guaranteed. The distributed application is modeled asbounded ordinary Petri net and system analysis is accomplished through a partialorder method known as unfolding. The unfolding constructs an event structurethat provides a natural encapuslation of concurrent threads of execution whoseselective disablement by the supervisory plug-in assures the desired applicationproperty. The synthesis of the plug-in is based on results from supervisory con-trol theory and the synthesized plug-ins are ”optimal” in that they are maximallypermissive. We demonstrate our approach on a distributed cache system.
1 Introduction
Distributed software may be viewed as a collection of objects that interact throughmessage passing. Such software is of growing importance and it appears in applicationssuch as military command and control, commercial telecommunications, and emergentInternet applications. Distributed software is required in networks of embedded proces-sors that are used to control major components of the national infrastructure such asthe electric power grid and air traffic control system. Due to the critical nature of suchapplications, it is essential that we develop systematic methods for assuring the qualityof such distributed software.
Assuring the quality of distributed software can be extremely difficult. Difficultiesarise due to the concurrent and decentralized nature of the applications. The ”open”nature of many distributed software architectures also introduces many challenges. Asan example, consider a network controlling an electric power distribution system. Thissystem consists of older (so-calledlegacy) hardware and software components, as wellas newer components. The open nature of the architecture allows newer components toenter and leave the system freely. For such systems we need to ensure that the entry ordeparture of newer components does not interfere with the performance of the legacycomponents. Assuring re-usability of legacy components under software upgrades canbe difficult for a variety of reasons. In the first place, the concurrent nature of the ap-plications means that analyses of the overall system are hampered by state-space ex-plosion. In the second place, these systems can be dynamic in that objects may enter orleave the system at run-time. In such a dynamic environment it can be extremely diffi-cult to analyze system behavior due to uncertainty in the suite of objects comprising the
155
2
current system. In the third place, the mandate for open software architectures meansthat designers have limited control over legacy components, thereby complicating thedesign process. Finally, newer and older objects may interact in unpredicatable waysthat introduce new or emergent patterns of behavior. Such emergent behaviors can bevery difficult to identify due to the large scale nature of the system’s state space.
Solving the preceding problems requires a formal and scalable analysis method fordistributed systems. This paper presents a formal approach to the design of distributedsoftware that applies methods from supervisory control theory [1]. Supervisory controltheory is concerned with the regulation of discrete-event systems. It provides a clearcharacterization of optimal supervision. In this paper, we use this theory to synthesizeplug-insto a distributed application that enforce specified properties such as fairness ordeadlock freedom. The underlying formal model is a bounded Petri net. We analyze thenet’s behavior by a partial order method known as unfolding [2]. Unfolding transformsthe original system into an event structure from which we can encapsulate concurrentthreads of execution that can be selectively disabled by the synthesized plug-ins toenforce the desired behavioral properties [13]. The use of supervisory control theoryensures that the resulting system isoptimalin the sense of being maximally permissive.We demonstrate our ideas on a distributed cache system.
Remark: While the results in this paper only pertain to bounded Petri nets, it shouldbe noted that many of the definitions also apply to unbounded networks as well. In fact,there is every reason to believe that the underlying principles advocated in this paper canalso be applied to restricted classes of unbounded nets. What has not been demonstratedfor unbounded nets, however, is the optimality or existence of such supervisors.
The remainder of this paper is organized as follows. Section 2 articulates the su-pervisory control problem for distributed software. Section 3 discusses the synthesisof supervisory plug-ins using a partial order method known as unfolding. Section 4shows how these ideas can be applied to the the run-time reconfiguration of distributedsoftware. Section 5 summarizes the principal results and future directions of this work.
2 Supervising Distributed Software
This section articulates a framework in which to pose the problem of designingsu-pervisory plug-insfor a distributed application. By asupervisory plug-in, we mean asoftware object that can be composed with the base application to restrict the base ap-plication’s behavior without adding any new behaviors. This restriction of the originalsystem behavior is referred to as thesupervisory control problemin the control sys-tems literature. We therefore pose the problem of designing supervisory plug-ins as asupervisory control problem.
The underlying design paradigm in this paper is illustrated in figure 1. For the mo-ment, ignore the details in this figure and focus on the feedback connection. We seethat this system consists of the base application software (what we refer to as theplant)and the plug-in component (what we refer to as thesupervisor). The supervisor usesinformation from the plant to control the base application’s behavior. As noted in thefirst paragraph, this control actually restricts or disables the plant from executing certain
156
3
actions that are considered undesirable. The ”restrictive” nature of this control is whatcontrol theorists refer to as a ”supervision” (as opposed to regulation).
v1-v2-v1-v2
Σu
w
y
z
Σ
Σ
Σ
={W}
={0,1}
={v1,v2,v3}
={A,B} l
l
l
l
u
y
w
z
: {w} → T
(vi)=vi
(v)= { 1 if v=v30 otherwise
(u)= { {t1} if u=Bφ otherwise
v1v2
v3
supervisor
PLANT
measureableoutputs
controlled inputs
objectivesuncontrolled inputs
w-w-w
B-A-B-A
0-0-0-0
t1
t2
t3
v1 v2 v3
A
B *
* *
Fig. 1. Supervisory Control Loop
From a pragmatic point of view, there are many ways in which the block diagramin figure 1 can be viewed. One view treats the supervisor as a mobile software objectthat the user downloads to a pre-existing object in the base application. This view isparticularly useful in dynamically reconfigurable software [3] [4] where plug-ins arecomposed with the base application at run-time in order to take advantage of changes inthe structure of the application. As noted earlier, such changes can occur frequently innetwork based applications. In another, more conventional viewpoint, the ”plug-ins” be-come patches to the original program. These patches are synthesized to correct ”bugs”in the original application software. In this case, the block diagram in figure 1 is anarchetype for the software design process, in which we iteratively analyze and correct”bugs” in a given application.
The loop in figure 1 is the classical control loop used in all of traditional controltheory [5]. We now begin filling in the details of figure 1. In the loop, the plantP istreated as atwo-port system. In other words, the plant is a system with two types ofinputs and two types of outputs. Plant inputs are categorized as either beingcontrolsignalsor uncontrolled disturbance signals. The control inputs are chosen by the de-signer/supervisor to regulate plant behavior. The uncontrolled disturbance input is notcompletely known by the designer. The disturbance is really used to enable a set of pos-sible next events that the plant can generate. In this regard, therefore, the uncontrolleddisturbance injects some degree of non-determinism into the plant state’s evolution. Thesystem outputs are also categorized into two distinct groups. Theobjectivesignal is anoutput that quantifies the system’s performance. In our case, we take the object signalto be a ”warning” that the system has entered a forbidden state. The other output signalis called themeasurementsignal. This signal is directly observed by the supervisor andis used by the supervisor to help direct the plant’s behavior.
With the loop in figure 1, we now associate thesupervisory control problem. Inparticular, our problem is to find asupervisorthat prevents the plant from entering anypreviously specified forbidden state. In general, there may be a number of supervisors
157
4
that accomplish this objective. For instance, if we have a supervisor that disables allplant transitions, then we would have achieved the objective (assuming we started in asafe state to begin with). Such solutions to the supervisory control problem, however,are highly undesirable because they are extremely restrictive. In particular, we wouldlike to determine amaximally permissivesupervisor. If such a maximally permissivepolicy exists, then we say it is ”optimal”. Supervisory control in traditional control ofdiscrete event systems is concerned with the existence of and method for synthesiz-ing the maximally permissive (i.e., optimal) supervisor. The application of this theoryto software design means that we can clarify what it means for a particular softwaresolution to beoptimal.
The preceding discussion is still somewhat informal. We now provide a completeformal description of the supervisory control problem. We begin by considering the baseapplication. Let’s assume that the plant can be represented by a net systemG = (N,µ0)whereN = (S,T,F) is an ordinary bounded Petri net with placesS, transitionsT, anddirected arcsF ⊂ (S×T)∪ (T×S). µ0 is the initial marking of the net system.
For notational purposes, let’s review some basic Petri net concepts. The current stateof the Petri net is represented by themarking µ: S→ Z+. µ maps each place in the Petrinet onto a non-negative integer. Ifµ(s) > 0, then we say that places is marked. Givena transitiont ∈ T, we define the preset oft (denoted as•t) as all placess∈ Ssuch that(s, t) ∈ F. Similarly, the postset of transitiont (denoted ast•) is the set of all placess∈ Ssuch that(t,s) ∈ F . A markingµ is said to be reachable fromµ0 through transition
t (also denoted asµ0t→ µ) if and only if µ(s)> 0 for all s∈ •t and
µ(s) =
µ0(s) + 1 if s∈ t •−• tµ0(s)−1 if s∈ •t− t•
µ0(s) otherwise
A string of transitionsσ = t1, t2, · · · , tn is called anoccurrence sequenceif there exists a
sequence of marking vectorsµ0,µ1, · · · ,µn such thatµi−1ti→ µi for i = 1, . . . ,n. The set
of all markings reachable fromµ0 is denoted asR(µ0).To embed the net systemG = (N,µ0) into the control loop in figure 1, we define an
augmented plantas the 5-tuple,
P = (G, `w, `u, `z, `y)
where`w : Σw→ Pow(T) maps symbols in the disturbance alphabetΣw onto a set oftransitions, u : Σu → Pow(T) maps symbols in a control alphabetΣu onto a set oftransitions. u and `w are input functions. A transitiont is said to beuncontrollableif and only if there exists no control symbolλ such thatt ∈ `u(λ). The output maps`z : R(µ0)→ Σz and`y : R(µ0)→ Σy map the net system’s current marking onto a symbolin an objective alphabet,Σz, or measurement alphabet,Σy, respectively.
Thesupervisoris a mapS : Σy→ Σu from the measurement symbols to the controlsymbols. The supervised plantP |S is the interconnection of the augmented plant andsupervisor shown in figure 1. We can view this supervised system as an input/outputsystem that accepts a string of disturbance symbols and generates a string of objectivesymbols. In particular, consider a sequence of objective symbolsσw = w1,w2, · · · ,wn.
158
5
We say that the occurrence sequenceσ = t1, t2, · · · , tn is acceptedby the supervised plantP |S with input sequenceσw if and only if there exists a sequence of reachable markingsµ0,µ1, · · · ,µn such that
– µ0t1→ µ0
t2→ ··· tn→ µn
– ti ∈ `w(wi) for all i = 1, . . . ,n, and– ti /∈ `u(S(`y(µi−1))) for i = 1, . . . ,n.
The sequence of objective symbolsσz = z0,z1,z2 · · · ,zn is generated by this occurrencesequence ifzi = `z(µi). From these definitions, we see that the action of the supervisor isto disablespecified transitions from firing when the net system reaches a given markingin the domain of u. Because supervision is based on the marking of the plant’s Petrinet, we refer toS as amarking based supervisor.
The system in figure 1 represents a specific supervisory control system in whichplant’s network,(S,T,F) has the form shown in the figure. The output alphabets areΣy = {v1,v2,v3} andΣz = {0,1}. In this example, we define the input maps so that`u(B) = {t1} and`u(A) = /0. The disturbance input map is`w(w) = T. With these defi-nitions, we see that the control input only disables transitiont1 when the control symbolis B. Moreover, we see that the disturbance input was chosen so that at any instant, alltransitions that have their presets marked (and which have not been disabled by the su-pervisor) will be free to fire. The output map`y is chosen so that the supervisor can seeall markings generated by the system. The other output mapping,`z, generates a 1 ifthe marked state isv3. Note thatv3 is a deadlocked place from which the net systemcannot fire another transition. Therefore the objective map warns us when the system isdeadlocked. The supervisor shown in figure 1 is represented as a table for the supervisormap. It shows that we generate the output symbolB when the system marks statev1.Sincev1 has a transition,t1, leading to the deadlocked markingv3, it is apparent thatthe action of the supervisor is to prevent the system from reaching the deadlocked state.This is accomplished by disablingt1 from firing if placev1 is marked. We therefore seethat the supervisor,S , in this example is a deadlock-avoidance supervisor.
The preceding discussion shows a supervisor that prevents the plant from reachingdeadlocked marking. The deadlock avoidance property is aspecificationon the closedloop system’s desired behavior. We now generalize the ideas presented in the precedingparagraph. Let the subsetRf ⊂R(µ0) be a collection offorbidden markingsin the orig-inal net system. Assume that`z is chosen to signal the system’s entry into a forbiddenmarking. In other words, letz(µ) = 1 if and only ifµ∈Rf . Let’s partition the transitionsT into a set ofcontrollable Tc anduncontrollabletransitions. Recall that an uncontrol-lable transition is a transition that cannot be disabled by the supervisor. Therefore ift ∈ Tu, we know thatt /∈ `u(u) for any u ∈ Σu. Let L(G) denote the set of all occur-rence sequences that can be accepted byG. LetK be a sublanguage ofL(G) (also calledthe specification language) such that all occurrence sequences inK generate objectivesequences that have no ones(1) in them (i.e., no forbidden markings are entered). Con-sider the supervised plantP |S and letL(P |S) denote the set of all occurrence sequencesin L(G)accepted byP |S for any input sequenceσw ∈ Σ∗w. The supervisorS is said to belegal if L(P |S)⊆K. We say that the supervisor ismaximally permissiveif for any other
159
6
legal supervisorS ′, thenL(P |S ′) ⊆ L(P |S). Thesupervisory control problemasks usto find the maximally permissive legal supervisor. The language generated by this max-imally permissive supervisor is denoted asK↑ and is called thesupremal controllablesublanguage.
Since a bounded ordinary Petri net can be represented as a finite state machine, theresults of [10] can be used to infer the existence of the supremal controllable sublan-guage. In other words, the supervisory control problem always has anoptimalsolution(optimality being interpreted in the sense of maximal permissivity) and this means thatour problem statement is well-posed. The chief contribution of supervisory control the-ory is to ensure that the problem of finding an optimal supervisor for a discrete-eventsystem is meaningful.
Let’s consider a specific example that illustrates the application of this frameworkto the design of supervisory plug-ins for distributed software. We consider a distributedcache system in which two local cache memories synchronize their contents to thecontents in a global memory bus. Each local cache has memory and a processor tocontrol memory access. The global bus also has memory and a processor. The globalbus and local caches interact through message passing.
We assume that the local cache and global bus each have three states:invalid,shared, or owned. When the data in the local cache and global bus are synchronizedthen all objects are in thesharedstate. The data in a cache becomes unsynchronizedwhen the local cache updates its memory. When a local cache wants to perform thisupdate, it changes its local state toowned and sends the messageinvalidate to theother cache and global bus. Upon receipt of this message the global bus and other cachechange their internal states toinvalid.
The local cache can also invalidate the global bus if it detects a loss of synchronythrough aread-onlymessage. This provides a means of fault identification for mem-ory faults. In this case, the local cache issues aread-only request to the global bus.The global bus responds with the requested data and if this data is inconsistent with thelocal cache’s copy, then the local cache issues aninvalidate signal.
Once invalidated, the cache memories need to be resynchronized to the global bus.This resynchronization is initiated by the local cache that changed its local memory.After updating its memory, the local cache sends thecomplete-update message tothe global bus. The global bus responds with aread-write request for the updateddata. Theowned local cache responds to this request with the desired data and thenchanges its internal state toinvalid. Upon receipt of the data, the global bus changesits state toowned. We now have both local caches invalidated and they can each changetheir internal state toshared by issuingread-write requests to the global bus.
The software controlling the communication between the local caches and the globalbus can be viewed as distinct objects. We will formally model these objects as ordinaryPetri nets. For instance, letNlc = (S,T,F) be a Petri net for one of the local caches. Themessages sent and received by this object are a subsetSmeasof Ssuch that ifs∈ Smes,then eithers• = /0 or •s= /0. In other words, messages are places that are either sinksor sources of the object Petri net. We define theprivate variables, Spriv, of the object asall other places (i.e.Spriv = S−Smes). Thepublic methodsof the object are transitions
160
7
that are connected to message places. In particular, we define theith public method asa subsetMi ⊂ T such that ift ∈Mi then
– •t−Smes 6= /0 or t •−Smes 6= /0– and if for anyt1, t2 ∈ Mi , we know•t1−Smes= •t2−Smes and t1 •−Smes = t2 •−Smes.
In other words, public methods are collections of transitions whose arcs to messageplaces all have the same connectivity pattern. Petri net objects for the local cache andglobal bus objects are shown in figure 2. In this figure, private places are represented byopen circles. Note that in figure 2, arcs going to (from) message places do not terminate(originate) in an open circle. Message places are not explicitly shown in this figure. Alsonote in this figure that all transitions are public method. This, however, is not alwaysthe case as we can define objects that have internal private transitions.
invalidshared owned
read-write
read
ack-read
ack-write
waiting
waiting
ack-invalidinvalidate
waitinginvalidate ack-invalid
ack-invalid
invalidate
complete-update
waiting
read-write
ack-write
shared owned
ack-invalidinvalidate
read ack-read
ack-write read-write
read ack-read
invalid
complete_updateread-write
waiting
ack-write
Fig. 2. Distributed Cache System Object Petri Nets (local cache on left, global bus on right)
We now formulate the supervisory control problem for the distributed software sys-tem comprised of the objects in figure 2. Recall that the formulation of the problemstarts with a specification of the system’s forbidden markings. One obvious set of for-bidden markings would consist of those markings from which the entire system isdead-locked. Assuming that we can identify the deadlocked markingsMdead, (this is done be-low using a partial order method), we can then define the objective map`z to take valuesof 1 whenµ∈ Mdeadand zero otherwise. We’re interested in designing another object(called aplug-in) that can selectively disable system transitions to enforce deadlock-avoidance.
Since the plug-in is an object as well, it can only interact with the other objectsthrough their public methods. Therefore, our supervisor can only disable those transi-tions that are found in public methods. In this particular example, all of the transitionsare in a public method and so we have complete controllability over this system. How-ever, this need not be the case in general. For objects in which there are transitionsrepresenting private methods, these transitions cannot be directly disabled. Theuncon-trollability of various transitions in the network makes the problem of identifying asupervisory controller much more difficult. One of the chief accomplishments of super-visory control theory was the articulation of a framework for such uncontrollable net
161
8
systems and the identification of necessary and sufficient conditions for the existenceof legal controllers enforcing a desired specification language.
It is important to note that thesupervisednet system is not an ordinary Petri net. Thesupervisor disables transitions when a specified set of places are marked in the plant.This disabling action cannot always be represented by a Petri net. It is well known [6]that Petri net languages are not closed under the recursive operation used to computethe supremal controllable sublanguage. This result, therefore, implies that an optimal(maximally-permissive) marking based supervisor does not necessarily have a repre-sentation as an ordinary Petri net. On the basis of this result, therefore, we can partitionresults on supervisory control into marking-based supervisors and Petri-net based su-pervisors [7] [8] . The framework presented above uses a marking-based supervisor andin this case, we know a maximally permissive supervisor can always be found. Thereare obvious benefits in being able to represent the supervisor as a Petri net. For someclasses of specifications (deadlock), necessary and sufficient conditions for the exis-tence of a marking-based supervisor and Petri-net based supervisory have recently beenproposed [9].
3 Synthesis of Supervisory Plug-ins
Most existing approaches [11] [12] [13] for the synthesis of maximally permissive su-pervisors involve some sort of search of the Petri net’s state space. The problem withthis, of course, is that distributed software has a high degree of concurrency, so it’simpractical to search exhaustively for critical transitions leading to forbidden mark-ings. This means that clever and efficient means of search must be employed if we areto automate the design of supervisory plug-ins for this class of software. This sectionsummarizes recent results in [13] in which a partial order method known as networkunfolding is used to synthesize marking based supervisors. Partial order methods [14][15] [16] represent an important approach that can greatly reduce the complexity ofnetwork analysis. This point was first made in [17] where unfolding was proposed as ameans taming state-explosion problems encountered in the verification of asynchronousdigital circuits. Since that time a variety of researchers have used unfolding [20] [18][19] to characterize network properties and in [13], this idea was extended to synthesizesupervisors enforcing this set of characterized properties. In this section we summarizethe approach to supervisor synthesis and then illustrate its application to the design ofsupervisory plug-ins that enforce deadlock-freedom for the distributed cache examplein the preceding section.
Consider a net system(N′,µ′0), whereN′ = (S′,T ′,F ′) is an ordinary Petri net andµ′0 is the initial marking. Let min(N′) be those places inN with empty presets. We defineanoccurrence netas a net system(N ′,µ′0) such that every place is preceded by at mostone transition (i.e.,| • s| ≤ 1 for all s∈ S′), no transition is in self-conflict and a places∈min(N′) if and only if it is marked byµ′0. A branching processβ = (N′,h′) of netsystemN consists of an occurrence netN′ and a net homomorphism,h′, from N′ to N.The net homomorphism preserves the causal ordering of transitions. Specifically thismeans that if•t1 = •t2 andh′(t1) = h′(t2) thent1 = t2. In general a given network may
162
9
have many branching processes and the unfolding is the maximal branching process(denoted asβm).
The unfolding of a deadlock-free net system will always be of infinite size. Nonethe-less, it is often possible to find a branching processβc that is a finitary prefix of theunfoldingβm such that all the reachable marking of the original net systemN can beenumerated fromβc. An important prefix of this type was introduced in [17] and subse-quent variations were presented in [20]. A key concept in the characterization of suchprefixes is the concept of aconfiguration. Let Nm be the occurrence net associated withthe unfoldingβm. A set of transitions,C, is said to be a configuration if and only if alltransitions inC are in precedence and no two transitions inC are in conflict.. Given atransitiont ∈ T, we define thecauseof t (denoted as[t]) as the set of all transitionsprecedingt. The cause is easily shown to be a configuration.
The cut of a configurationC is defined as
Cut(C) = (minN′ ∪C•)−•C
whereC• (•C) is the postset (preset) of transitions inC. The cut of the configurationcontains those places that are marked after firing all transitions inC.
Given an unfoldingβm, we define the set ofend transitions Tend as any transitionsuch that
– there is no transitionT ′ ∈ Tm such thatt < t ′,– or there exists a transitiont ′ ∈T such that[t ′]⊂ [t] andhm(Cut([t ′])) = hm(Cut([t])).– or the marking ofhm(Cut([t])) is the initial markingµ0.
The transitions inTend represent a natural place to cut the unfolding because these tran-sitions either represent local deadlocks (the first condition) or they represent transitionsthat enable other configurations within the net system (the final two conditions). Wedefine the branching processβc by removing those nodes in the unfolding that followtransitions inTend. It has been shown thatβc is a finitary prefix that enumerates allreachable markings inR(µ0). In this regard, we can construe the net systemNc associ-ated withβc as a reduced reachability graph.
Recognizing the importance ofTend, we refer to the cause of any transitiont ∈Tendas abase configuration. Base configurations encapsulate causally related strings oftransitions and as such they represent a thread of execution that can be seen, intuitively,as basis threads from which all other system behaviors can be generated. Another wayof viewing the base configuration is as ameta-statefor the system. From the standpointof supervisory control, these meta-states can be selectively disabled to enforce, in amodular manner, various specifications on the system behavior. The unfolding processprovides an a means of automatically identifying these meta-states as we construct thenet system’s reduced reachability graph. The unfolding process also allows us to easilyidentify the markings enabling these meta-states. This means that unfolding can bereadily used to synthesize supervisory controllers for Petri nets, a fact that was firstadvocated in [13].
As an example, let’s consider the Petri net shown in figure 3 and construct its un-folding. The original network,N, is shown in the top part of this figure with an initialmarking of placess1 ands3. The associated occurrence net forN is shown in the second
163
10
graph in figure 3. We constructN′ from N by following the markings that are reachablefrom the initial marking. In figure 3, the first transition that is enabled is transitiont3and this results in the marking{s2,s4}. We construct the network associated with thistransition as shown in thefirst tier of the occurrence net in figure 3. The second tieris constructed by considering the markings reachable from{s2,s4}. In this case, thereare two possible transitions that can be enabled,t1 andt4. However, the network has achoice in which transition is fired. The mappings reached by choosing either of thesetransitions forms thesecond tierof this particular unfolding. Note that our unfoldinghas now identified two different paths that the Petri net can follow. These represent twodifferent concurrent executions of the system. The finalthird tier of the unfolding isobtained by firing the transitionst2 andt4.
s1
s2
s3 s4 s5
t1
t2
t3
t4
t3 t1
t4
t2 t4
s1
s5 s4
s2 s1’
s3
s5’’
s5’s4’
first tier second tier
third tier
configuration 1: {t3,t1,t2,t4}
configuration 2: {t3 t4}
critical transition = t4
Original Petri Net, Nmaps onto occurrence net, N’, through the nethomomorphism, h’
Fig. 3. Unfolding of Petri Net
164
11
Since unfolding preserves precedence relations between transitions, it can be used toidentify critical transitionswhose controllability ensures the existence of a maximallypermissive supervisor disabling a specified base configuration. In figure 3, we have thefinite prefixβc for the unfolded system. In this unfolding there are two base executions.These base configurations are formed from the set of transitionsBC1 = {t1, t2, t3, t4} andBC2 = {t2, t4}. The first executionBC1 is a cycle, in that upon completion of the exe-cution, the network reaches a marking from whichBC1 can be re-enabled. The secondexecution,BC2, is deadlocked. The unfolding in figure 3 explicitly shows how the net-work can be deadlocked when it chooses to execute base configurationBC2. In order toprevent deadlock, we simply need to find that transition which disablesBC2 from beingexecuted while keeping configurationBC1 alive.
In figure 3, it is apparent that the critical transition disablingBC2 is transitiont4.This transition can be fired inBC2 when the net marking is{s2,s4}. If we then intro-duce a supervisory map,S , that disablest4 when these two places are marked then wecan ensure that the deadlocked base configuration cannot be executed. Moreover, bydisabling the execution ofBC2 and noting thatBC1 contains all transitions of the origi-nal net systemN , we see that this proposed supervisor in fact enforces the liveness ofthe supervised system. It is, of course, crucial, in this example thatt4 be controllable.If t4 is not controllable, then it may be possible to look at those controllable transitionspreceding the critical transition and see if disabling any of them will achieve the sameresult (namely disablingBC2 and keepingBC1 alive). In this example, unfortunately,there are no such controllable transitions precedingt4 and therefore the controllabil-ity of transitiont4 is necessary and sufficient for the existence of a supervisory policyenforcing system liveness.
We now apply these ideas to the supervisory control of the distributed cache system.This particular system has a deadlock that is relatively difficult to detect. We want tosynthesize a plug-in that makes the system deadlock free. Using the unfolding meth-ods in [19], we find that the distributed cache system is deadlocked whenever one localprocessor sharing data with the global bus is trying to invalidate the other local cache’smemory, and at the same time the other cache is requesting to read data from the globalbus. The configuration in figure 4 shows how the deadlock occurs. Local cache 1 sendsout the invalidatemessage and awaits acknowledgement from local cache 2. In themeantime, local cache 2 sends out aread request to the global bus and awaits its re-sponse. The global bus, however, cannot respond because its memory was invalidatedby local cache 1. In this case both local caches and the global bus cannot proceed andthe system is deadlocked.
The situation illustrated in figure 4 is a race condition that is referred to ascyclic lockin [19]. Cyclic locks occur when a sequence of transitions in concurrent base configu-rations are interleaved in such a way that both configurations are waiting for resourcesthat the other configuration needs to release. The sequence of transitions leading up tothis race condition is called alock sequence. Lock sequences can be identified duringthe algorithmic construction of the net system’s unfolding. The data in the unfoldingcan also be used to identify those markings that must be disabled in order to prevent thelock sequence from firing. It therefore becomes possible to use the unfolding method
165
12
invalid
Local bus 1
Global bus
local bus 2
owned
read-write
waiting
ack-write
shared
shared
invalidate(to local bus 2)invalidate
invalid
waiting
invalidwaiting
read
shared
read
waiting
ack-read
invalid
ack-invalid
Fig. 4. Race Condition in Distributed Cache System
to synthesize a supervisory controller that enforces deadlock freedom in a maximallypermissive manner.
In the distributed cache example, our plug-in must not let the global bus invalidateits memory if there is a read request in its message queue. By disabling this transition,we force the global bus to respond to theread request sent by the other local cache. Onthe other hand, we must also disable a local bus’ read request if there is aninvalidate
request on the local cache’s message queue. This restriction forces the local cache toacknowledge the invalidation request and let the data update proceed.
The implementation of this supervisory action is rather simple. We only need todevelop two types of supervisory plug-ins, one for the global bus and the other for thetwo local caches. Pseudo code for the global bus plug-in is
if( (Private_State==SHARED) &&
(message_queue(invalidate)) &&
(message_queue(read)) )
disable(Shared2Invalidate)
In this pseudocode, the variablePrivate_State is the global bus state and the functionmessage_queue checks the message queue for the specified message. If the conjunc-tion of these conditions is true, then the functiondisable disables the invalidation ofthe global bus’ memory. Pseudo code for the plug-ins on the local caches is
if( message_queue(invalidate)){
Disable(Send_read_request);
} else {
Enable_all();
}
166
13
This pseudocode simply tests to see if the local cache has aninvalidatemessage onits message queue. In which case, theread_request is disabled. If the message queuedoes not have aninvalidate message queued up, then theread_request action isre-enabled.
4 Runtime Reconfiguration of Distributed Software
This section speculates on the application of supervisory control to the runtime recon-figuration of distributed software. Due to the open and dynamic nature of the physicallayer in embedded network systems, there is a real need for distributed software thatcan monitor its own health and then autonomously reconfigure itself to improve its per-formance. This is the notion ofdynamic reconfigurableor adaptivesoftware [3] [4].
The underlying paradigm is shown below in figure 5. Ignoring the details in thisfigure, we see that the basic control loop of figure 1 has been embedded into a largercontrol loop. The objective signal is now used by aswitching elementto select whichsupervisors are to be applied to our software system. To use the switching element wemust monitor the behavior of the augmented plant to detect anomalous behavior. Upondetection of an anomaly that adversely effects system performance (as represented bythe objective symbols), the switching element reconfigures the software system by se-lecting a different set of supervisory plug-ins to control the plant. This reconfiguration,of course, is done at run-time using pre-compiled objects that are simply ”plugged-into”the augmented plant.
A more detailed examination of figure 5 shows how the monitoring is actually ac-complished. We see that the objective signal is passed through a mappingQ : Σ∗z→ℜ.Q maps each string of objective symbols onto a real number that represents theQualityof Serviceor QoSprovided by the plant for this particular input sequence. The QoS is areal number and can represent a number of practical performance measures. Returningto our distributed cache example, one useful measure of QoS is the time it takes for thesystem to return to theshared state after the global bus has been invalidated. If thisresynchronization time is too long, then this means something is wrong within the sys-tem and our switching element is used to reconfigure the software. The reconfigurationdecision is made by a simple threshold test on the length of the resynchronization timeas output byQ. So in figure 5, we see that the mapQ is followed by a thresholdingelement that provides a binary output to the switching element indicating whether ornot the system needs to be reconfigured.
The actual nature of the reconfiguration depends on the suite of supervisory plug-ins we have at our disposal. In the preceding section, it was shown that this system hasa cyclic lock that can be fixed through a deadlock-avoidance plug-in. It is also possibleto introduce plug-ins for other specifications. In this distributed cache example, weconsider afairnessspecification.
To motivate this fairness specification, let’s assume that one of the local cachesissues aninvaliate message, but for some reason the cache is unable to completeupdating its memory. This may happen due to a processor fault. If this happens, thenread requests from the other local bus will be blocked because the global bus hasbeen invalidated. However, since the local cache never issues thecomplete-update
167
14
measureableoutputs
controlled inputs
objectivesuncontrolled inputs
w-w-w Q
threshold
deadlockavoidanceplug-in
plug-in to disable local cache 1
plug-in to disable local cache 2
switchingelement
Distributed Cache System’s augmentedplant.
Fig. 5.Runtime Reconfigurable Distributed Software
message, the global bus is blocked from leaving theinvalid state. This type failure inthe local cache, therefore, is sufficient to deadlock the entire distributed cache system.In other words, our distributed software system is not fault tolerant since it fails globallywhen a single local cache is faulty.
We want to fix this problem without rewriting the existing protocols in the localcaches and global bus. We solve our problem by introducing a plug-in that can be ap-plied when this type of fault is detected. Obviously, this fault results in extremely long(i.e. unbounded) resynchronization times, so the simple threshold test mentioned abovecan be used to detect this type of fault. The most obvious action to be taken at this timeis to simply isolate the faulty local cache from the entire system. This is accomplishedby introducing a supervisory plug-in on the faulty cache that disables the transitions
168
15
sendinginvalidatemessages. In figure 5, the additional two supervisors connected tothe switching element are the plug-ins disabling these transitions.
Remark: Note that in addition to applying plug-ins to isolate the faulty cache, wemust also reinitialize the global bus as well. Recall that the deadlock induced by thisfault leaves the global bus in a state from which it is deadlocked unless acomplete-update
message is received. By simply disabling messages from the faulty cache, however, wedo not clear this deadlock. It is therefore essential that in addition to turning on theplug-ins, that the global bus is re-initialized. This re-initialization is not shown in figure5. However, it must be realized that re-initialization is an important part of dynamicsoftware reconfiguration.
Remark: One important aspect of supervisory control in this application is the ap-parent composability of the supervisors. Our early work indicates that these supervisoryplug-ins can be composed in such a manner that they do not interfere with each other.This is obviously apparent in the distributed cache example, where we can apply thedeadlock-avoidance and fairness plug-ins without losing either property. Whether ornot this composability is a general property of supervisory plug-ins is currently beinginvestigated and will be reported upon in the future.
5 Conclusions
The primary contribution of this paper is the proposed application of supervisory con-trol theory to the synthesis of supervisory plug-ins for distributed software. This the-ory ensures that the synthesis problem is a well-posed optimization problem in whichwe search for maximally permissive marking-based supervisors. The theory applies tobounded net systems with uncontrollable transitions and this means that it is relevantto open architecture software systems where a designer has limited access to objectmethods. Moreover, recent advances in partial order method analyses provide system-atic methods for the synthesis of such supervisors for certain classes of specificationssuch as deadlock and fairness. In short, the methods presented in this paper apparentlyprovide a systematic and tractable set of methods that may be used to automate the de-sign of high quality distributed software. This conjecture was exemplified by using theframework to formulate an approach to run-time reconfigurable software.
This paper is aconceptpaper and there remain a number of important issues thatmust be addressed before this concept can be implemented in practice. Some of theseissues are itemized below.
– This paper’s restriction to bounded Petri net immediately suggests that traditionalfinite-state machine methods for verification and supervision might be applied aswell. The potential benefit that partial order methods bring to this analysis is a re-duction in the analysis’ complexity. Even though this paper has not formally quan-tified that reduction in complexity, it is possible to speculate that the computationalsavings obtained using this method will vary greatly with the complexity of the pro-cess being studied. Systems having a few sparsely connected fundamental cycles(such as the dining philosopher’s problem) are well served by this method. Otherproblems having many densely connected fundamental cycles may be better served
169
16
using the binary decision diagrams employed in the verification of finite-state ma-chines. Future work is needed to quantify where and when partial order methodsare most valuable.
– There is an important question concerning the implementation of the supervisor in adistributed system. Clearly, the supervisor requires access to at least a partial globalstate before it can disable a method. Identifying such states in a distributed systemcan be extremely difficult. One approach that has been suggested is for supervisorsto use time-stamped messages to construct a partial system state that is known tobe valid at a specified time in the past. The firing of object methods, therefore, mustalso accomodate such a delay. This is, probably, a function to be implemented innetwork middleware. These ideas are also being explored by our group.
– Our recent work in this area suggests that supervisory approaches indeed providea method for composing software plug-ins in a non-interfering manner. Formallyproving this conjecture is currently under way and will be reported on in the future.
– Another important direction of work concerns the fact that our plug-ins are onlysupervisory. Supervision is, by definition, a restriction of the executions that thebase application can generate. There is, however, great interest in being able todevelop plug-ins that can also augment or add to overall system behaviors in amodular manner. The apparent modular nature of our base configurations suggeststhat the unfolding methods adopted in this paper might also be used to design plug-ins that augment a system’s executions in a modular manner.
– While the Petri net is a useful low-level model for analysis purposes, its use isinconvenient for program specification. There is significant interest in our ability tointegrate high-level modeling formalisms such as the Unified Modeling Language(UML) with our Petri net tools.
– The application of these methods for the runtime reconfiguration of distributed soft-ware represents an application of these methodologies that can have an enormousimpact on the development of mobile Internet based software. Future work is defi-nitely need to more fully explore the scalability of these methods for such applica-tions.
This paper represents an initial attempt to assess the relevance of existing control theo-ries to software engineering. In particular, it seems that software development is oftenan ad hoc process in which the user (rather than the designer) is responsible for assur-ing software reliability. As distributed software becomes increasingly important in thecontrol and management of critical systems like the electric power grid or air trafficcontrol, it is essential that these software systems beengineeredin the same sense thatwe engineer planes, spacecraft, and other physical systems. In other words, our hopeis that the methodologies presented in this paper provide a framework in which to for-mally engineer critical distributed object software with provable guarantees of programquality.
References
1. P.J. Ramadge and W.M. Wonham, “Supervisory control of a class of discrete event pro-cesses”,SIAM Journal of Control and Optimization, 25(1), pp. 206-230, 1987.
170
17
2. J. Engelfriet, “Branching processes of Petri nets”,Acta Informatica, 28, 575-591, 1991.3. R. Laddaga (guest editor), special issue on “Robust software and self-adaptation”IEEE In-
telligent Systems and Their Applications, Vol. 14, No. 3, May/June 1999.4. J. Veitch and R. Laddaga (guest editors), special issue on distributed dynamic systems, Com-
munications of the ACM, Vol 41, No. 5, May 1998.5. J. Doyle, B. Francis, and A. Tannenbaum, Feedback Control Theory, MacMillan Press, 1992.6. A. Giua, “Blocking and Controllability of Petri Nets in Supervisory Control”,IEEE Trans.
on Automatic Control, Vol 39(4), 1994.7. K. Yamalidou, J. Moody, M.D. Lemmon and P.J. Antsaklis, Feedback Control of Petri nets
based on Place Invariants,Automatica, Vol. 32, No. 1, pp. 15-28, 1996.8. J.O. Moody, P.J. Antsaklis, and M.D. Lemmon, “Application of Automatic Petri Net Con-
trol Design”, proceedings of INRIA/IEEE Conference sur les technologies emergentes etl’automatisation de systemes de fabrication, October 10-13, Paris, France.
9. K.X. He and M.D. Lemmon, ”On the transformation of liveness-enforcing marking basedsupervisors into monitor supervisors”, submitted to the IEEE Conference on Decision andControl, Sydney Australia, December 2000.
10. W.M.Wonham and P.J. Ramadge, “On the supremal controllable sublanguage of a givenlanguage”,SIAM Journal of Control and Optimization, 25(3), pp. 637-659, May 1987.
11. R.S. Sreenivas, “On supervisory policies that enforce liveness in complete controlled Petrinets with directed cut-places and cut-transitions”,IEEE Trans. on Automatic Control, Vol.44(6), June 1999, pp. 1221-1225.
12. Y. Li and W.M. Wonham, “control of vector discrete-event systems: controller synthesis”,IEEE Transactions on Automatic Control, Vol. 39(3), pp. 512-530, 1994.
13. K.X. He and M.D. Lemmon, ”On the existence of liveness-enforcing supervisory policiesof discrete-event systems modeled byn-safe Petri nets”,Proceedings of IFAC conference onControl System Design, Special issue on Petri nets, Slovakia, June 2000.
14. Vogler, W. (1992),Modular Construction and Partial Order Semantics of Petri Nets, LectureNotes in Computer Science, Vol. 625, Springer-Verlag, 1992.
15. P. Godefroid.Partial-Order Methods for the Verification of Concurrent Systems – An Ap-proach to the State-Explosion Problem.PhD thesis, University of Liege, Computer ScienceDepartment, November 1994.
16. P. Godefroid and P. Wolper, ”Using Partial Orders for the Efficient Verification of Dead-lock Freedom and Safety Properties,”Formal Methods in System Design, Kluwer AcademicPublishers, Vol. 2, No. 2, April 1993, pp. 149-164.
17. K. McMillan,”Using unfoldings to avoid the state explosion problem in the verification ofasynchronous circuits”,Computer Aided Verification, 4th International Workshop (CAV’92),(Bochmann and Probst (eds.), LLNCS Vol 663, Springer Verlag, 164-177, 1992.
18. A. Kondratyev, M. Kishinevsky, A. Taubing, and S. Ten, “Structural approach for the analysisof Petri nets by reduced unfoldings”,Proceedings of the 17th International Conference onApplication and Theory of Petri Nets, Osaka Japan, June 24-28, 1996.
19. K.X. He and M.D. Lemmon, “Liveness verification of discrete event systems modeled byn-safe Petri nets”, to appear in Proceedings of the 21st International Conference on Applicationand Theory of Petri Nets, Denmark, June 2000.
20. J. Esparza, S. Romer, and W. Vogler, “An improvement of McMillan’s unfolding algorithm”,Proceedings of Tools and Algorithms for the Construction and Analysis of Systems, (T. Ma-garia and B. Steffen, eds.), LNCS Vol. 1055, Springer-Verlag, 1996.
171
172
Protocol Re-synthesis
Based on Extended Petri Nets?
Khaled El-Fakih1, Hirozumi Yamaguchi2,
Gregor v. Bochmann1, and Teruo Higashino2
1 School of Information Technology and Engineering, University of Ottawa,
150 Louis Pasteur, Ottawa, Ontario K1N 6N5, Canada
fkelfakih,[email protected] Graduate School of Engineering Science, Osaka University,
1-3 Machikaneyamacho, Toyonaka, Osaka 560-8531, Japan
fh-yamagu,[email protected]
Abstract. Protocol synthesis is used to derive a speci�cation of a dis-
tributed system from the speci�cation of the services to be provided by
the system to its users. Maintaining such a system involves applying fre-
quent minor modi�cations to the service speci�cation due to changes in
the user requirements. In order to reduce the maintenance costs of such a
system, we present an original method that consists of a set of rules that
avoid complete protocol synthesis after these modi�cations. These rules
are given for a system modeled as an extended Petri net. An application
example is given along with some experimental results.
1 Introduction
Synthesis methods have been used (for surveys see [5, 6]) to derive a speci�ca-
tion of a distributed system (hereafter called protocol speci�cation) automatically
from a given speci�cation of the service to be provided by the distributed system
to its users (called service speci�cation). The service speci�cation is written like
a program of a centralized system, and does not contain any speci�cation of
the message exchange between di�erent physical locations. However, the proto-
col speci�cation contains the speci�cation of communications between protocol
entities (PE's) at the di�erent locations.
A number of existing protocol synthesis strategies have been described in
the literature. The �rst strategy, [9, 3, 4, 8, 10, 12, 14, 17, 18], aims at implement-
ing complex control- ows using several computational models such as LOTOS,
Petri nets, FSM/EFSM and temporal logic. The second strategy, [20, 23, 19, 24,
22], aims at satisfying the timing constraints speci�ed by a given service speci-
�cation in the derived protocol speci�cation. This strategy deals with real-time
distributed systems. The last strategy, [21, 25, 11, 15, 7, 16], deals with the man-
agement of distributed resources such as �les and databases. The objective here,
? This work was partially funded by Communications and Information Technology
Ontario (CITO).
173
is to determine how the values of these distributed resources are updated or ex-
changed between PE's for a given �xed resource allocation on di�erent physical
locations.
Some methods in the last strategy, especially these presented in our previous
research work[26], have tried to synthesize a service speci�cation by deriving its
corresponding protocol speci�cation with minimum communication costs and
optimal allocation of resources.
As an example, we consider a Computer Supported CooperativeWork (CSCW)
software development process. This process is distributed among engineers (de-
velopers, designers, managers and others). Each engineer has his own machine
(PE) and participates in the development process using distributed resources
(drafts, source codes, object codes, multimedia video and audio �les, and oth-
ers) placed on di�erent machines. Considering the need for using these resources
between di�erent computers, we derive, using our protocol synthesis method,
the engineer's sub-processes (protocol speci�cation) knowing the whole software
development cycle (service speci�cation) and we decide on an allocation of re-
sources that would minimize the communication costs. Both the service and
protocol speci�cations are described using extended Petri nets.
In realistic applications, maintaining a system modeled by a given extended
Petri net speci�cation, involves modifying its speci�cation as a result of changes
in the user requirements. Synthesizing the whole system after each modi�ca-
tion is considered expensive and time consuming. Therefore, it is important to
re-synthesize the modi�ed parts of service speci�cation in order to reduce the
maintenance cost, which was reported to account for as much as two-thirds of
the cost of software production [30].
In this paper, we present a new method for re-synthesizing the protocol
speci�cation from a modi�ed service speci�cation. The method consists of a
set of rules that would be applied to di�erent PE's after a modi�cation to the
service speci�cation, in order to produce new synthesized (henceforth called re-
synthesized) PE's. The parts of the protocol speci�cation that correspond to
the unmodi�ed parts of the service speci�cation are preserved intact. As shown
later, this method reduces the cost of synthesizing the whole system after each
modi�cation.
This paper is organized as follows. Section 2 gives examples of service and
protocol speci�cations, and Section 3 describes the protocol synthesis method.
Based on this method, we present in Section 4 protocol re-synthesis method along
with some application examples in Section 5. Section 6 concludes this paper and
includes our insights for future research.
2 Service Speci�cation and Protocol Speci�cation
2.1 Petri Net Model with Registers
We use an extended Petri net model called a Petri Net with Registers (PNR in
short) [15] to describe both service and protocol speci�cations of a distributed
174
i>R1
[ R1<-R2+i, R2<-R1+R2+i ]
G1 ? i
R1 R2
G1
i>R1
[ R1<-R2+i, R2<-R1+R2+i ]
G1 ? i
R1 R2
G1
3
1
fire
2 5 6
(a) (b)
transition t transition t
Fig. 1. Register Values and Token Locations before and after Firing of Transition in
PNR
system. In this model, an I/O event between users and the system followed by
the calculation of new values of variables inside the system is associated with
the �ring of a transition. Since distributed systems contain some variables (e.g.
databases and �les) and their values are updated according to inputs from users,
they can be modeled by PNR naturally.
Each transition t in PNR has a label hC(t); E(t);S(t)i, where C(t) is a pre-
condition statement (one of the �ring conditions of t), E(t) is an event expression(which represents I/O) and S(t) is a set of substitution statements (which repre-
sents parallel updates of data values). Consider, for example, transition t of Fig. 1
where C(t) =\i > R1", E(t) =\G1?i" and S(t) =\R1 R2+i; R2 R1+R2+i".
i is an input variable, which keeps an input value and its value is referred by
only the transition t. R1 and R2 are registers, which keep assigned values until
new values are assigned, and their values may be referred and updated by all
the transitions in PNR (that is, global variables). G1 is a gate, a service access
point (interaction point) between users and the system. Note that \?" in E(t)means that E(t) is an input event.
A transition may �re if (a) each of its input place has one token, (b) the value
of C(t) is true and (c) an input value is given through the gate in E(t) (if E(t) isan input event). Assume that an integer of value 3 has been given through gate
G1, and the current values of registers R1 and R2 are 1 and 2, respectively. In
this case the value of \i > R1" is true and the transition may �re. If it �res, the
event \G1?i" is executed and the input value 3 is assigned to input variable i.
Then \R1 R2+ i" and \R2 R1+R2+ i" are executed in parallel. Therefore
after the �ring, the tokens are moved and the values of registers R1 and R2 are
changed to �ve (= 2 + 3) and six (= 1 + 2 + 3), respectively (Fig. 1(b)).
Formally, E(t) is one of the following three events: \Gs !exp", \Gs ?iv", or
\�". \Gs !exp" is an output event and it means that the value of expression
\exp", whose arguments are registers, is output through gate Gs. \Gs ?iv" is
175
G1?i1[R2<-retrieve(R1,i1)]
keyword(i1)
keyword(i2)G2?i2[R4<-retrieve(R3,R2,i2)]
G1!R4[ ]
true
R1 R2 R3 R4
G1 G2
T1
T2
T3
Fig. 2. Service Speci�cation
an input event and it means that the value given through Gs is assigned to the
input variable \iv". \�" is an internal event, which is unobservable from the
users. S(t) is a set of substitution statements, each of the form \Rw expw",
where Rw is a register and expw is an expression whose arguments are from the
input variable in E(t) and registers. If t �res, E(t) is executed followed by the
parallel execution of statements in S(t).
2.2 Service Speci�cation
At a highly abstracted level, a distributed system is regarded as a centralized
system which works and provides services as a single \virtual" machine. The
number of actual PE's and communication channels among them are hidden. The
speci�cation of the distributed system at this level is called a service speci�cation
and denoted by Sspec.
Actual resources of a distributed system may be located on some physical
machines, called protocol entities. However, only one virtual machine is assumed
at this level. Fig. 2 shows Sspec of a simple database system which has only three
transitions. The system receives a keyword (input variable i1) through gate G1,
retrieves an entry corresponding to the keyword from a database (register R1),
and stores the result to register R2. This is done on transition T1. Then the
system receives another keyword (input variable i2) through gate G2, retrieves
an entry corresponding to the keyword and the retrieved entry (register R2)
from another database (register R3), and stores the result to register R4. This
is done on transition T2. Finally the system outputs the second result (the value
of register R4) through G1 on transition T3 and returns to the initial state.
176
R3 R4 R1 R2
G1 G2
keyword(i1)
keyword(i2)
G1?i1
Rtmp1
ID(Mb2, w)
[Rtmp1.R2<-w]
ID(Mb2, w)
[Rtmp1.i1<-i1]
ID(Mb1, w)
[Rtmp3.i1<-w]g31?w
[R2<-retrieve (R1, Rtmp3.i1)]
τ
g13?w
g13!Mb1[Rtmp1.i1]
g32!Mg1[ ]
g32?w
g31!Mb2[R2]
g23?w
[Rtmp1.i2<-w]g12?w
true
[R4<-retrieve (R3, Rtmp1.R2, Rtmp1.i2)]
τtrue
G1!R4true
true
true
ID(Ma2, w)
Rtmp2 Rtmp3
g12g13 g21 g31g32g23
[Rtmp2.i2<-i2]G2?i2
true trueg21!Mb2[Rtmp2.i2] g23!Ma2[ ]
τtrue
τtrue
PE1 PE2 PE3
ID(Mg1, w)
true
t1.1
t1.2 t1.6
t2.1
t2.3 t2.2
t1.3
t1.4
t1.5
t2.4
t2.5
t2.7t2.6
t2.8
t3.1
Fig. 3. Protocol Speci�cation
2.3 Protocol Speci�cation
A distributed system is a communication system which consists of p protocol
entities PE1, PE2, ... and PEp. We assume a duplex and reliable communication
channel with in�nite capacity bu�ers at both ends, between any pair of PEi and
PEj . The PEi (PEj) side of the communication channel is represented as gate
gij (gji). Moreover, we assume that some resources (registers and gates) are
allocated to certain PE's of the distributed system.
Two PE's communicate with each other by exchanging messages. If PEi ex-
ecutes an output event \gij !M [Rw]", the value of register Rw located on PEi is
sent to PEj through the communication channel between them and put into the
bu�er at PEj 's end. M is an identi�er to distinguish several values which may
exist at the same time on the same channel. PEj can take the value identi�ed
by M from the bu�er, by executing an input event \gji?w" with a pre-condition
ID(M;w). ID(M;w) is a predicate whose value is true i� the identi�er in input
variable w isM . Note that more than one register's or input variable's value can
be sent at a time. If a received data contains multiple values, they are distin-
guished by suÆx such as w:R1 and w:i. A set of an identi�er and register/input
values is called a message. A message may contain no value and sending such a
message is represented as an output event \gij !M [ ]".
In order to implement a distributed system which consists of p PE's, we
must specify the behavior of these PE's. A speci�cation of PEk is called a
177
protocol entity speci�cation and denoted by Pspeck. A set of p protocol entity
speci�cations h Pspec1, ..., Pspecp i is called a protocol speci�cation and denoted
by Pspech1;pi. We need a protocol speci�cation to implement the distributed
system.
As an example, let us assume that there are three PE's PE1, PE2 and PE3
in order to implement the service speci�cation of Fig. 2. We also assume that an
allocation of resources to these PE's has been �xed as follows. PE1 has the gate
G1 and the registers R3 and R4, PE2 has the gate G2, and PE3 has the registers
R1 and R2. Note that in addition to these registers, we assume that each PEi
has another register Rtmpi to keep received values given through gates (inputs
and message contents). Rtmpi can contain several values. The values can be
distinguished by adding the name of the value as suÆx, such as Rtmp1:R31. Fig.
3 shows an example of Pspech1;3i, which provides the service of Fig. 2, based on
this allocation of resources.
According to the speci�cation of Fig. 3, PE1 �rst receives an input (input
variable i1) through G1 and stores it to Rtmp1:i1 (on transition t1:1). Then it
sends the value of Rtmp1:i1 to PE3 as a message (on transition t1:2), since PE3
needs the value of i1 to change the value of R2. PE3 receives and stores the
value to Rtmp3:i1 on transition t1:3. Then it changes the value of R2 using its
own value and the value of Rtmp3:i1 on transition t1:4, and sends a message
to PE2 on transition t1:5. When PE2 receives the message on transition t1:6,
PE2 knows that it can now check the value of C(T2) and execute E(T2). PE2
receives an input (input variable i2) and stores it to Rtmp2:i2 on transition t2:1,
and sends two messages. One is to send the value of i2 to PE1 (on transition
t2:3) and another is to incite PE3 to send the value of R2 to PE1 (on transition
t2:2). PE1 receives these values and stores them to Rtmp1:i2 and Rtmp1:R2
on transitions t2:6 and t2:7, respectively. Then it changes the value of R4 on
transition t2:8. Finally, PE1 outputs the value of R4 on transition t3:1 and PE1,
PE2 and PE3 return to their initial states.
As exempli�ed in the above discussion, PE's cooperate with each other by
exchanging messages. The communication between di�erent PE's may be quite
complex and it is diÆcult to design protocols that behave correctly. Therefore we
would like to derive a protocol speci�cation automatically, such that it provides
the same service as a given service speci�cation.
3 Synthesis Overview
A method for deriving protocol speci�cation with an optimal allocation of re-
sources from a given service speci�cation is presented in this section. This method
is based on a set of rules (called henceforth synthesis rules) that specify how to
execute each transition Tx = hC(Tx); E(Tx);S(Tx)i of the service speci�cation
by the corresponding PE's in the protocol speci�cation. Furthermore, based on
1 We can realize such a register that contains several values by using several registers.
However, for simplicity of discussion, we use these registers.
178
these rules, it decides on an optimal allocation of resources (registers and gates)
amongst di�erent derived PE's.
3.1 Synthesis Rules
For executing a transition Tx = hC(Tx); E(Tx);S(Tx)i of the service speci�cationby the corresponding set of transitions tx:1; tx:2; ::: of the PE's in the protocol
speci�cation, we proceed as follows.
{ The PE that has gate Gs used in E(Tx) (say PEstart(Tx)) checks the value
of C(Tx) (pre-condition statement) and executes E(Tx) (event expression).{ After that, the PE sends messages called �-messages to the PE's which have
the registers used in the arguments of S(Tx) (substitution statements).
{ In response, these PE's send the register values to the PE's which have the
registers to be updated in S(Tx) (PEsubst(Tx) denotes the set of those PE's)as messages called �-messages.
{ The substitution statements are executed and noti�cation messages called
-messages are sent to those PE's which will start the execution of the next
transitions.
For example, for transition T2 of the service speci�cation in Fig. 2, PEstart(T2)
is PE2 and PEsubst(T2) is fPE1g. PE2 checks the value of pre-condition state-
ment "keyword(i2)" and executes "G2?i2" on transition t2:1. Then PE2 sends
an �-message \Ma2" to PE3 on transition t2:2 since PE3 has register R2 which
is used to substitute the value of R4. PE2 also sends the input value to PE1
as a �-message \Mb2" on transition t2:3. PE3 receives the �-message \Ma2"
on transition t2:4 and sends the value of R2 to PE1 as a �-message \Mb2" on
transition t2:5. PE1 receives these two �-messages on transitions t2:6 and t2:7,
and then executes \R4 retrieve(R3; R2; i2)" on transition t2:8 using its own
register R3 and the received values of R2 and i2. The PE's which will start the
execution of next transition T3 is PE1 itself. Therefore, PE1 does not send any
-message. Then PE1 starts the execution of T3 on transition t3:1.
In Fig. 4, we present the details of the above rules [26], that are classi�ed into
action and message rules. Action rules specify which PE checks the pre-condition
and executes the event and substitution statements of Tx. Message rules specify
how the PE's exchange messages, and the contents and types of these messages.
Three types of messages are exchanged for the execution of Tx. (1) �-messages
are sent by the PE that starts the execution of Tx (i.e. PEstart(Tx)) to inform
those PE's who need to send their registers' values to other PE's, that they can
go ahead and send these values. Thus, an �-message does not contain values of
registers. (2) �-messages are sent in order to let each PE which executes some
substitution statements of Tx (i.e. PEk2PEsubst(Tx)) know the timing and some
values of registers' it needs for executing these statements. (3) -messages are
sent to each PEm2PEstart(Tx � �), note that Tx � � is the set of each next
transition of Tx, to let it know the timing and some values of registers it needs
to start executing the next transitions (i.e. transitions in Tx � �).
179
We let Tx = hC(Tx); E(Tx);S(Tx)i be a transition of Sspec.
[Action Rules]
(A1) The PE which has the gate appearing in E(Tx) (denoted by Gs) checks that
(a) the value of C(Tx) is true,(b) the execution of the previous transitions of Tx has been �nished and
(c) an input has been given through Gs if E(Tx) is an input event.
Then the PE executes E(Tx). This PE is denoted by PEstart(Tx).
(A2) After (A1), the PE's which have at least one register whose value is changed
in the substitution statements S(Tx) execute the corresponding statements in
S(Tx). The set of these PE's is denoted by PEsubst(Tx).
[Message Rules]
(M�1) Each PEk2PEsubst(Tx) must receive at least one �-message from some
PE's (each called PEj) in order to know the timing and values of registers
it needs for executing its substitution statements (see (M�2)), except where
PEk=PEstart(Tx), in this case PEk already knows the timing to start execut-
ing its substitution statements of Tx.
(M�2) If PEk2PEsubst(Tx) needs the value of some register (say Rz) in order
to execute its substitution statements, then PEk must receive Rz through a
�-message if Rz is not in PEk.
(M�3) Each PEj that sends some values of registers to PEk2PEsubst(Tx) througha �-message, knows the timing to send these values by receiving an �-message
from PEstart(Tx). Note, if PEj=PEstart(Tx) then PEj knows the timing to
send these values without receiving an �-message.
(M�) After (A1), the only PE that can send �-messages to the PE's which need
them is PEstart(Tx).
(M 1) Each PEm2PEstart(Tx � �), where Tx � � is the set of next transitions of
Tx, must receive a -message from each PEk2PEsubst(Tx) after (A2), except
where m = k. This allows PEm to know that the execution of the substitution
statements of Tx had been �nished.
(M 2) Each PEm2PEstart(Tx � �) must receive at least one -message from some
PEl (where m 6= l) in order to know that the execution of Tx had been �nished
and/or to know some values of registers it needs to evaluate and execute its
condition and event expression, respectively.
(M 3) Each PEl that sends a -message to PEm2PEstart(Tx � �) :(a) must be in PEsubst(Tx) (see (M 1)), or
(b) must receive an �-message from PEstart(Tx) to know the timing to send
the -message to PEm, or
(c) it is itself PEstart(Tx). In this case, PEl sends the -message to let PEm
know the timing and/or some values of registers to start evaluating and
executing its condition and event expressions.
(M 4) If PEm2PEstart(Tx ��) needs the value of some register (say Rv) in order to
evaluate and/or execute its substitution statements, then PEm must receive
Rv through a -message if Rz is not in PEm.
Fig. 4. Derivation Method in Detail
180
3.2 Integer Linear Programming Model for Protocol Derivation
Based on the above synthesis rules, we determine a behavior of the derived PE's
that would minimize their communication cost while optimally allocating their
resources, using an Integer Linear Programming (ILP) model. This cost could be
based on the number of messages to be exchanged between di�erent PE's [25].
Moreover, other cost criteria can also be considered such as the costs of resource
allocation, size of messages exchanged between di�erent PE's, and frequencies
of transition execution.
The ILP Model (for details see [26, 25]) consists of an objective function
that minimizes the communication cost and decides on an optimal allocation of
resources, based on a set of constraints. These constraints are based on the above
synthesis rules, and they consist of 0-1 integer variables indicating (a) whether
a PE should send a message or not, (b) whether a message contains a register
value or not, or (c) whether a register/gate is allocated to a PE or not.
4 Protocol Re-synthesis
In this section, we present our new method for re-synthesizing the protocol
speci�cation from a modi�ed service speci�cation. The method consists of a
set of rules that would be applied to di�erent PE's after a modi�cation to the
service speci�cation, in order to produce new synthesized (re-synthesized) PE's.
For each simple modi�cation (henceforth called atomic modi�cation) made on
the service speci�cation Sspec, we de�ne its corresponding atomic re-synthesis
rules. As shown later, these atomic re-synthesis rules can also be sequentially ap-
plied to deal with more than one modi�cation. Note that the atomic re-synthesis
rules are based on the synthesis rules described in Section 3. Consequently, we
show next to the description of each re-synthesis rule its corresponding synthesis
rule.
4.1 Atomic Modi�cations and Their Corresponding Re-synthesis
Rules
For each of the following possible atomic modi�cations to Sspec, we present its
corresponding atomic re-synthesis rules. Note that each modi�cation to Sspec
changes the label of a transition Tx in Sspec from hE(Tx); C(Tx);S(Tx)i tohE 0(Tx); C
0(Tx);S0(Tx)i. For convenience, we denote the following sets of regis-
ters:
{ Revx: the set of registers that PEstart(Tx) needs to evaluate C(Tx) or executeE(Tx)
{ Rrsubxi: the set of registers that are used in PEi 2PEsubst(Tx) to execute
the statements in S(Tx){ Rcsubx
i: the set of registers that are de�ned (i.e. referenced) by the left-
hand-sides of the substitution statements in S(Tx) in PEi 2PEsubst(Tx).
181
[Atomic Modi�cations]
1. Revx Revx n fRhg2. Revx Revx [ fRhg3. Rrsubx
k Rrsubx
kn fRhg
4. Rrsubxk Rrsubx
k[ fRhg
5. Rcsubxk Rcsubx
kn fRhg
6. Rcsubxk Rcsubx
k[ fRhg
[Atomic Re-synthesis Rules]
1. Revx Revx n fRhg:The following rules take into account that the value of Rh which has been
sent to PEstart(Tx) is no longer necessary after the modi�cation. These rules
are applied to the part of the protocol speci�cation where each previous
transition (say Tw) of Tx is executed, if applicable.
(a) Each PE (say PEl) which sends a -message including the value of Rh
to PEstart(Tx), should exclude the value of Rh from the -message (c.f.
synthesis rule (M 4)).
(b) If (a) is done, then the -message can be deleted only if
{ PEl 62PEsubst(Tw) (c.f. synthesis rule (M 1)),
{ there is still at least one -message sent to PEstart(Tx) after deleting
it (c.f. synthesis rule (M 2)) and
{ it no longer has values (c.f. synthesis rule (M 4)).
(c) If (b) is done, then an �-message sent to PEl can be deleted only if PEl
no longer sends �- and -messages (c.f. synthesis rule (M 3)(b)).
2. Revx Revx [ fRhg:The following rules take into account that the value of Rh must be sent to
PEstart(Tx) after the modi�cation. These rules are applied to the part of
the protocol speci�cation where each previous transition (say Tw) of Tx is
executed, if applicable.
(a) One of the PE's which have Rh and send -messages to PEstart(Tx)
should include the value of Rh in its -message to PEstart(Tx), if such
a PE exists (c.f. synthesis rule (M 4)).
(b) Otherwise, one of the PE's which have Rh should send a new -message
which includes the value of Rh to PEstart(Tx). If the PE does not re-
ceive �-messages and is not PEstart(Tx), PEstart(Tw) should send an
�-message to the PE. (c.f. synthesis rule (M 3)).
3. Rrsubxk Rrsubx
kn fRhg:
The following rules take into account that the value of Rh sent to PEk is no
longer necessary after the modi�cation. These rules are applied to the part
of the protocol speci�cation where Tx is executed.
(a) Each PE (say PEj) which sends a �-message including the value of Rh to
PEk should exclude the value from the �-message (c.f. synthesis rule
(M�2)).
(b) If (a) is done, then the �-message can be deleted only if
182
{ there is still at least one �-message sent to PEk after deleting it (c.f.
synthesis rule (M�1)) and
{ it no longer has values (c.f. synthesis rule (M�2)).
(c) If (b) is done, the �-message sent to PEj can be deleted only if PEj no
longer sends �- and -messages. (c.f. synthesis rule (M�3)).
4. Rrsubxk Rrsubx
k[ fRhg:
The following rules take into account that the value of Rh must be sent
to PEk after the modi�cation. These rules are applied to the part of the
protocol speci�cation where Tx is executed.
(a) One of the PE's which have Rh and send �-messages to PEk should
include the value of Rh to its �-message to PEk, if such a PE exists. (c.f.
synthesis rule (M�2)).
(b) Otherwise, one of PE's which have Rh should send a new �-message
which includes Rh to PEk. If the PE does not receive �-messages and is
not PEstart(Tx), PEstart(Tx) should send an �-message to the PE.
5. Rcsubxk Rcsubx
kn fRhg:
Removing a substitution statement. Usually, this may cause an additional
modi�cation Rrsubxk Rrsubx
knfRh1
; Rh2; :::; Rhk
g, since the deleted state-
ment uses values of registers. In this case, we consider that the atomic mod-
i�cation (3) was made on Sspec k times and apply its corresponding atomic
re-synthesis rule (3) k times.
6. Rcsubxk Rcsubx
k[ fRhg:
Adding a substitution statement. Usually, this may cause an additional mod-
i�cation Rrsubxk Rrsubx
k[ fRh1
; Rh2; :::; Rhk
g, since the added statement
uses values of registers. As the case of the re-synthesis rule (5), we apply the
atomic re-synthesis rule (4) k times.
4.2 Modi�cations to the Service Speci�cation
In this section, we describe how modi�cations to Sspec can be represented as the
set of atomic modi�cations presented in the previous subsection. We consider
modi�cations to the label of a transition Tx of Sspec.
{ If E(Tx) (or C(Tx)) is modi�ed to E 0(Tx) (or C0(Tx)), then this modi�cation
can be represented as a set of the atomic modi�cations of type (1) and/or
(2) which involve adding and/or removing registers from the set of registers
Revx that PEstart(Tx) needs to execute E(Tx) (or evaluate C(Tx)).{ If S(Tx) is modi�ed to S 0(Tx), then this modi�cation can be represented by
a sequence of atomic modi�cations of type (3), (4), (5) or (6), respectively.
4.3 Changing the Resource Allocation for the Protocol Speci�cation
In some application areas, the allocation of resources between di�erent PE's is
necessary. For example, in distributed databases, adding a copy of an existing
register to some PE's is necessary to increase the fault tolerance and balance the
load amongst these PE's. Here we consider the case where a copy of an existing
183
register Rh in PEj is added to another PE PEk. For each transition Tx where
the value of Rh is changed (de�ned) in the substitution statement S(Tx), PEk
must execute this substitution statement to update the value of register Rh.
Consequently, this modi�cation can be represented by the atomic modi�cation
(6).
5 Example and Experimental Results
5.1 Modeling the ISPW-6 Example
Protocol synthesis methods have been applied to many applications such as
communication protocols, factory manufacturing systems[14], distributed coop-
erative work management[13] and so on.
In this section, we apply our synthesis method [26] to the distributed devel-
opment of software that involves �ve engineers (project manager, quality assur-
ance, design, and two software engineers). Each engineer has his own machine
connected with the others, and participates in the development through a gate
(interfaces) of this machine, using distributed resources placed on this machine.
This distributed development process includes scheduling and assigning tasks,
design modi�cation, design review, code modi�cation, test plans modi�cation,
modi�cation of unit test packages, unit testing, and progress monitoring tasks.
The engineers cooperate with each other to �nish these sub-sequential tasks.
The reader may refer to ISPW-6 [28] for a complete description of this process,
which was provided as an example to help the understanding and comparison of
various approaches to process modeling.
Figure 5 shows a work ow model of the above development process using
PNR, where the engineers and resources needed to accomplish the tasks are
indicated. We note that for convenience, we do not show the progress monitoring
process tasks in Fig. 5.
We regard this work ow as the service speci�cation, and we derive its cor-
responding protocol speci�cation using the method and programs used in our
previous work[26], where we have developed two programs that generate for the
given speci�cation its corresponding ILP problem constraints, and derive the
protocol speci�cations using the synthesis rules. The tool lp solve[29] is used
to solve the ILP problem and obtain the minimal number of messages to be
exchanged between the derived protocol entities. It took 639 seconds on MMX-
Pentium 200MHz PC to synthesize the given speci�cation. The optimal alloca-
tion of the registers is shown in Table 1 and the minimum number of messages
to be exchanged between the di�erent PE's is 40.
5.2 Experimental Results
In this section, we show the e�ectiveness of our re-synthesis method by compar-
ing the time it takes to synthesize the given service speci�cation again after an
assumed modi�cation to the time it takes using our re-synthesis method.
We consider the following modi�cations to the given service speci�cation:
184
MN
G?
req
,ntf
Rre
q
DE
!Rre
q,R
des
ign
,
R
des
ign
_rf
Sche
dule
and
Ass
ign
Tas
ksM
odif
y D
esig
n
Rde
sign
Rde
sign
_fb
SE
1!R
des
ign
SE
2!R
des
ign
QA
!Rd
esig
n
DE
!Rd
esig
nD
E?
rvw
,dcs
SE
1?rv
w,d
cs
SE
2?rv
w,d
cs
QA
?rv
w,d
cs
[ Rrv
w_d
e <
- rv
w R
dcs_
de <
- dc
s ]
[ Rrv
w_s
e1 <
- rv
w R
dcs_
se1
<-
dcs
]
[ Rrv
w_s
e2 <
- rv
w R
dcs_
se2
<-d
cs ]
[ Rrv
w_q
a <
- rv
w R
dcs_
qa <
- dc
s ]
QA
!Rrv
w_d
e,R
rvw
_se1
,Rrv
w_s
e2,R
rvw
_qa,
Rd
cs_d
e,R
dcs
_se1
,Rd
cs_s
e2,R
dcs
_qa
auth
oriz
atio
n(nt
f)=
="y
es"
MN
G!R
dcs
dcs=
="M
inor
Cha
nges
Rec
omm
ende
d"
Rco
de
Rte
st_f
b
DE
!Rco
de,
Rd
esig
n,
Rte
st_f
bD
E?
mcd
[ Rte
stpl
an <
- ts
p ]
QA
!Rre
q,R
test
pla
nQ
A?
tsp
QA
!Rte
stp
lan
,Ru
nit
test
,
R
des
ign
,Rte
st_f
bQ
A?
utp
[ Run
ittes
t <-
utp
]
QA
!Rte
stre
sult
QA
DE
!Rte
stre
sult
[ Rte
stre
sult
<-
Run
(Run
ittes
t,Rob
ject
) ]
QA
?al
s
DE
?al
s[ R
als_
qa <
- al
s ]
[ Ral
s_qa
<-
als
]
MN
G!"
com
ple
te"
QA
?d
csdc
s==
"Mod
ifyU
nit T
est P
acka
ge"
dcs=
="M
odify
Uni
t Tes
t Pac
kage
and
Sou
rce
Cod
e"QA
?d
cs
QA
?d
csdc
s==
"Com
plet
e"
QA
!Ral
s_q
a,R
als_
de
Rev
iew
Des
ign
dcs=
="C
ompl
ete" Q
A?
dcs
[ Rco
de <
-mcd
Rob
ject
<-c
ompi
led(
mcd
) ]
Mod
ify
Cod
e
Mod
ify
Tes
t Pla
nsM
odif
y T
est U
nit P
acka
ge
Tes
t Uni
t
Rob
ject
Rte
stpl
an
Rrv
w_q
a
Rrv
w_s
e1
Rrv
w_s
e2
Rrv
w_d
e
Rdc
s_qa
Rdc
s_se
1
Rdc
s_se
2
Rdc
s_de
Run
ittes
t
Rte
stre
sult
Ral
s_de
Ral
s_qa
Dev
elop
Cha
nge
and
Tes
t Uni
tM
NG
DE
SE
1S
E2
QA
[ Rre
q <
- re
q ]
DE
?d
sg
[ Rde
sign
<-
dsg
]
MN
G!R
dcs
MN
G!R
dcs
[ Rde
sign
_rf <
- R
rvw
_de+
Rrv
w_s
e1+
Rrv
w_s
e2+
Rrv
w_q
a ]
[ Rde
sign
_rf <
- R
rvw
_de+
Rrv
w_s
e1+
Rrv
w_s
e2+
Rrv
w_q
a ]
dcs=
="M
ajor
Cha
nges
Rec
omm
ende
d"
QA
?d
cs
QA
?d
cs
[ Rte
st_f
b <
- R
test
resu
lt
+ R
als_
qe +
Ral
s_de
]
[ Rte
st_f
b <
- R
test
resu
lt
+ R
als_
qe +
Ral
s_de
]
Rdc
s
[ Rdc
s <
- dc
s ]
[ Rdc
s <
- dc
s ]
[ Rdc
s <
- dc
s ]
T1
T3
T4
T6
T8
T10
T5
T7
T9
T11
T12
T13
T18
T14
T15
T16
T17
T19
T20
T21
T22
T23
T24
T25
T26
T27
T28
T29
T30
T31
T32
T33
T34
T2
Fig. 5. Modeling the Core Problem in the ISPW-6 Example
185
PEmng PEde PEse1 PEse2 PEqa
Gate MNG DE SE1 SE2 QA
Register Rreq
Rdesign
Rdesign fb
Rrvw de
Rdcs de
Rcode
Rtest fb
Rtestplan
Rrvw se1
Rdcs se1
Runittest
Rtestresult
Rrvw se2
Rdcs se2
Rrvw qa
Rdcs qa
Rdcs
Robject
Ralc qa
Rals de
Table 1. Optimal Allocation of Resources for Engineers' Machines
Synthesis Time (sec.) Number of Messages
Re-synthesis Complete Synthesis Re-synthesis Complete Synthesis
case1 1 958 44 44
case2 1 1021 46 46
case3 1 940 40 40
case4 1 1640 42 42
MMX-Pentium 200 MHz, 128MB Memory
Table 2. Experimental Results
1. An additional source code (register Rcode new) is placed on the machine of
the software engineer 1 (SE1), and the design engineer (DE) modi�es and
compiles it as well as Rcode, in \Modify Code" (transitions T19 and T20).
2. An additional new unit test (register Runittest new) is placed on the machine
of the software engineer 2 (SE2), and the QA engineer (QA) modi�es it as
well as Runittest, in \Modify Test Unit Package" (T23 and T24). Moreover,
an additional test is done using the unit test in \Test Unit" (T25).
3. DE analyzes the test feedback (register Rtest fb) and gives his comments to
QA. For this purpose, a new register Rreport is introduced on DE's machine
and his comments are stored on it in transition T20. Then it is shown to QA
on T25.
4. For fault tolerance, a new copy of the existing code Rcode (placed on PEde)
is placed on PEmng.
After each modi�cation, we have used the programs developed in [26] to
measure the time (in seconds) it takes to synthesize the given speci�cation.
Moreover, we have also measured the time it took to re-derive the protocol
speci�cations using the re-synthesis rules and a program that we have developed
for this purpose. Table 2 shows these times. The reader can clearly see that the
re-synthesize time is much less than the time for a complete synthesis. This is
mainly due to the fact that by using the re-synthesis rules, we do not have to
re-derive the whole protocol speci�cations after each modi�cation. Moreover, we
186
do not have to re-optimize the number of messages sent between di�erent PE's
because (as shown in Table 2) the re-derived protocol speci�cations still have
optimal (or near-optimal in general cases) solutions.
6 Conclusion and Further Research
Based on our previous work on protocol synthesis of systems modeled as ex-
tended Petri nets, we have developed a set of rules that avoid complete synthe-
sis after incremental modi�cations to such a system. These rules are applied to
the a�ected parts of derived protocol speci�cation. This would make protocol
synthesis and maintenance more practical for realistic applications.
Currently, we are developing a re-synthesis method to speci�cations modeled
as �nite state machines. Moreover, we are investigating the extension of our
re-synthesis method to speci�cations modeled as timed Petri nets.
References
1. T. Murata, \Petri Nets: Properties, Analysis and Applications," Proc. of the IEEE,
Vol. 77, No. 4, pp. 541{580, 1989.2. R. Milner, \Communication and Concurrency," Prentice-Hall, 1989.3. V. Carchiolo, A. Faro and D. Giordano, \Formal Description Techniques and Auto-
mated Protocol Synthesis," Journal of Information and Software Technology, Vol.
34, No. 8, pp. 513{421, 1992.4. H. Erdogmus and R. Johnston, \On the Speci�cation and Synthesis of Commu-
nicating Processes," IEEE Trans. on Software Engineering, Vol. SE-16, No. 12,
1990.5. R. Probert and K. Saleh, \Synthesis of Communication Protocols: Survey and
Assessment," IEEE Trans. on Computers, Vol. 40, No. 4, pp. 468{476, 1991.6. K. Saleh, \Synthesis of Communication Protocols: an Annotated Bibliography,"
ACM SIGCOMM Computer Communication Review, Vol. 26, No. 5, pp. 40{59,
1996.7. R. Gotzhein and G. v. Bochmann, \Deriving Protocol Speci�cations from Service
Speci�cations Including Parameters," ACM Trans. on Computer Systems, Vol. 8,
No. 4, pp. 255{283, 1990.8. R. Langerak, \Decomposition of Functionality; a Correctness-Preserving LOTOS
Transformation," Proc. of 10th IFIP WG6.1 Symp. on Protocol Speci�cation, Test-
ing and Veri�cation (PSTV-10), pp. 229{242, 1990.9. C. Kant, T. Higashino and G. v. Bochmann, \Deriving Protocol Speci�cations
from Service Speci�cations Written in LOTOS," Distributed Computing, Vol. 10,
No. 1, pp. 29{47, 1996.10. P. -Y. M. Chu and M. T. Liu, \Protocol Synthesis in a State-transition Model,"
Proc. of COMPSAC '88, pp. 505{512, 1988.11. T. Higashino, K. Okano, H. Imajo and K. Taniguchi, \Deriving Protocol Speci�-
cations from Service Speci�cations in Extended FSM Models," Proc. of 13th Int.
Conf. on Distributed Computing Systems (ICDCS-13), pp. 141{148, 1993.12. M. Nakamura, Y. Kakuda and T. Kikuno, \Component-based Protocol Synthesis
from Service Speci�cations," Computer Communications Journal, Vol. 19, No. 14,
pp.1200-1215, Dec. 1996.
187
13. K. Yasumoto, T. Higashino and K. Taniguchi, \Software Process Description Using
LOTOS and its Enaction," Proc. of the 16th Int. Conf. on Software Engineering
(ICSE-16), pp. 169-179, 1994.14. D. Y. Chao and D. T. Wang, \A Synthesis Technique of General Petri Nets,"
Journal of System Integration, Vol. 4, pp. 67{102, 1994.15. H. Yamaguchi, K. Okano, T. Higashino and K. Taniguchi, \Synthesis of Protocol
Entities' Speci�cations from Service Speci�cations in a Perti Net Model with Reg-
isters," Proc. of 15th Int. Conf. on Distributed Computing Systems (ICDCS-15),
pp. 510{517, 1995.16. H. Kahlouche and J. J. Girardot, \A Stepwise Requirement Based Approach for
Synthesizing Protocol Speci�cations in an Interpreted Petri Net Model," Proc. of
INFOCOM '96, pp. 1165{1173, 1996.17. A. Al-Dallal and K. Saleh, \Protocol Synthesis Using the Petri Net Model," Prof.
of 9th Int. Conf. on Parallel and Distributed Computing and Systems (PDCS'97),
1997.18. A. Khoumsi and K. Saleh, "Two Formal Methods for the Synthesis of Discrete
Event Systems," Computer Networks and ISDN Systems, Vol. 29, No. 7, pp. 759{
780, 1997.19. M. Kapus-Koler, \Deriving Protocol Speci�cations from Service Speci�cations with
Heterogeneous Timing Requirements," Proc. of 1991 Int. Conf. on Software Engi-
neering for Real Time Systems, pp. 266{270, 1991.20. A. Khoumsi, G. v. Bochmann and R. Dssouli, \On Specifying Services and Syn-
thesizing Protocols for Real-time Applications," Proc. of 14th IFIP WG6.1 Symp.
on Protocol Speci�cation, Testing and Veri�cation (PSTV-14), pp. 185{200, 1994.21. A. Khoumsi and G. v. Bochmann, \Protocol Synthesis Using Basic LOTOS and
Global Variables," Proc. of 1995 Int. Conf. on Network Protocols (ICNP'95), 1995.22. A. Nakata, T. Higashino and K. Taniguchi, \Protocol Synthesis from Timed
and Structured Speci�cations," Proc. of 1995 Int. Conf. on Network Protocols
(ICNP'95), pp. 74{81, 1995.23. H. Yamaguchi, K. Okano, T. Higashino and K. Taniguchi, \Protocol Synthesis
from Time Petri Net Based Service Speci�cations," Proc. of 1997 Int. Conf. on
Parallel and Distributed Systems (ICPADS'97), pp. 236{243, 1997.24. J. -C. Park and R. E. Miller, \Synthesizing Protocol Speci�cations from Service
Speci�cations in Timed Extended Finite State Machines," Proc. of 17th Int. Conf.
on Distributed Computing Systems (ICDCS-17), 1997.25. K. El-Fakih, H. Yamaguchi and G.v. Bochmann, \A Method and a Genetic Algo-
rithm for Deriving Protocols for Distributed Applications with Minimum Commu-
nication Cost," Proc. of the 11th IASTED Int. Conf. on Parallel and Distributed
Computing and Systems (PDCS'99), 1999.26. H. Yamaguchi, K. El-Fakih, G.v. Bochmann and T. Higashino, \A Petri Net Based
Method for Deriving Distributed Speci�cation with Optimal Allocation of Re-
sources," Proc. of the ASIC Int. Conf. on Software Engineering Applied to Net-
working and Parallel/ Distributed Computing (SNPD'00), pp. 19{26, 2000.27. S.S. Skiena, \The ALGORITHMDesign Manual," TELOS - The Electronic Library
of Science (A Springer-Verlag Imprint), 1998.28. Kellner, M. et al. : \ISPW-6 Software Process Example," Proc. of the 1st Int. Conf.
on the Software Process, pp. 176-186, 1991.29. \lp solve," ftp://ftp.ics.ele.tue.nl/pub/lp solve/
30. G. Rothermel and M. J. Harrold, \Analyzing Regression Test Selection Tech-
niques," IEEE Trans. on Software Engineering, Vol. 22, No. 8, pp. 529{551, 1996.
188