Awareness Requirements John Mylopoulos University of Trento Workshop on “Self- Adaptive Systems”

1. Awareness Requirements John Mylopoulos University of Trento Workshop on “Self- Adaptive Systems” Dagstuhl, Germany October 25-29, 2010

2. Adaptation is requirements-driven • Adaptation takes place when requirements are found to be partially/un-fulfilled. • We need some way of talking about “partial fulfillment” … • Several ways to go about it, such as: • Have relaxed versions of fulfillment, e.g., “as soon as possible”, “as close as possible” (RELAX, [Whittle09]) • Have fuzzy versions of fulfillment (FLAGS, [Baresi10]) • This talk offers yet-another way of talking about partial fulfillment of requirements …

3. Awareness • Awareness: Consciousness, sentience, ability to sense and respond to the environment. • Many types of awareness play a role in the design of software systems (security/process/context/location … ) • Important topic, not only in Computer Science. • In Philosophy, awareness plays a central role in several theories of consciousness. Our notion of awareness requirements draws on the distinction between higher-order awareness (awareness of one’s own mental states) and first-order awareness (awareness of things external) [Rosenthal05].

4. Awareness requirements (awReqs) • Refer to other requirements, i.e., Goals/Tasks/Quality Constraints/Domain Assumptions, and run-time properties thereof, i.e., success/failure/performance/consumption/ … • Consider • r = ‘schedule meeting’, da = ‘always rooms available’ • r1 = ‘r will be completed within 2hrs’ (delta) • r2 = ‘r won’t fail >3 times per year’ (aggregate) • r3 = ‘avg r time won’t increase between months’ (trend) • r4 = ‘da won’t fail >3 times per year’

5. Awareness vs vanilla requirements • Consider • r = ‘schedule meeting’ • r’ = ‘schedule meeting within 2hrs from request’ • r1 = ‘r will be completed within 2hrs’ • Semantically, r’ and r1 are (almost) equivalent, yet: • Default operationalization for r’ leads to a vanilla design (no monitoring, etc.), • The default for r1 leads to a design with full feedback. • In other words, reference to other requirements carries with it a modality: “watch this!”, which is what awareness means in the first place (“… ability to sense and respond to the environment.)

6. Get available rooms Collect timetables By system Schedule meeting Choose schedule By person By system By person Find rooms Collect Requirements Goal Softgoal “# Rooms available for Meetings” “From how Many” Good quality schedule AND AND AND AND FhM RfM + OR OR cp1 - cp3 OR cp2 OR OR >70% participation OR Rooms available -- Pre/Post-conditions Schedule Schedule Quality constraint Domain assumption Choice point Pre/Post-conditions Tasks

7. Get available rooms Schedule meeting Choose schedule Collect timetables By system Collect Requirements at run-time FhM=80% RfM=10 Good quality schedule AND AND AND AND OR OR Available rooms instanceOf Pre/Post-conditions

8. Object lifetimes: Goals • The possible states of each goal instance can be represented by a finite state machine (FSM). • Analogous FSMs describe the lifetimes of other requirement objects (QC, DA, T) Fulfilled Initiated Suspended Failed

9. Reactive Operationalizations • Default operationalization for an awareness requirement is a feedback loop consisting of Monitor, Diagnose, Reconcile, Compensate tasks. M D R C r

10. Specifications • For every assignment of values to each choice point and control parameter, we can generate a specification consisting of tasks, domain assumptions and quality constraints (i.e., functional+non-functional requirements) for the system-to-be. • Each such specification constitutes the signature (DNA, ground model1) of a solution/system-to-be that fulfills the requirements we started from.

11. Variability spaces • For every requirements problem, we find through goal analysis a variability spaceSpec(ChoicePt, ControlParam) that defines a space of possible behaviours for the adaptive system. • In fact, there is a hierarchy of variability spaces as we move from specifications to … to architectures to … to implementations. • A basic challenge for this community is to characterize such variability space hierarchies and develop adaptive mechanisms for shifting behaviours within and across layers.

12. From awReqs to feedback loops • The task at hand: develop systematic, tool-supported techniques so that, given a set of awareness requirements, we can generate monitoring, diagnostic, reconciliation and compensation functions in a systematic way. • We have developed those techniques for monitoring [Souza10], based on past work by Bill Robinson; will base our work on diagnosis and compensation on earlier work by Yiqiao Wang [Wang09a], [Wang09b]. • The hardest problem ahead of us is designing the reconciliation task of a feedback loop …

13. See you in

14. References • [Baresi10] Baresi, L., Pasquale, L., Spoletini, P., “Fuzzy Goals for Requirements-Driven Adaptation”, 19th International IEEE Conference on Requirements Engineering (RE’10), Sydney Australia, September 2010. • [Chung00] Chung, L., Nixon, B., Yu, E., Mylopoulos, J., Non-Functional Requirements in Software Engineering, Kluwer 2000. • [Feather98] Feather, M., Fickas, S., van Lamsweerde, A., Pounsard “Reconciling system requirements and runtime behavior”, 9th International Workshop on Software Specification and Design (IWSSD’98), Isobe Japan, April 1998. • [Fickas95] S. Fickas, S., Feather, M., “Requirements Monitoring in Dynamic Environments”, 2nd IEEE Int. Symposium on Requirements Engineering (RE’95), York, March 1995. • [Finkelstein08] Finkelstein, A., “Requirements Reflection”, workshop presentation, Schloss Dagstuhl seminar 08031: Software Engineering for Self-Adaptive Systems (2008), Wadern, Germany, http://www.dagstuhl.de/08031/ • [Robinson06] Robinson, W., “A Requirements Monitoring Framework for Enterprise Systems”, Requirements Engineering Journal 11(1), Springer-Verlag, 2006, 17-41. • [Robinson08] Robinson, W., “Extended OCL for Goal Monitoring”, Workshop on Modeling Systems with OCL, at MoDELS’07, Berlin, October 2007.

15. References (cont’d) • [Robinson09] Robinson, W, Purao, S., “Specifying and Monitoring Interactions and Commitments in Open Business Processes”, IEEE Software, March/April 2009, 2-9. • [Rosenthal05] Rosenthal, D., Consciousness and Mind, Oxford University Press, 2005. • [Souza09] Silva Souza, V., Mylopoulos, J., “Monitoring and Diagnosing Malicious Attacks with Autonomic Software”, 28th International Conference on Conceptual Modeling (ER’09), Gramado Brazil, November 2009. • [Souza10] Silva Souza, V., Lapouchnian, A., Robinson, W., Mylopoulos, J., “Awareness Requirements for Adaptive Systems”, Technical Report, Department of Information Engineering and Computer Science (DISI), University of Trento, September 2010, http://eprints.biblio.unitn.it/archive/00001893/. • [Wang09a] Wang, Y., McIlraith, S., Yu, Y., Mylopoulos, J., “Monitoring and Diagnosing Software Requirements”, Journal ofAutomated Software Engineering 16(1), Springer-Verlag, March 2009, 3-35. • [Wang09b] Wang, Y., Mylopoulos, J., “Self-repair Through Reconfiguration: A Requirements Engineering Approach”, 24nd IEEE/ACM International Conference on Automated Software Engineering (ASE’09), Auckland, New Zealand, November 2009. • [Whittle09] Whittle, J., Sawyer, P., Bencomo, N., and Cheng, B., “RELAX: Incorporating Uncertainty into the Specification of Self-Adaptive Systems,” Proceedings 17th IEEE International Requirements Engineering Conference (RE’09), Atlanta, September 2009.