focuspersistent software attributes A Unified Model of Dependability: Capturing Dependability in Context Victor Basili, University of Maryland and Fraunhofer Center for Experimental Software Engineering Paolo Donzelli and Sima Asgari, University of Maryland n contemporary societies, individuals and organizations increasingly depend on services delivered by sophisticated software-intensive sys- tems to achieve personal and business goals. So, a system must have I engineered and guaranteed dependability, regardless of continuous, rapid, and unpredictable technological and context changes. The International Federation for Information Processing Working Group 10.4 (www.dependability.org) defines dependability as “the trustworthiness of a computing system which allows reliance different things to different people; you often to be justifiably placed on the services it deliv- see different definitions given for the same at- ers.” “Reliance” is contextually subjective and tributes.1–3 Put another way, dependability as- depends on the particular stakeholders’ needs. sumes a precise meaning only when applied to Depending on the circumstances, different a specific context: the system and the stake- stakeholders will focus on different systems at- holders’ goals it must support. So, achieving tributes, such as availability, performance, and maintaining dependability in a quickly real-time response, and ability to avoid cata- changing context requires you to firmly un- strophic failures and resist adverse conditions, derstand its meaning. as well as different levels of adherence to such From this perspective, we introduce our attributes. Additionally, an attribute can mean Unified Model of Dependability, a modeling language for discussing and reasoning about dependability. By providing a structured Dependability is a key systems property that must be guaranteed framework for eliciting and organizing de- regardless of continuous, rapid, and unpredictable technological and pendability needs, UMD helps stakeholders build dependability models that clearly iden- context changes. Our Unified Model of Dependability lets you reason tify the measurable, implementable properties about dependability and turn it into clearly defined, implementable individual systems need to be dependable for system properties. their users. 0740-7459/04/$20.00 © 2004 IEEE Published by the IEEE Computer Society IEEE SOFTWARE 19 WHY READ THIS ARTICLE? Imagine for a moment that you have a complex system ticle, Victor Basili, Paolo Donzelli, and Sima Asgari de- with numerous properties that must all be maintained within scribe their Unified Model of Dependability approach to certain limits during the system’s operation. When a spe- capturing and analyzing the impacts of diverse events cific negative event such as a denial-of-service attack oc- on critical system properties. Their UMD method demon- curs, what will its impact be on various properties such as strates the recurring theme that you can make -ilities more system safety, availability, security, and other “-ilities”? enduring and survivable over time by capturing and sup- For most systems, such questions can be surprisingly porting a wider range of context information about those difficult to analyze due to the diverse ways in which a sin- properties. —Terry Bollinger, Jeffrey Voas, and gle event can affect different system properties. In this ar- Maarten Boasson, guest editors ■ If the online application is an e-commerce EventIssue Scope system, a delayed response could discour- Denial-of-service Response time age potential customers from buying (the attack > 10 seconds Query service Cause Concern service is unavailable), so this misbehavior represents a lack of availability. ■ The response delay could occur because of Figure 1. Unified Model an internal fault but also because of an ex- of Dependability UMD ternal event—for example, an unintentional concepts and their Traditional dependability modeling usually external event, such as a hardware fault, or relationships with an develops in a top-down fashion. For example, an intentional one, such as a denial-of-serv- online application let’s focus on a specific dependability attribute, ice attack. In this case, the performance fail- system example. performance, and assume we want to define ure becomes a lack of survivability (unin- what performance means for a specific service tentional) or of security (intentional). of a given system (for example, an online ap- plication’s query service). First, we need to de- These simple examples show how you could fine performance—for example, “performance interpret the same failure differently. Given this is a static or dynamic system’s capability (re- one-to-many relationship between failures and sponse time, throughput) defined in terms of attributes, you can more efficiently and intu- an acceptable range.”4 Then, on the basis of itively model dependability by assuming failure this definition, we can specify the desired be- as a starting point (that is, think bottom-up havior. So, our online application’s query serv- and not only top-down). As Brian Randall ice could have this performance requirement: points out, there’s a clear need to go beyond “The response time must be no greater than 10 terminology (that is, attributes definitions) and seconds.” In this way, we’ve obtained a model focus on relevant concepts (such as failure).5 of the system’s performance starting from a UMD builds on this need. We designed it to generic attribute definition. This simple model focus on a dependability issue (that is, an un- defines what we expect from the system: When dependable behavior, such as a failure) to help the query service responds in more than 10 sec- stakeholders build dependability models of in- onds, we can say there’s a performance failure, dividual systems. UMD (see Figure 1) lets or a lack of performance. However, the same stakeholders model dependability by defining failure could also represent a lack of other— an actual issue that shouldn’t affect the system perhaps even more relevant for the stakehold- or a service (scope) along with a possible re- ers—system properties. For example, sponsible external event that might cause it. ■ If the online application supports an emer- Supporting elicitation gency response operator, a delayed re- We provide stakeholder guidance by incor- sponse could result in a dangerous situa- porating into UMD the models, definitions, tion, so failure would be also a hazard, and classifications adopted in the literature to representing a lack of safety. discuss these concepts. For example (see Figure 20 IEEE SOFTWARE www.computer.org/software Figure 2. Stakeholder Issue guidance for specifying FAILURE issues. Characterization: 2), we could categorize issues into the (not ex- Type clusive) concepts of failures and hazards to • Accuracy • Response time help stakeholders identify potential system • And so on ... misbehaviors. Availability impact We can further refine these concepts by in- • Stopping troducing subclassifications for both failures • Nonstopping and hazards—for example, by classifying them HAZARD by type or other characteristics (such as failure Characterization: availability impact in Figure 2). Depending on Type the specific needs, you could adopt different • User hazard standards and classifications, for example, • Environment hazard • And so on ... MIL-STD-8826 for hazards and ISO/IEC 132367 for failures. Similarly, you could introduce ad hoc definitions and classifications for event and scope. In this way, UMD guides stakeholders dur- work’s lower to upper levels. ing the elicitation process. Specifically, stake- As Figure 3 shows, you can view UMD as an holders can use items already available or tai- experience base that supports stakeholders in lor, expand, and modify them according to building a specific system’s dependability model. their specific needs. For example, stakehold- The knowledge embedded in the UMD experi- ers can ence base can be customized and provides guid- ■ Use the definitions of failure types already ance while eliciting specific context needs. present The new knowledge acquired while build- ■ Use the same failure types but provide dif- ing the system dependability model can be an- ferent definitions alyzed and packaged for reuse in UMD. ■ Introduce more specific failure types—for example, response time rather than Measuring dependability performance UMD lets stakeholders specify the issues they don’t want to occur. However, this doesn’t UMD’s bottom-up nature lets stakeholders suffice; we need an operational definition of take advantage of existing dependability dependability. For example, Jean-Claude La- knowledge (models and classifications). So, prie says, “The extent to which a system pos- Figure 3. The updating the UMD framework consists of sesses the attributes of dependability should be process from version interpreted in a relative, probabilistic sense, due 11.23 to version 11.25, ■ Invariant concepts: These are stable for to the unavoidable occurrence of failures.”8 showing how to add a every UMD application (issue, scope, and UMD provides measurement models via the new column in the event). Bank table. ■ Semi-invariant concepts: These are the structure of the concepts’ characterization (for example, mapping issue to failure, Specific-system hazard, or both). dependability model ■ Customizable concepts: These are the characterizations (for example, classes of Customize Extract new failures, hazards, events, and so on). They framework to