Requirements Engineering with SOTA Sample Clauses

Requirements Engineering with SOTA. ‌ The activity of requirements engineering for self-adaptive systems in SOTA requires identifying the dimensions of the SOTA space, which means modeling the relevant information that the different components and ensembles of a system have to collect to become aware of their location in such space. This is necessary to recognize whether they are behaving correctly and to adapt their actions whenever necessary. In e-mobility, the space S clearly includes the spatial dimensions related to the street map, but also dimensions related to the current traffic conditions, the battery conditions, and in general any physical or virtual dimension that may affect the behavior of vehicles. As a vehicle moves along some road, its position in the SOTA space changes accordingly, obviously w.r.t. the dimension representing the spatial location but also w.r.t. the dimension representing the traffic and battery conditions. Once the SOTA space is defined, a goal in SOTA can be expressed in terms of a specific state of the affairs to aim for, that is, a specific point or a specific area in S which the component or ensemble should try to reach in its evolution, in spite of external contingencies that can move the trajectory farther from the goal. For instance, a goal for a vehicle could imply reaching a position in the SOTA space that, for the dimensions representing the spatial location, trivially represents the final destination and for the dimension representing the battery condition may represent a charging level ensuring safe return. That is, if the location to be reached has coordinate (x,y) and we know that the place need to be reached in a time no more than T: Gcari = n Gpre = location(t, s); Gpost = location(x, y); U = battery level > 10% [ time for reaching < T , In general, a goal is not necessarily always active. That is, a goal has to be defined also in terms of the preconditions that activate it. In addition, a goal may impose constraints on the trajectory to be followed while trying to achieve, e.g., a car may wish to reach a destination while avoiding motorway.

Requirements Engineering with SOTA. ‌ The precise analysis of requirements is an important aspect in the early phase of system engineering [ST09]. Depending on the system under consideration, the domain must be mapped out in different ways. In open-ended and adaptive systems, a goal-oriented approach to requirements engineering, i.e. where requirements are modeled in terms of goals [MCY99], is the most beneficial. Within ASCENS, the SOTA (State Of The Affairs) approach [AZ12] captures this way of think- ing about a system, and goes one step further from simple goal-oriented systems in that it considers dynamic systems modeling with a particular focus on systems with self-* (self-star) properties, in par- ticular self-adaptation. Within a system, this applies both on a local level (i.e., the component level) and more global levels (i.e., the ensemble level). The SOTA approach proves useful to understand and model functional and non-functional require- ments, expressing them into system specifications whose correctness can be checked. A complete def- inition of the requirements of a system-to-be implies identifying the dimensions of the SOTA space, and in particular defining the set of goals (with pre- and post-conditions, and possibly associated goal-specific utilities) and the global utilities for such systems, that is, the sets: G = {G1, G2, . . . , Gn} i where Gi = {Gpre, Gpost, Ui} U = {U1, U2, . . . , Un} The SOTA specification expressed in terms of Goals and Utilities enables the designer to choose the most appropriate pattern from a catalogue ([Puv12]), so as to describe the system under study at best. Depending on the type of utilities and/or goals in the specification of the scenario, a pattern is more suitable than another, as thoroughly discussed in [PPC+13] and [PCZ13]. It is important to note that self-* systems should not be simply engineered to achieve a certain state, but to strive to achieve a certain state. In SOTA, the entities of the systems (either simple ones or collections of entities) are seen placed in an n-dimensional space S, where each of the n dimensions represents one axis on which the entities are placed. The position of the entity may change either based on its own actions or because the environment changes. Moving within S thus corresponds to the evolution of the system. The different dimensions in S within the cloud case study relate to the fitness of each node in itself, and to keeping to the requirements of applications (SLAs) executed by ensembles. Thus, d...