Mathematical system models as a basis of software engineering

1995 ◽  
pp. 292-306 ◽  
Author(s):  
Manfred Broy
Keyword(s):  
Software Engineering ◽  
System Models ◽  
Mathematical System

Fault-Tolerant Software

2009 ◽  
pp. 21-52
Author(s):  
Vincenzo De Florio
Keyword(s):  
Fault Tolerance ◽  
Software Engineering ◽  
Fault Tolerant ◽  
Exception Handling ◽  
Fault Models ◽  
Application Layer ◽  
System Models ◽  
Functional Aspects ◽  
Design Choice ◽  
Computer Services

After having described the main characteristics of dependability and fault-tolerance, it is analyzed here in more detail what it means that a program is fault-tolerant and what are the properties expected from a fault-tolerant program. The main objective of this chapter is introducing two sets of design assumptions that shape the way our fault-tolerant software is structured—the system and the fault models. Often misunderstood or underestimated, those models describe • what is expected from the execution environment in order to let our software system function correctly, and • what are the faults that our system is going to consider. Note that a fault-tolerant program shall (try to) tolerate only those faults stated in the fault model, and will be as defenseless against all other faults as any non fault-tolerant program. Together with the system specification, the fault and system models represent the foundation on top of which our computer services are built. It is not surprising that weak foundations often result in failing constructions. What is really surprising is that in so many cases, little or no attention had been given to those important factors in fault-tolerant software engineering. To give an idea of this, three wellknown accidents are described—the Ariane 5 flight 501, Mariner-1 disasters, and the Therac-25 accidents. In each case it is stressed what went wrong, what were the biggest mistakes, and how a careful understanding of fault models and system models would have helped highlighting the path to avoid catastrophic failures that cost considerable amounts of money and even the lives of innocent people. The other important objective of this chapter is introducing the core subject of this book: Software fault-tolerance situated at the level of the application layer. First of all, it is explained why targeting (also) the application layer is not an open option but a mandatory design choice for effective fault-tolerant software engineering. Secondly, given the peculiarities of the application layer, three properties to measure the quality of the methods to achieve fault-tolerant application software are introduced: 1. Separation of design concerns, that is, how good the method is in keeping the functional aspects and the fault-tolerance aspects separated from each other. 2. Syntactical adequacy, namely how versatile the employed method is in including the wider spectrum of fault-tolerance strategies. 3. Adaptability: How good the employed fault-tolerance method is in dealing with the inevitable changes characterizing the system and its run-time environment, including the dynamics of faults that manifest themselves at service time. Finally, this chapter also defines a few fundamental fault-tolerance services, namely watchdog timers, exception handling, transactions, and checkpointingand- rollback.

Enforcing negative imaginary dynamics on mathematical system models

2013 ◽  
Vol 86 (7) ◽  
pp. 1292-1303 ◽  
Author(s):  
M.A. Mabrok ◽  
A. Lanzon ◽  
A.G. Kallapur ◽  
I.R. Petersen
Keyword(s):  
System Models ◽  
Mathematical System

Abstraction: An alternative neurocognitive account of recognition, prediction, and decision making

2020 ◽  
Vol 43 ◽  
Author(s):  
Valerie F. Reyna ◽  
David A. Broniatowski
Keyword(s):  
Decision Making ◽  
Software Engineering ◽  
Systems Engineering ◽  
Evidence Based ◽  
Extensive Literature ◽  
Trace Theory ◽  
Fuzzy Trace Theory ◽  
Abstract Representations ◽  
Technical Systems

Abstract Gilead et al. offer a thoughtful and much-needed treatment of abstraction. However, it fails to build on an extensive literature on abstraction, representational diversity, neurocognition, and psychopathology that provides important constraints and alternative evidence-based conceptions. We draw on conceptions in software engineering, socio-technical systems engineering, and a neurocognitive theory with abstract representations of gist at its core, fuzzy-trace theory.

Editorial: The role of formality in HCI issues in software engineering

1997 ◽  
Vol 144 (4) ◽  
pp. 193
Author(s):  
J.I. Siddiqi ◽  
C.R. Roast
Keyword(s):  
Software Engineering

Software Engineering for Real Time Systems

IEE Review ◽  
1992 ◽  
Vol 38 (3) ◽  
pp. 112
Author(s):  
Stuart Bennett
Keyword(s):  
Software Engineering ◽  
Real Time ◽  
Real Time Systems ◽  
Time Systems

Rationale and Design Considerations for a Semantic Mediator in Health Information Systems

1998 ◽  
Vol 37 (04/05) ◽  
pp. 518-526 ◽  
Author(s):  
D. Sauquet ◽  
M.-C. Jaulent ◽  
E. Zapletal ◽  
M. Lavril ◽  
P. Degoulet
Keyword(s):  
Information Systems ◽  
Software Engineering ◽  
Health Information ◽  
Rapid Development ◽  
Heterogeneous Systems ◽  
Health Information Systems ◽  
Semantic Interoperability ◽  
Point Of View ◽  
Current State ◽  
Engineering Environment

AbstractRapid development of community health information networks raises the issue of semantic interoperability between distributed and heterogeneous systems. Indeed, operational health information systems originate from heterogeneous teams of independent developers and have to cooperate in order to exchange data and services. A good cooperation is based on a good understanding of the messages exchanged between the systems. The main issue of semantic interoperability is to ensure that the exchange is not only possible but also meaningful. The main objective of this paper is to analyze semantic interoperability from a software engineering point of view. It describes the principles for the design of a semantic mediator (SM) in the framework of a distributed object manager (DOM). The mediator is itself a component that should allow the exchange of messages independently of languages and platforms. The functional architecture of such a SM is detailed. These principles have been partly applied in the context of the HEllOS object-oriented software engineering environment. The resulting service components are presented with their current state of achievement.

Sign in / Sign up

Export Citation Format

Share Document