SMScom will focus on all lifelong aspects of a situational application. The expected results will be an integrated set of methods and prototype support tools. In particular we will focus on:
Specification. Specification comes into the picture because we need to formally describe SMScom entities, such as goals, abstract sensors, computational units, and devices. The specification must be formal, to support the mathematical reasoning that is necessary to ensure the desired levels of dependability and automation. Based on the explicitly formulated goals, which express why an application has to be reified and what it is expected to fulfill, SMScom will support the identification of the intentions, upon which computational units are selected and combined (possibly through local adaptations) to yield assemblies.
Verification. Verification is key to dependability. We will address verification of both the functional and non-functional properties against the goals. Moreover, since SMScom considers continuously evolving systems, we will consider verification as a lifelong effort. In the ideal, but extreme, case in which the application is composed in a fully automated way, verification is only performed at run time, to check that everything works as specified when the assembly was formed. Run-time data that indicate possible changes in the computational units, in the hosting devices, in the goals, or in the external world (captured by sensors), which may invalidate the correctness of the resulting assembly, must be kept, analyzed, and then fed back to the SMScom process that (partially) re-generates the assembly. Beside this extreme case we consider also more traditional situations, involving human intervention at design time, which require design-time verification to be also performed. In general, SMScom will explore the seamless integration of the design-time and run-time verification of the correctness of assemblies.
Architectural composition mechanisms. SMScom will explore fully automated mechanisms to support compositions. On the other hand, we expect that full automation will work in rather specific and restricted domains. Therefore we will explore the entire range of options, from full automation to designer-specified compositions. In the latter case, we will explore different composition architectures: from those that require a logically global coordination to those that are fully decentralized.
Change mechanisms. SMScom primarily deals with systems that dynamically change over time and must continue to offer service as changes occur. Adaptation to change can be reified in many different ways: from predefined applications, whose adaptability is anticipated, and limited to some variation points (as in product line architectures), to (service) aggregations fully created at runtime, whose components are discovered and assembled dynamically by means of planning techniques.
Middleware. Adaptation in a heterogeneous, dynamic, and largely distributed environment like the one we envision is hard to obtain without the support of appropriate middleware abstractions, which could ease the task of programmers. Such abstractions must support both the architectural styles and the change mechanisms mentioned above. Moreover, the middleware itself must be able to adapt to changes in the external environment to offer its services in every possible situation.
Sensing and actuating environment. In SMScom users are expected to interact with an augmented environment, which provides both sensing and actuating capabilities. As soon as a situation change is detected, possibly because new devices enter the scene while others leave, the new situation can provide both new inputs for the components already in use, and completely new capabilities. Moreover, sensors, actuators, and embedded devices in general, may also become the computing platforms to run dedicated components (services), which may become part of the application (possibly for a limited amount of time). Consequently, new situations may offer new computational units that must be taken into consideration if we want to allow users to be able to exploit the best "tool" for the goals they want to tackle in a particular situation.
Security. Security issues are of paramount importance among other dependability attributes. Situational software systems can be successful only if they operate in a secure manner, by preserving privacy and trust among the involved parties. Since in general context has an impact on security policies, the services provided by the system and the authorizations granted should adapt themselves to the current situation and revoked accordingly. Moreover, privacy becomes a further constraint since context information has often a personal character that must be preserved accordingly.
