1 / 22

Intensive Instrumentation and Monitoring for Software Ecosystems

Intensive Instrumentation and Monitoring for Software Ecosystems. Hausi A. Müller Department of Computer Science University of Victoria Dagstuhl Seminar Nº 08031 Software Engineering for Self-Adaptive Systems January 2008. Reverse Engineering and Migration Technology.

mardi
Download Presentation

Intensive Instrumentation and Monitoring for Software Ecosystems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Intensive Instrumentationand Monitoring forSoftware Ecosystems Hausi A. MüllerDepartment of Computer ScienceUniversity of Victoria Dagstuhl Seminar Nº 08031Software Engineering for Self-Adaptive SystemsJanuary 2008

  2. Reverse EngineeringandMigration Technology Autonomic Computing Technology Self-* Adaptive Software Ecosystems Multiple Control Loops Intensive Instrumentation and Monitoring for Software Ecosystems 2

  3. Despite enormous successes in migrating legacy systems to modern platforms, dealing with legacy software systemsdoes not seem to get any easier!! So, what is the problem? 3

  4. The Automation Conundrum • Over the past 50 years, computer systems have had a huge capacity to automate • Enormous variety of tasks • Cost per task greatly reduced • Incalculable benefits • Unprecedented success • Key challenges • Further declines in task costs by traditional are subject to the law of diminishing returns • The complexity of infrastructure management threatens to outweigh the benefits of further automation A. Spector, VP IBM Services and Software Research, 2003 4

  5. Evolution of Software Systems • Legacy systems are migrating tomodern platforms • Integration ofSoftware-Intensive Systems (ISIS) • http://www.sei.cmu.edu/isis/ • Systems of Systems • Enterprise integration • Dynamic systems • http://www.sei.cmu.edu/programs/ds/ 5

  6. Evolution of Software Systems • Legacy systems • Systems of Systems • Ultra-Large-Scale(ULS) Systems • Software Ecosystems 6

  7. Continuous Evolution • Flawed assumption: software systems should • support organizational stability and structure • be low maintenance • strive for high degrees of user acceptance • Continuous evolution: software systems • should be under constant development • can never be fully specified • are subject to constant adjustment and adaptation [Truex99] • Good news • for software engineering community (adaptive and reverse engineering in particular) since this view guarantees research problems for years to come • Bad news • most software engineering textbooks will have to be rewritten Truex et al., Growing Systems in Emergent Organizations, CACM, 1999 7

  8. Independent Studies Confirm the Notion of Continuous Evolution • German SE Manifest [Broy06] • Challenges for Software Engineering Research • ICSE 2006 Keynote [Boehm06] • SE theses and antitheses for every decade from 1950 to 2020 • He argues that “the ability of organizations and their products, systems, and services to compete, adapt, and survive will depend increasingly on software and on the ability to integrate related software-intensive systems into systems of systems.” • SEI ULS [ULS06] • Systems of systems are likely to evolve into Ultra-Large-Scale (ULS) socio-technical ecosystems • ULS ecosystems require a radically new perspective with respect to design and evolution, orchestration and control, as well as monitoring and assessment. • SEI study suggests that traditional top-down engineering approaches are insufficient to tackle the complexity and evolution problems inherent in decentralized, continually evolving software 8

  9. Ultra-Large-Scale (ULS) Systems • Premise • ULS systems will place an unprecedented demand on software acquisition, production, deployment, management, documentation, usage, and evolution • Needed • A new perspective on how to characterize the problem and realize solutions • Breakthrough research in concepts, methods, and tools beyond current hot topics such as SOA or MDA • Proposal • New solutions involving the intersections of traditional software engineering and other disciplines including fields concerned with people—microeconomics, biology, city planning, anthropology L. Northrop et al., SEI, Ultra-Large-Scale Systems, June 2006 9

  10. Decentralized Ecosystems • For 40 years we have embraced the traditional centralized engineering perspective for building software • Central control, top-down, tradeoff analysis • Beyond a certain complexity threshold, traditional centralized engineering perspective is no longer adequate nor can it be the primary means by which ultra-complex systems are made real • Firms are engineered—but the structure of the economy is not; yet it adapts • The protocols of the Internet were engineered—but not the Web as a whole; and yet it adapts • Ecosystems exhibit high degrees of complexity, organization and adaptability—but not through top-down engineering L. Northrop et al., SEI, Ultra-Large-Scale Systems, June 2006 10

  11. With adaptive systemsand feedback loops  How? Change of Perspective • Fromsatisfaction of requirements through traditional, top-down engineering • To satisfaction of requirements by regulation of complex, decentralized systems The system shall do this … but it may do this … as long as it does this … 11

  12. From Buildings to Cities • A ULS system will operate more like a city • built or conceived by many individuals over long periods of time (Rome) • the form of the city is not specified by requirements, but loosely coordinated and regulated—zoning laws, building codes, economic incentives (change over time) • Every day in every city construction is going on, repairs are taking place, modifications are being made—yet, the cities continue to function • ULS systems will not simply be bigger systems: they will be interdependent webs of software-intensive systems, people, policies, cultures, and economics SEI, Ultra-Large-Scale Systems, June 2006 12

  13. Characteristics of ULS Systems • Decentralized control • Inherently conflicting, unknowable, and diverse requirements • Continuous evolution and deployment • Heterogeneous, inconsistent, and changing elements • Erosion of the people/system boundary • Software and hardware failures are the norm 13

  14. Challenges in ULS Systems • Design and evolution • Rules and regulations • Enforcement mechanisms and processes • Integration • Emergent quality and behaviour • Orchestration and Control • Online modification • Maintenance of quality and service • Creation and execution of policies and rules • Adaptation to users and contexts • Enabling user controlled orchestration • Monitoring and Assessment • Defining indicators • Understanding why indicators change • Handling change and imperfect information • Gauging the human elements http://www.sei.cmu.edu/uls/ 14

  15. Unprecedented Levels of Monitoring • To be able to observe and possibly orchestrate the continuous evolution of software systems in a complex and changing environment, we need to push the monitoring of evolving systems to unprecedented levels • Instrument software-intensive systems with autonomic elements using reverse engineering technology to enhance their monitoring and assessment capabilities 15

  16. Analyze Plan Monitor Execute Knowledge Sensors Effectors Sensors Effectors How to simplify software? • Historically, in contrast to engineering disciplines, computing science seems to have neglected the control loop • To simplify programs,inject control loops or autonomic elementsinto ordinary programs • Self-advertising infrastructure components [Chris Craddock, CA] 16

  17. Autonomic Program Monitors • Run-time check monitors • Monitor assertions and invariants • Monitor frequency of raised exceptions • Continually measure test coverage • Data structure load balancing • Buffer overflows, intrusion • Memory leaks • Checking liveness properties 17

  18. Satisfaction of Requirements • Monitor the satisfaction of requirements • Perform critical regression tests regularly to observe satisfaction of requirements • Perform V&V operations (transformations) regularly to ascertain V&V properties • How to monitor functional and non-functional requirements when the environment evolves? 18

  19. Design programs with the Autonomic Element as a Core Architectural Component Teach the notion of a Control Loopin 1st Year of Computer Science (and Engineering) M. Shaw. Beyond Objects: A Software Design Paradigm based on Process Control, ACM SIGSOFT Software Engineering Notes, 20(11):27–38, 1995 19

  20. Challenge for our community • To instrument software systems with manageability endpoints—sensor and effectors • To monitor software systems and their environments at unprecedented levels 20

  21. Temperature Heart rate Breathing rate Blood pressure Blood sugar Pupil dilation Tears Digestion Immune response Control Decide Resource Measure The Most Famous Autonomic System Autonomic Nervous System─ANS • Parasympathetic • Day-to-day internal processes • Sympathetic • Stressful situation processes Monitor and Regulate 21

  22. Reverse EngineeringandMigration Technology Autonomic Computing Technology Self-* Adaptive Software Ecosystems Multiple Control Loops Intensive Instrumentation and Monitoring for Software Ecosystems 22

More Related