FRINK Linked Data Fragments server

Matches in SemOpenAlex for { <https://semopenalex.org/work/W208087578> ?p ?o ?g. }

• W208087578 abstract "The inertness of today’s software systems turns innovative applications into an obstacle rather than an enabler and results in dependability degradation during the systems’ lifetime. Even more so, heterogeneity, scale, and dynamics open up what Laprie called the dependability gap. In this position paper, we identify the need to converge methods from software engineering with traditional middleware and dependable systems research to close the dependability gap. In particular, we suggest a nested control loop approach, where the inner loop addresses short-term changes autonomously, while the outer loop addresses longterm evolution by run-time software engineering. 1. Dependability Gap While computing is becoming a utility and software services increasingly pervade our daily lives, dependability is no longer restricted to critical applications, but rather becomes a cornerstone of the information society. Dependability clearly is a holistic concept: Contributing factors are not only technical, but also social, cultural (i.e. corporate culture), psychological (perceived dependability), managerial, and economical. Fostering learning is a key, and simplicity is generally an enabler for dependability. Among technical factors, software development methods, tools, and techniques contribute to dependability, as defects in software products and services may lead to failure and also provide typical access for malicious attacks. In addition, there is a wide variety of fault tolerance techniques available, ranging from persistence provided by databases, replication, transaction monitors to reliable middleware with explicit control of quality of service properties. Unfortunately, heterogeneous, large-scale, and dynamic software systems that typically run continuously often tend to become inert, brittle, and vulnerable after a while. The key problem is, that the most innovative systems and applications are the ones that suffer most from a significant decrease in (deterministic) dependability when compared to traditional critical systems, where dependability and security are fairly well understood as complementary concepts and a variety of proven methods and techniques is available today [1]. In accordance with Laprie [5] we call this effect the dependability gap, which is widened in front of us between demand and supply of dependability, and we can see this trend further fueled by an ever increasing cost pressure. This is caused by some of the following reasons [7, 5]: • Change of context and user needs: It is impossible to reasonably predict all combinations of change during design, implementation, deployment, and — most importantly — during run-time. • Imprecise (and sometimes even competing or contradictory) requirements: Users are either inarticulate about their precise criteria for correctness, performance, dependability, and other system qualities, or different users impose competing or contradictory requirements on the system, partially because of inconsistent needs. • Interdependencies between systems and software artefacts, and emerging behaviour: The system may be too complex to predict even its internal behaviours precisely. As a result, traditional systems experience permanent dependability degradation throughout their life-time. This in turn requires continuous and highly responsive human maintenance intervention and repetitive software development processes. While this need for intervention is costly, error-prone, and hence further impairs dependability, it may, in some cases, even become prohibitively slow compared to the system’s pace in normal operation. We can see two complementary approaches to address the problem of dependability degradation: Adaptive coupling and run-time software engineering. We contribute with the proposal to integrate these two approaches in a nested control loop approach that converges methods from software engineering with methods from traditional dependability research. 2. Adaptive and autonomous coupling Adaptiveness is envisaged in order to react to observed, or act upon expected (temporary) short-term changes of the system itself, the context/environment (e.g., resource variability or failure scenarios) or users’ needs (e.g., day/night setting) and expectations (e.g., responsiveness). As this kind of adaptivity should be provided without explicit user intervention, it is also termed autonomous behavior or selfproperties, and often involves monitoring, diagnosis (analysis, interpretation), and reconfiguration (repair) [4]. One of the main reasons why many approaches fell short in the past, however, lies in the major focus on the system’s components (e.g., by focusing on recompilation, reconfiguration, and redeployment of components), while complexity theory [6] on the other hand clearly shows that the overall properties of large and complex software systems are largely determined by the internal structure and interaction of its parts and less by the function of its individual components. Even more so, a complex software system provides a mixture of tightly and loosely coupled parts. As an important consequence, the overall system properties are determined not only by the structure but also by the strength of coupling of its relationships. Thus the inner control loop has to adaptively configure the strength of the architectural coupling between the system’s constituents as the most promising approach to explicitly balance competing dependability and security properties of the overall system according to the respective situation. This control should flexibly be performed as interaction between infrastructure and application (or even the end user), typically through run-time selection and reconfiguration of dependability protocols, e.g., consistency of replication protocols [3]. 3. Run-time software engineering As not all possible evolvements can be foreseen for longrunning software, long-term evolution has to be supported to regulate the emerging behavior of large and dynamic systems, again, with respect to the evolvement of the requirements and user expectations, but also in response to longterm changes in the context. This will be performed by changing the system’s design during run-time, which in turn requires run-time processable requirements and design-views in the form of constraints [2], models (”UML virtual machine”), or (partial) architectural configurations. The ultimate idea here is to move into run-time what previously could only be done by modifying an application off-line during design-time. These run-time accessible and processable requirements can be stored in repositories or be accessed via reflection, aspect-oriented programming, or protocols for meta-data exchange. They can explicitly be manipulated and configured, which allows such a system to balance or negotiate certain properties against each other or against user needs during run-time. Clearly, this requires middleware services to support manipulation of requirements and negotiation of properties and needs. The vision here is a convergence of software development tools with middleware (including traditional dependability, fault tolerance, and adaptivity concepts), to provide for run-time software development tools in the form of middleware services to compensate for dependability degradation by re-engineering running software." @default.
• W208087578 created "2016-06-24" @default.
• W208087578 creator A5056810923 @default.
• W208087578 date "2008-01-01" @default.
• W208087578 modified "2023-09-26" @default.
• W208087578 title "Closing the Dependability Gap: Converging Software Engineering with Middleware" @default.
• W208087578 cites W2026074664 @default.
• W208087578 cites W2033272857 @default.
• W208087578 cites W2126060096 @default.
• W208087578 cites W2127228682 @default.
• W208087578 cites W2145071552 @default.
• W208087578 cites W2149679864 @default.
• W208087578 cites W2150008502 @default.
• W208087578 hasPublicationYear "2008" @default.
• W208087578 type Work @default.
• W208087578 sameAs 208087578 @default.
• W208087578 citedByCount "0" @default.
• W208087578 crossrefType "journal-article" @default.
• W208087578 hasAuthorship W208087578A5056810923 @default.
• W208087578 hasConcept C10138342 @default.
• W208087578 hasConcept C111919701 @default.
• W208087578 hasConcept C115903868 @default.
• W208087578 hasConcept C144133560 @default.
• W208087578 hasConcept C169468491 @default.
• W208087578 hasConcept C199360897 @default.
• W208087578 hasConcept C2777904410 @default.
• W208087578 hasConcept C2778775528 @default.
• W208087578 hasConcept C41008148 @default.
• W208087578 hasConcept C77019957 @default.
• W208087578 hasConceptScore W208087578C10138342 @default.
• W208087578 hasConceptScore W208087578C111919701 @default.
• W208087578 hasConceptScore W208087578C115903868 @default.
• W208087578 hasConceptScore W208087578C144133560 @default.
• W208087578 hasConceptScore W208087578C169468491 @default.
• W208087578 hasConceptScore W208087578C199360897 @default.
• W208087578 hasConceptScore W208087578C2777904410 @default.
• W208087578 hasConceptScore W208087578C2778775528 @default.
• W208087578 hasConceptScore W208087578C41008148 @default.
• W208087578 hasConceptScore W208087578C77019957 @default.
• W208087578 hasLocation W2080875781 @default.
• W208087578 hasOpenAccess W208087578 @default.
• W208087578 hasPrimaryLocation W2080875781 @default.
• W208087578 hasRelatedWork W154150777 @default.
• W208087578 hasRelatedWork W1991197791 @default.
• W208087578 hasRelatedWork W2017719599 @default.
• W208087578 hasRelatedWork W202849499 @default.
• W208087578 hasRelatedWork W2033267867 @default.
• W208087578 hasRelatedWork W2088627423 @default.
• W208087578 hasRelatedWork W2109777773 @default.
• W208087578 hasRelatedWork W2112559209 @default.
• W208087578 hasRelatedWork W2121502627 @default.
• W208087578 hasRelatedWork W2134367453 @default.
• W208087578 hasRelatedWork W2134716336 @default.
• W208087578 hasRelatedWork W2141181829 @default.
• W208087578 hasRelatedWork W2145762726 @default.
• W208087578 hasRelatedWork W2158500210 @default.
• W208087578 hasRelatedWork W2165768251 @default.
• W208087578 hasRelatedWork W2169515430 @default.
• W208087578 hasRelatedWork W2352484596 @default.
• W208087578 hasRelatedWork W2509448990 @default.
• W208087578 hasRelatedWork W2586464723 @default.
• W208087578 hasRelatedWork W7293467 @default.
• W208087578 isParatext "false" @default.
• W208087578 isRetracted "false" @default.
• W208087578 magId "208087578" @default.
• W208087578 workType "article" @default.