Software Engineering for Self-Adaptive Systems (Wintersemester 2017/2018)
Dozent: Prof. Dr. Holger Giese
(Systemanalyse und Modellierung)
(Systemanalyse und Modellierung)
(Modellierung softwareintensiver Systeme)
Software systems can be challenging to handle regarding their complexity, evolution of their requirements and uncertainty in their environments. This has led the software engineering community to look in diverse related fields to get inspired for new ways to design and manage complex systems and their evolution. In this endeavor, fields such as robotics, artificial intelligence, control theory, and biology have been a source of inspiration.
The important concern for modern software systems is to become more cost-effective, while being versatile, flexible, resilient, self-healing , energy-efficient, customizable, configurable and self-optimizing when reacting to run-time changes. Self-adaptation as a mean to achieve such properties has become one of the most promising directions. In particular, self-adaptive systems should be able to modify their behavior and/or structure in response to their perception of the environment and the system itself, and their goals. (cf. [1,2,3]).
The landscapes of software engineering domains are constantly evolving. In particular, software has become the bricks and mortar of many complex systems that are composed of interconnected parts. Often the overall system exhibits properties not obvious from the properties of the individual parts. Extreme cases for such complex systems are ultra-large-scale (ULS) systems or system of systems (SoS). In such systems, self-adaptation, self-organization, and emergent behavior are unavoidable. In order for the evolution of software engineering techniques to keep up with these dynamic landscapes, the systems must be built in such a manner that they are able to adapt to their ever-changing surroundings. For sufficiently complex systems, these adaptations must necessarily happen autonomously.
Self-adaptive systems can be characterized by how they operate or how they are analyzed. Properties such as centralized or decentralized as well as top-down or bottom-up are commonly used to characterize self-adaptive systems. A top-down self-adaptive system is often centralized and operates with the guidance of a central controller or policy. Such a system reasons about its own behavior in the current surroundings, and adapts itself if the monitoring and analysis warrants it. A top-down self-adaptive system often operates with an explicit internal representation of itself and its global goals. By analyzing the components of a top-down self-adaptive system, one can synthesize and deduce the behavior of the whole system. In contrast, a cooperative self-adaptive system or self-organizing system is often decentralized, operates without a central authority, and is typically composed bottom-up of a large number of components that interact locally according to simple rules. The global behavior of the system emerges from these local interactions. It is difficult to deduce properties of the global system by analyzing only the local properties of its parts. Such systems do not necessarily use internal representations of global properties or goals; they are often inspired by biological or sociological phenomena. Most engineered and nature-inspired self-adaptive systems fall somewhere between these two extreme ends of the spectrum of self-adaptive system types. In practice, the line between these types is rather blurred and compromises will often lead to an engineering approach incorporating techniques from both of these two ends. For example, ultra-large-scale (ULS) systems embody both top-down and bottom-up self-adaptive characteristics (e.g., the Web is basically decentralized as a global system, but local sub-webs are highly centralized or server farms are both centralized and decentralized).
In this lecture we will discuss how to build self-adaptive software systems cost-effectively. We will review existing theories, methods, and techniques for their software engineering. We will cover all life-cycle phases and in particular the necessary adjustments for existing engineering activities as well as novel activities that become necessary.
As part of this lecture, the students will conduct a project to gain hands-on experience of the concepts discussed in the lecture. They will build a self-adaptive software by adding self-adaptation capabilities to an existing adaptable software (ie. mRUBiS, an online marketplace) and enabling certain properties. The project will consist of two parts, in which students experiment and evaluate different concepts and have a deeper realization of the practical perspectives of the concepts.
- 08.01 is the deadline for the first milestone of task(I)
- Lecture restarts On 09.01
- On 16.01 and 17.01 there will be no lecture. (potential slots to discuss the project)
- The deadline for task (I) is on the 22.01.
- On the 23.01, there is no lecture and instead task (II) for the project will be presented.
- No lecture on 24.01 and 29.01.
- 31.01 will be the final lecture during which the date for the final examination and deadline of the project will be decided as well.
 B.H.C. Cheng, H. Giese, P. Inverardi, J. Magee, R. de Lemos, eds.: Software Engineering for Self-Adaptive Systems. Volume 5525 of Lecture Notes in Computer Science. Springer (2009) (http://dx.doi.org/10.1007/978-3-642-02161-9)
 R. de Lemos, H. Giese, H.A. Müller, M. Shaw, eds.: Software Engineering for Self-Adaptive Systems II. Volume 7475 of Lecture Notes in Computer Science (LNCS). Springer (2013) (http://dx.doi.org/10.1007/978-3-642-35813-5)
 Software Engineering for Self-adaptive Systems: Research Challenges in the Provision of Assurances. In: de Lemos, R., Garlan, D., Ghezzi, C., Giese, H. (eds.) Software Engineering for Self-Adaptive Systems III. LNCS 9640. Springer. (to appear); To access the Paper see :
[*] Further hints on literature are given in the lecture and by the lecture materials.
Lern- und Lehrformen
Each week two lectures (each of 90 minutes) will be given, interrupted by project phases and project meetings, for instance, to present intermediate project results.
- Oral exams by the end of the semester.
- The successful participation in the project is a mandatory precondition for taking the oral exam.
- The final course grade is the oral exam grade.
Lecture: each week:
- Tuesday, 13:30 - 15:00, A-2.2
- Wednesday, 11:00 - 12:30, A-2.2
The first lecture will be on Wednesday the 25th of October.
- Semesterwochenstunden : 4
- ECTS : 6
- Benotet :
- Einschreibefrist : 27.10.2017
- Lehrform : V/Ü/P
- Belegungsart : Wahlpflicht
Studiengänge & Module
IT-Systems Engineering MA
- BPET-Konzepte und Methoden
- BPET-Techniken und Werkzeuge
- OSIS-Konzepte und Methoden
- OSIS-Techniken und Werkzeuge
- SAMT-Konzepte und Methoden
- SAMT-Techniken und Werkzeuge