Hausi Müller - Towards Self-Adaptive Software-Intensive Systems


Published on

This set of slides was used by Prof. Hausi Müller for an invited talk given at the CHOOSE Forum 2008.

Published in: Education, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Hausi Müller - Towards Self-Adaptive Software-Intensive Systems

  1. 1. TOWARDS SELF-ADAPTIVE SOFTWARE-INTENSIVE SYSTEMS Hausi A. Müller University of Victoria, Canada Choose Forum 2008 Bern, Switzerland December 8, 2008
  2. 2. MY BACKGROUND <ul><li>Founding Director of Bachelor of Software Engineering </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>47 courses; 15 software engineering courses </li></ul></ul><ul><li>IBM Toronto </li></ul><ul><ul><li>Since 1991 </li></ul></ul><ul><ul><li>CSER/NSERC CRD Project: Design and Evolution of Autonomic Application Software </li></ul></ul><ul><ul><li>SOA and Service Oriented Programming Models </li></ul></ul><ul><li>CA Canada Inc. (formerly Computer Associates), Toronto </li></ul><ul><ul><li>Since 2005 </li></ul></ul><ul><ul><li>CSER/NSERC CRD Project: Logging, Monitoring and Diagnosis Systems for Enterprise Software Applications </li></ul></ul><ul><li>SEI (Software Engineering Institute), Pittsburgh </li></ul><ul><ul><li>Since 1995 </li></ul></ul><ul><ul><li>SOA and Service Oriented Computing </li></ul></ul><ul><ul><li>Ultra Large Scale Systems </li></ul></ul>
  3. 3. ENGINEERING SELF -ADAPTIVE SYSTEMS High degree of dynamism Goals / policies change at run-time Validation and verification performed at run-time Agility at run-time Müller, H.A.: SEAMS 2008 Panel—Report from Dagstuhl Seminar 08031 on Engineering Self-Adaptive Systems
  4. 4. VERY HIGH EXPECTATIONS FOR SELF-ADAPTABILITY <ul><li>Software systems must become more </li></ul><ul><ul><li>versatile, flexible, resilient, dependable </li></ul></ul><ul><ul><li>service-oriented, mashable, inter-operable, </li></ul></ul><ul><ul><li>continuously available, robust, decentralized, </li></ul></ul><ul><ul><li>energy-efficient, recoverable, customizable, </li></ul></ul><ul><ul><li>configurable, self-healing, configurable, </li></ul></ul><ul><ul><li>self-optimizing, self-*, … </li></ul></ul><ul><li>by adapting to changing operational contexts and environments </li></ul>
  5. 5. OUTLINE <ul><li>Motivation for self-adaptive systems </li></ul><ul><li>Challenges in SOA governance </li></ul><ul><li>Realizing self-adaptive systems using feedback loops </li></ul><ul><li>Maintainability of self-adaptive systems </li></ul><ul><li>Research challenges </li></ul>
  6. 6. RISE OF THE DYNAMIC VALUE SET <ul><li>The value chains of today are the result of linked individual business tasks that come together to form a valuable end product </li></ul><ul><ul><li>Just like a physical assembly line, each participant in the value chain contributes something to increase the value of the end product </li></ul></ul><ul><ul><li>Although these value chains have become increasingly distributed, they still tend to be predictable, structured and linear </li></ul></ul><ul><li>Set of service providers is changing dynamically based on who is in the best position to perform a given task at a given time </li></ul><ul><ul><li>Service providers are becoming interconnected to the point that mapping their relationships yields more of a net than the traditional linear chain </li></ul></ul><ul><ul><li>Familiar value chains are morphing into dynamic value nets </li></ul></ul><ul><li>Value nets are orchestrated by the organization that delivers the end product to market </li></ul><ul><ul><li>This orchestration may be the lead brand organization’s unique value add </li></ul></ul>Steve Mills, VP IBM Software Group: The Future of Business, White Paper, June 2007
  7. 7. IBM GLOBAL SERVICES SERVICE INTEGRATION MATURITY MODEL (SIMM) <ul><li>Ultimate goal: dynamically configurable services </li></ul>
  8. 8. SELF-ADAPTIVE SYSTEMS: ANTICIPATED AND UN-ANTICIPATED ADAPTATION <ul><li>Anticipated adaption </li></ul><ul><ul><li>The different contexts to be accommodated at run-time are known at design-time </li></ul></ul><ul><li>Un-anticipated adaption </li></ul><ul><ul><li>The variation possibilities are recognized and computed at run-time </li></ul></ul><ul><ul><li>The decision which variant is best is computed using self-awareness and environmental context information </li></ul></ul><ul><li>Pure un-anticipated self-adaptive system are rare </li></ul><ul><ul><li>Most self-adaptive systems feature a combination of anticipated self-adaptation and un-anticipated self-adaptation </li></ul></ul>
  10. 10. KEY PERFORMANCE INDICATORS (KPI) AND QUALITY-OF-SERVICE INDICATORS XML and Web Services Unleashed, SAMS Publishing Instrumenting all Levels for Indicators
  11. 11. SOA GOVERNANCE <ul><li>Governance has been rated as the main inhibitor of SOA adoption </li></ul><ul><li>SOA governance provides a set of policies, rules, and enforcement mechanisms for developing, using and evolving service-oriented systems, and for analysis of their business value </li></ul><ul><li>SOA governance includes policies, procedures, roles and responsibilities for design-time governance and runtime governance </li></ul>G. Lewis, D. Smith: SOA and its Implications for Software Maintenance and Evolution, ICSM FoSM 2008
  12. 12. SOA GOVERNANCE TYPES <ul><li>Design-time governance </li></ul><ul><ul><li>Includes elements such as rules for strategic identification of services, development, and deployment of services; reuse; and legacy system migration to services </li></ul></ul><ul><ul><li>Enforces consistency in use of standards, SOA infrastructure and processes </li></ul></ul><ul><li>Run-time governance </li></ul><ul><ul><li>Enforces rules to ensure that services are executed only in ways that are legal and that important runtime data is logged </li></ul></ul><ul><ul><li>Service level agreements (SLAs) including runtime validation of contractual specifications on performance, throughput, and availability; the use of automated metrics for tracking and reporting; and problem management </li></ul></ul>G. Lewis, D. Smith: SOA and its Implications for Software Maintenance and Evolution, ICSM FoSM 2008
  14. 14. Continuous Evolution Problems
  15. 15. ULS CHALLENGES APPLY TO SOA <ul><li>The ULS book describes challenges in three broad areas: </li></ul><ul><ul><li>Design and evolution </li></ul></ul><ul><ul><li>Orchestration and control </li></ul></ul><ul><ul><li>Monitoring and assessment </li></ul></ul><ul><li>The challenges in all three areas apply readily to the maintenance and evolution of SOA systems and in particular to the issues of governance </li></ul>L. Northrop et al.: Ultra-Large-Scale Systems: The Software Challenge of the Future, SEI Tech Report, June 2006
  16. 16. SPECIFIC CHALLENGES IN GOVERNANCE SYSTEM MONITORING AND ASSESSMENT <ul><li>With respect to governance </li></ul><ul><ul><li>How do we evaluate the effectiveness of SOA system design, operation, evolution, orchestration, and control? </li></ul></ul><ul><ul><li>How do we monitor and assess system state, behavior, and overall health and well being? </li></ul></ul><ul><li>Challenges include </li></ul><ul><ul><li>Defining indicators </li></ul></ul><ul><ul><li>Understanding why indicators change </li></ul></ul><ul><ul><li>Prioritizing the indicators (e.g., to form a hierarchy) </li></ul></ul><ul><ul><li>Handling change and imperfect information </li></ul></ul><ul><ul><li>Gauging the human elements </li></ul></ul>
  17. 17. SPECIFIC CHALLENGES FOR SYSTEM MONITORING AND ASSESSMENT <ul><li>Defining indicators </li></ul><ul><ul><li>What system-wide, end-to-end, and local quality-of-service indicators are relevant to meeting user needs and ensuring the long-term viability of the SOA subject system? </li></ul></ul><ul><li>Understanding why indicators change </li></ul><ul><ul><li>What adjustments or changes to system elements and interconnections will improve or degrade these indicators? </li></ul></ul><ul><li>Prioritizing the indicators </li></ul><ul><ul><li>Which indicators should be examined under what conditions? </li></ul></ul><ul><ul><li>Are indicators ordered by generality? </li></ul></ul><ul><ul><ul><li>General overall health reading versus specialized particular diagnostics </li></ul></ul></ul>
  18. 18. SPECIFIC CHALLENGES FOR SYSTEM MONITORING AND ASSESSMENT <ul><li>Handling change and imperfect information </li></ul><ul><ul><li>How do the monitoring and assessment processes handle continual changes to components, services, usage, or connectivity? </li></ul></ul><ul><ul><li>Imperfect information can be inaccurate, stale, or imprecise. </li></ul></ul><ul><li>Gauging the human elements </li></ul><ul><ul><li>What are the indicators of the health and performance of the people, business, and organizational elements of the SOA subject system? </li></ul></ul>
  19. 19. BRIEF SIDE NOTE ... COMPLIANCE VS. CONFORMANCE <ul><li>Compliance implies adherence to a standard or regulation </li></ul><ul><ul><li>You either pass or fail </li></ul></ul><ul><ul><li>A company can be in compliance with Sarbanes-Oxley auditing requirements </li></ul></ul><ul><ul><li>A browser can comply with a specific security requirement by providing 128-bit security and TLS encryption </li></ul></ul><ul><ul><li>Service delivery is compliant with an SLA </li></ul></ul><ul><li>Conformance describes how well a given implementation matches or does not match a standard or a reference </li></ul><ul><ul><li>A conformance testing suite that returns results that certain aspects of an implementation match a reference implementation </li></ul></ul><ul><ul><li>A Web services implementation can conform with the WS-I basic interoperability profile </li></ul></ul><ul><ul><li>Service delivery is conformance with an SLA depends on the importance of the customer </li></ul></ul><ul><li>A lack of conformance does not necessarily imply a value judgment the way that lack of compliance with a law or regulation does </li></ul>Keep in mind: Whenever we talk about “compliance,” we often really mean “conformance.”
  20. 20. MONITORING DYNAMICAL SYSTEMS <ul><li>Perform critical regression tests dynamically to observe satisfaction of requirements </li></ul><ul><ul><li>Testing run-time (and design-time) governance </li></ul></ul><ul><ul><li>Govern and enforce rules and regulations </li></ul></ul><ul><li>Perform V&V operations (transformations) regularly to ascertain V&V properties </li></ul><ul><ul><li>Monitor compliance and conformance </li></ul></ul><ul><ul><li>Assess whether services are used properly </li></ul></ul><ul><ul><li>Recognizing normal and exceptional behaviour </li></ul></ul><ul><li>Monitor functional and non-functional requirements when the environment evolves </li></ul><ul><ul><li>SLAs </li></ul></ul><ul><ul><li>Assess and maintain quality of service (QoS) </li></ul></ul><ul><ul><li>Manage tradeoffs </li></ul></ul>
  21. 21. CHANGE OF PERSPECTIVE <ul><li>From satisfaction of requirements through traditional, top-down engineering </li></ul><ul><li>To satisfaction of requirements by regulation of complex, decentralized systems </li></ul>With adaptive systems and feedback loops  How? The system shall do this … but it may do this … as long as it does this …
  22. 22. BIOLOGICAL SYSTEMS <ul><li>The internal mechanisms of humans continuously work together to maintain essential variables within physiological limits—the n-dimensional viability zone </li></ul><ul><li>The goal of human self-managing behavior is directly linked to survivability </li></ul><ul><ul><li>If the external or internal environment pushes the system outside its physiological equilibrium zone, the system will work towards returning to the equilibrium zone </li></ul></ul>n-dimensional viability zone equilibrium
  23. 23. MOST FAMOUS FEEDBACK SYSTEM AUTONOMIC NERVOUS SYSTEM (ANS) <ul><li>Autonomic nervous system (ANS) </li></ul><ul><li>Parasympathetic </li></ul><ul><ul><li>Day-to-day internal processes </li></ul></ul><ul><li>Sympathetic </li></ul><ul><ul><li>Stressful situation processes </li></ul></ul>Temperature Heart rate Breathing rate Blood pressure Blood sugar Pupil dilation Tears Digestion Immune response Decide Resource Measure Control Monitor and regulate
  24. 24. FEEDBACK SYSTEMS <ul><li>Merriam-Webster’s Online Dictionary the return to the input of a part of the output of a machine, system, or process </li></ul><ul><ul><li>producing changes in an electronic circuit to improve performance </li></ul></ul><ul><ul><li>an automatic control device to provide self-corrective action </li></ul></ul>
  25. 25. APPROACH: FEEDBACK LOOP Dobson, S. et al.: A Survey of Autonomic Communications. ACM Trans. on Autonomous and Adaptive Systems (TAAS) 1(2):223-259 (2006)
  27. 27. HIERARCHY OF AUTONOMIC ELEMENTS TO ORCHESTRATE INDICATORS; ACRA IBM: An Architectural Blueprint for Autonomic Computing, 4th Ed. (2006)
  28. 28. REALIZATION OF A DYNAMIC ARCHITECTURE <ul><li>Feedback control system with disturbance and noise input </li></ul>Hellerstein, Diao, Parekh, Tilbury: Feedback Control of Computing Systems. John Wiley & Sons (2004)
  29. 29. REALIZATION OF A DYNAMIC ARCHITECTURE <ul><li>Reference input </li></ul><ul><ul><li>Goal, objectives, specified desired output </li></ul></ul><ul><li>Control Error </li></ul><ul><ul><li>Reference input minus (measured) transduced output </li></ul></ul><ul><li>Control Input </li></ul><ul><ul><li>Parameters which affect behavior of the system—number of threads, CPU, memory, parameters </li></ul></ul><ul><li>Disturbance input </li></ul><ul><ul><li>Affects control input—arrival rate </li></ul></ul><ul><li>Controller </li></ul><ul><ul><li>Change control input to achieve reference input—design is based on a model of the managed system </li></ul></ul><ul><li>Managed system </li></ul><ul><ul><li>Dynamical system, process, plant—often characterized by differential equations </li></ul></ul><ul><li>Measured output </li></ul><ul><ul><li>Measurable feature of the system—response time </li></ul></ul><ul><li>Noise input </li></ul><ul><ul><li>Affects measured output </li></ul></ul><ul><li>Transducer </li></ul><ul><ul><li>Transforms measured output to compare with reference input </li></ul></ul>Hellerstein, Diao, Parekh, Tilbury: Feedback Control of Computing Systems. John Wiley & Sons (2004)
  30. 30. ADAPTIVE CONTROL <ul><li>Modify the control law to cope by changing system parameters while the system is running </li></ul><ul><li>Different from Robust Control in the sense that it does not need a priori information about the uncertainties </li></ul><ul><ul><li>Robust Control includes the bounds of uncertainties in the design of the control law. </li></ul></ul><ul><ul><li>Thus, if the system changes are within the bounds, the control law needs no modification. </li></ul></ul>
  31. 31. SYSTEM IDENTIFICATION MODEL BUILDING <ul><li>Mathematical tools and algorithms to build dynamical models from measured data </li></ul><ul><li>A dynamical mathematical model in this context is a mathematical description of the dynamic behavior of a system or process in either the time or frequency domain </li></ul><ul><li>Theories and processes </li></ul><ul><ul><li>Physical </li></ul></ul><ul><ul><li>Computing </li></ul></ul><ul><ul><li>Social </li></ul></ul><ul><ul><li>Engineering </li></ul></ul><ul><ul><li>Economic </li></ul></ul><ul><ul><li>Biological </li></ul></ul><ul><ul><li>Chemical </li></ul></ul><ul><ul><li>Therapeutic </li></ul></ul>
  32. 32. MODEL REFERENCE ADAPTIVE CONTROLLERS—MRAC <ul><li>Also referred to as Model Reference Adaptive System (MRAS) </li></ul><ul><li>Closed loop controller with parameters that can be updated to change the response of the system </li></ul><ul><li>The output of the system is compared to a desired response from a reference model (e.g., simulation model) </li></ul><ul><li>The control parameters are updated based on this error </li></ul><ul><li>The goal is for the parameters to converge to ideal values that cause the managed system response to match the response of the reference model. </li></ul>
  35. 35. MODEL IDENTIFICATION ADAPTIVE CONTROLLERS—MIAC <ul><li>Perform system identification while system is running to modify the control laws </li></ul><ul><ul><li>Create model structure and perform parameter estimation typically using the Least Squares method </li></ul></ul><ul><li>Cautious adaptive controllers </li></ul><ul><ul><li>Use current system identification to modify control law, allowing for system identification uncertainty </li></ul></ul><ul><li>Certainty equivalent adaptive controllers </li></ul><ul><ul><li>Take current system identification to be the true system, assume no uncertainty </li></ul></ul>
  38. 38. MIAC AND MRAC ARCHITECTURES FOR DYNAMICAL COMPUTING SYSTEMS <ul><li>The goal of both approaches is to adjust the control laws in the controller </li></ul><ul><li>MRAC approach </li></ul><ul><ul><li>reference model is static—given or pre-computed and not changed at run-time </li></ul></ul><ul><li>MIAC approach </li></ul><ul><ul><li>reference model is changed at run-time using system identification methods </li></ul></ul>
  39. 39. MAINTAINABILITY CONCERNS <ul><li>How different are the maintainability concerns for self-adaptive SOA systems compared to static, non-adaptive SOA systems? </li></ul><ul><li>Is a SOA system that is designed for dynamic variability or adaptation easier to maintain? </li></ul>Control-Centric Design and Views
  40. 40. RESEARCH CHALLENGES <ul><li>Model construction </li></ul><ul><li>Managing and leveraging uncertainty </li></ul><ul><li>Making control loops explicit </li></ul>
  41. 41. RESEARCH CHALLENGES: MODEL CONSTRUCTION <ul><li>The process of designing feedback-based computing systems requires the construction of models which quantify the effect of control inputs on measured outputs </li></ul><ul><ul><li>While performance engineering and queuing theory have developed advanced models for many different applications, we need models for many other quality-of-service indicators that come into play in dynamical applications </li></ul></ul><ul><ul><li>For some of these criteria (e.g., trust) quantification is difficult </li></ul></ul><ul><ul><li>What system-wide, end-to-end, and local quality-of-service indicators are relevant to meeting user needs? </li></ul></ul><ul><li>Models are also needed to design trade-off analyses schemes for combinations of quality-of-service indicators </li></ul><ul><li>Developing feedback models for quality-of-service indicators for various application domains is a major challenge </li></ul><ul><ul><li>Models and quality-of-service indicators related to governance, compliance, and service-level agreements are of particular importance for service-oriented business processes and applications </li></ul></ul>
  42. 42. RESEARCH CHALLENGES: MANAGING AND LEVERAGING UNCERTAINTY <ul><li>When we model potential disturbances from the environment of an SOA system (e.g., unexpected saturation of the network) or satisfy requirements by regulation (i.e., trade-off analysis among several extra-functional requirements), we introduce some uncertainty </li></ul><ul><li>Therefore, designers and maintainers of such dynamical systems should manage uncertainty because the environment may change in unexpected ways and, as a result, the system may adapt in such a way that was not foreseeable at design time </li></ul><ul><li>Introducing uncertainty requires trade-offs between flexibility and assurance </li></ul><ul><li>For a maintainer it is critical to know which parts of the environment are assumed to be fixed and which are expected to introduce uncertainty </li></ul><ul><li>Moreover, assurance and compliance criteria should be continuously validated at run-time—not just at system acceptance time </li></ul><ul><li>Thus, understanding, managing, and leveraging uncertainty is important for delivering SOA systems with reliability and assurance guarantees </li></ul>
  43. 43. RESEARCH CHALLENGES: MAKING CONTROL LOOPS EXPLICIT <ul><li>Investigate architecture-centric vs. control-centric design and run-time views for SOA systems </li></ul><ul><li>Software engineers are trained to develop abstractions that hide complexity </li></ul><ul><li>Designers of SOA systems will likely realize significant benefits by raising the visibility of control loops and specifying the major components and characteristics of the control loops explicitly </li></ul><ul><ul><li>When arrangements of multiple control loops interact, system design and analysis should cover their interactions </li></ul></ul><ul><ul><li>As control grows more complex, it is important for the control loops to be explicit in design and analysis </li></ul></ul><ul><li>Investigate the trade-offs between hiding the complexity of feedback loops and treating feedback loops as first class objects with respect to the construction and operation of SOA systems </li></ul><ul><li>Further benefits could be realized by identifying common forms of adaptation and then distilling design and V&V obligations </li></ul>
  44. 44. CONCLUSIONS <ul><li>Changes in traditional value chains are giving rise to interconnected, dynamic value nets </li></ul><ul><li>To be able to observe and possibly orchestrate the continuous evolution of dynamical systems in a complex and changing environment, we need to push the monitoring of evolving systems to unprecedented levels </li></ul><ul><li>Monitoring dynamical systems using feedback loops </li></ul><ul><ul><li>Make feedback loops explicit and first class </li></ul></ul><ul><li>Architecture-centric vs. control-centric orchestration </li></ul><ul><ul><li>Recognize the limitations of evolutionary developments </li></ul></ul><ul><li>Combination of anticipated and un-anticipated adaptation </li></ul><ul><li>Instrument systems from the ground up for KPIs </li></ul><ul><li>Maintainability concerns for self-adaptive systems compared to static, non-adaptive systems </li></ul>
  45. 45. TO PROBE FURTHER <ul><li>Hellerstein, J.L., Diao, Y., Parekh, S., Tilbury, D.M.: Feedback Control of Computing Systems. John Wiley & Sons (2004) </li></ul><ul><li>Northrop, L., et al.: Ultra-Large-Scale Systems. The Software Challenge of the Future. SEI Tech Report, 134 pages, ISBN 0-9786956-0-7 (2006) </li></ul><ul><li>Lewis, G., Smith, D.: SOA and its Implications for Software Maintenance and Evolution, ICSM FoSM (2008) </li></ul><ul><li>Mills, S.: The Future of Business, White Paper (2007) </li></ul><ul><li>IBM: An Architectural Blueprint for Autonomic Computing, 4 th Ed. (2006) </li></ul><ul><li>Huebscher, M.C., McCann, J.A.: A Survey of Autonomic Computing—Degrees, Models, and Applications. ACM Computing Surveys, 40 (3):7:1-28 (2008) </li></ul><ul><li>Dobson, S., Denazis, S., Fernandez, A., Gaiti, D., Gelenbe, E., Massacci, F., Nixon, P., Saffre, F., Schmidt, N., Zambonelli, F.: A Survey of Autonomic Communications. ACM TAAS 1(2):223-259 (2006) </li></ul><ul><li>Diao, Y., Hellerstein, J.L., Parekh, S., Griffith, R., Kaiser, G.E., Phung, D.: A Control Theory Foundation for Self-Managing Computing Systems. IEEE Journal on Selected Areas in Communications 23(12):2213-2222 (2005) </li></ul><ul><li>Müller, H.A., Pezzè, M., Shaw, M.: Visibility of Control in Adaptive System. In: 3rd ACM/IEEE International ICSE ULSSIS 2008, pp. 23-26 (2008) </li></ul>
  46. 46. MARK YOUR CALENDARS HOPE TO SEE YOU ALL IN CANADA IN 2009 <ul><li>ICSE 2009—May 16-24 </li></ul><ul><ul><li>ACM/IEEE International Conference on Software Engineering (ICSE), Vancouver, British Columbia </li></ul></ul><ul><li>ICSM 2009—September 20-26 </li></ul><ul><ul><li>IEEE International Conference on Software Maintenance (ICSM), Edmonton, Alberta </li></ul></ul>
  47. 47. SEAMS 2009 <ul><ul><li> </li></ul></ul><ul><li>ACM/IEEE Software Engineering for Adaptive and Self-Managing Systems </li></ul><ul><ul><li>Two-Day ICSE Workshop </li></ul></ul><ul><ul><li>Mon/Tue, May 18-19, 2009 </li></ul></ul><ul><ul><li>Vancouver, British Columbia, Canada </li></ul></ul><ul><li>Important Dates </li></ul><ul><ul><li>Submission deadline: Saturday, January 26, 2009 </li></ul></ul><ul><ul><li>Camera ready copy: Thursday, February 19, 2009 </li></ul></ul><ul><li>General Chair </li></ul><ul><ul><li>Hausi A. Müller, University of Victoria, Canada </li></ul></ul><ul><li>Program Chair </li></ul><ul><ul><li>Jeff Magee, Imperial College, UK </li></ul></ul>
  48. 48. VISSOFT 2009 <ul><li>IEEE International Workshops on Visualizing Software for Understanding and Analysis </li></ul><ul><ul><li>Two-Day Workshop collocated with ICSM 2009 </li></ul></ul><ul><ul><li>Fri/Sat, September 25-26, 2009 </li></ul></ul><ul><ul><li>Edmonton, Alberta, Canada </li></ul></ul><ul><li>General Chair </li></ul><ul><ul><li>Hausi A. Müller, University of Victoria, Canada </li></ul></ul><ul><li>Program Chair </li></ul><ul><ul><li>Michele Lanza, University of Lugano, Switzerland </li></ul></ul><ul><ul><li>Margaret-Anne Storey, University of Victoria, Canada </li></ul></ul>