Introduction With today’s large and complex distributed software systems, building and maintaining dependable software systems is becoming more and more challenging We are in the period where more emphasis must be placed on developing systems that meet both functional and non functional requirements. Software's increasing role creates both requirements for being able to trust it more than before, and for more people to know how much they can trust their software.
What is Dependability? The international Federation for Information Processing (IFIP) defines dependability as the trustworthiness of a computing system that allows reliance to be justifiable placed on the services it delivers. Why is there a problem with software reliability? Human intellectual failures and inability to follow proper development plan.
Dependability Modelling Dependability Modelling F ramework that accommodates different philosophies, methods and techniques for analyzing dependability requirements of a system There are several tools to model dependability of a system Unified model of Dependability Unified Model Language Dependability Evaluation of multiple-phased systems (DEEM)
Threats Threats are things that can affect a system and cause a drop in Dependability. There are three main terms that must be clearly understood: Fault: A fault (which is usually referred to as a bug for historic reasons) is a defect in a system. The presence of a fault in a system may or may not lead to a failure. Error: An error is a discrepancy between the intended behavior of a system and its actual behavior inside the system boundary. Errors occur at runtime when some part of the system enters an unexpected state due to the activation of a fault. Failure: A failure is an instance in time when a system displays behavior that is contrary to its specification. An error may not necessarily cause a failure
Means Fault Prevention deals with preventing faults being incorporated into a system. This can be accomplished by use of development methodologies and good implementation techniques. Fault Removal can be sub-divided into two sub-categories: Removal During Development Removal During Use Fault Forecasting predicts likely faults so that they can be removed or their effects can be circumvented. Fault Tolerance deals with putting mechanisms in place that will allow a system to still deliver the required service in the presence of faults, although that service may be at a degraded level.
Dependability Attributes: Reliability is the continuity of correct service (a service is correct when implements the system function) [Laprie01]. Accuracy is the capability to minimize the difference between delivered computational results and the real world quantities that they represent [Boehm03]. Availability is the ability of the system to provide service at any given time. It is the probability of being operational, under given use condition, at a given instant in time [Melhart00].
Attributes Performance is concerned with quantifiable attributes of the system, such as response time (how quickly the system reacts to a user input), throughput (how much work the system can accomplish within a specified amount of time), availability (the degree to witch a system or component is operational or accessible when required for use), and accuracy [Bruegge04]. Safety is the ability of the system to deliver service under given use conditions with no catastrophic effect [Melhar00]. Confidentiality is the absence of unauthorized disclosure of information [Laprie01]. Integrity is the absence of improper system state alteration [Laprie01].
The Unified Model of Dependability The Unified Model of Dependability (UMD) is a modeling framework for discussing and reasoning about dependability. By providing a structured language for eliciting and modeling dependability requirements. UMD helps stakeholders to clearly identify the measurable and implementable properties a system should possess in order to be dependable.
The “Unified Model of Dependability” Modeling framework (designed around the concept of failure) that helps stakeholders to express their dependability requirements by defining the issues (failures) with respect to the system or a service (scope), and the possible responsible external events.
Measuring Dependability: It is important to introduce the possibility of measuring dependability by allowing the stakeholders not to only identify the undesired failure, but to quantify what they assume could be tolerable corresponding manifestations. Measures Types: Time-based (probability) measures, such as Mean Time to Failure (MTTF) Absolute measure, such as number of occurrence (in a given time frame) Ordinal measures, for example by introducing an ordinal scale such as” very rarely”/”rarely”/”sometimes”
References Automatic Dependability Modelling of Systems Described in UML István Majzik BME-DMIS.H-1521 Pisa, Italy http://bonda.cnuce.cnr.it/Documentation/Papers/file-MB98-ISSRE-115.pdf Dependability Modeling & Evaluation of Multiple-Phased Systems using DEEM Andrea Bondavalli1, Silvano Chiaradonna2, Felicita Di Giandomenico2, Ivan http://bonda.cnuce.cnr.it/Documentation/Papers/file-BCDGM04-TRDEEM-3.pdf Towards Sound Architectural Dependability Models Hichem Boudali Boudewijn R. Haverkort Matthias Kuntz Mari¨elle Stoelinga University of Twente, Department of Computer Science, Enschede, Netherlands. http://eprints.eemcs.utwente.nl/11030/01/PMCCS-final-Boudali.pdf