Edinburgh, April Applicability of DEGAS Performance Analysis and exploitation opportunities MTCI Case Study Presented by Ivan Mura Motorola Global Software Group, ITALY DEGAS IST

Edinburgh, April Outline Case study performance requirements Exploiting DEGAS tools to optimize case study design Conclusions and future exploitation opportunities

Edinburgh, April MTCI Case study e-Commerce micro-businesses

Edinburgh, April Start HandshakeAuthenticate RetrieveListStartBasket SelectItemCheckAvailability available? abort? 0.25 no CancelAction 0.5yes AddItem 0.75 yes complete? purchase? Commit 0.5 no stop 0.5 no 0.5yes 0.9 yes 0.1 no Activity Diagram for Transaction Buyer steps –contact seller –authenticate –retrieve the list of sold items –select item –check availability –if item available, add is to basket or select a new one, or abort (probabilistic choice) –when selection complete, commit purchase (cancel option exists)

Edinburgh, April State Diagram for Transaction start HandshakeAuthenticate RetrieveList accepted StartBasket list_ok SelectItem initiated CheckAvailability selected AddItem available Commit Cancel continue unavailable_continue unavailable_stop cancel contacted Idle restart activate finalize complete Performance evaluation currently based on SD AD is translated into a corresponding SD Probabilistic choices are embedded into transition rates among states

Edinburgh, April Choreographer solution Performance profiling through steady-state probability distribution Reveals in which states the system will spend its time start Authenticate [7.707%] RetrieveList [13.873%] StartBasket [1.541%] SelectItem [24.665%] CheckAvailability [9.866%] AddItem [2.467%] Commit [33.310%] Cancel [0.369%] complete Idle [0.030%] Handshake [6.166%] activate restart contacted finalize cancel accepted list_ok initiated continue selected available unavailable_continue unavailable_stop interaction (supported by the wireless network) local processing (no interaction)

Edinburgh, April Deepening the analysis of results An analysis of the hitting times (see D26) indicates that the expected transation time will be of about 5.4 minutes The contribution of some interaction steps can be reduced with action on some parts of the Transaction design –the RetrieveList action could be realized through an interation with the server rather than with the seller –the CheckAvailability action could be executed just before the final Commit action, rather than after each item selection  both these two changes would reduce the number of wireless connections required to complete the Transaction

Edinburgh, April Activity Diagram for Transaction (revised) Start HandshakeAuthenticateRetrieveList (from server)StartBasket SelectItem CheckAvailability CancelAction AddItem complete? 0.5 no purchase? 0.5yes Commit 0.9 yes 0.1 no stop

Edinburgh, April State Diagram for Transaction (revised)

Edinburgh, April New Choreographer solution Start Idle [0.035%] RetrieveList [5.255%] activate Handshake [7.006%] list_ok Authenticate [8.757%] contacted StartBasket [1.751%] accepted SelectItem [31.533%] AddItem [4.204%] CheckAvailability [6.306%] complete Commit [34.677%] Cancel [0.473%] restart abort initiated selected continue finalize cleanup interaction (supported by the wireless network) local processing (no interaction) Redesigned solution limits the amount of time the user has to wait for data transmission over the wireless links The expected transation time is reduced to about 4.4 minutes (1 minute less than the previous solution)

Edinburgh, April Conclusions UML performance evaluation capabilities built by DEGAS offer an extremely useful tool for software development The Choreographer tool provides an immediate demonstration of the practical applicability of the DEGAS approach Benefits are achieved from several points of view –process: fostering a more conscious development approach that takes into account non functional requirements since the early stages of application design –methodological: spreading the usage of performance evaluation tools across a wider software development community exploiting UML as a vector –economical: limiting risks of non compliances with requirements, that turn out in increased costs and significant reworks and delays, as well as reducing the amount of validation test in later stages of software development

Edinburgh, April Further developments and exploitation Results developed within DEGAS represent a valuable starting point to the definition of UML-like design environments able to effectively support the development in a variety of application domains A number of extension points exist to plug in additional solvers for time computation (steady state and transient), early reliability and availability assessment features MTCI is already working for –addition of time computation features (steady-state and transient) –tailoring of the DEGAS solution to specific application domains such as the development of hardware/software of mobile phones and in-car integrated telecommunications systems, for which a huge potential market exist inside Motorola –development of a prototype software tool to support the design and early validation of performance and dependability requirements of mobile devices in collaboration with Politecnico of Torino