Early Availability Requirements Modeling using Use Case MapsKAMARUL ZAMAN BIN PANATIK

MAN151033

Introduction

Modeling of requirements – Main challenges during development of complex systems.

Non-Functional requirements (NFR) consideration like timing, availability and reliability are often dominate the design of RT systems.

However they are often overlooked during initial sys design and described in separate model.

NFR should be modeled at earliest stage (System Requirement Level) of System Development Life Cycle (SDLC)

Modeling of NFR facilitates RT Design and supports detection of design errors during early stage of SDLC. – Reduce cost

This paper introduce an approach to describe availability features in Use Case Maps (UCM) Specs. Mapping of availability architectural tactics to UCMs Components, the case of ISSU (In Service Software Upgrade) features in IP Routers.

Use Case Maps in Brief

High-level visual scenario-based modeling technique that can be used to capture and integrate functional requirements & high-level design at early stages of developemnt process.

Developed by Prof Buhr et al, at Carleton Uni. Been used since 1992

Allow description of functional and architectural requirements at a high level of abstraction.

UCMs notation aims to link behavior and structure in an explicit and visual way.

Uses path representing scenario that intend to bridge the gap between requirements (use case) and detailed design

Can reveal problem with requirements (use case) (i.e. Incomplete, incorrect, ambiguous, inconsistent)

Convey a lot of information in a compact form

UCM Basic Notation

A Team is the most generic component, used as a container for sub-components of any kind. Teams are operational groupings of system-level components.

Objects are data or procedure abstractions that are system-level components to support the system comprehension.

A Process is an active component, which implies the existence of a control thread.

An Agent is an autonomous component, which acts on behalf of other components.

An Actor is an external component that describes an entity, either human or artificial, that interacts with the system.

Some Definition of Availability

The ITU-T recommendation E.800:

“the ability of an item to be in a state to perform a required function at a given instant of time, or at any instant of time within a given time interval, assuming that the external resources, if required, are provided.”

Avizienis et al. Treated availability as an attribute of dependability and defined it as being the readiness for a correct service.

The Service Availability Forum (SAF extends the definition of Avizienis to include a focus on the demands of customers.

Availability Architectural Tactics –(Bass et al)

Proposed by Bass et al.

Categorizes availability tactics based on fault detection, recovery, or prevention.

This paper addresses how these tactics are mapped into UCMs

UCM Fault Detection Modeling

UCM architectural features with physical connections between components address the ping/echo and the heartbeat tactics.

Figure (a) – Two components connected using a physical link.

The link is subject to ping/echo and/or heartbeat failures as described using the failure point and the associated comments.

Figure (b) – Optional values (maximum response time for ping, heartbeat timer values, the sources and destination of the ping/heartbeat) can be specified

UCM Fault Detection Modeling

Exceptions are handled at the scenario path level.

Exceptions may be associated with any responsibility along the UCM execution path.

The figure illustrates an example of exception handling mechanism to deal with a division by zero that may occur after executing responsibility R1.

This exception would trigger the execution, within the same component Component 1 of another UCM path called Exception Path (i.e. when the boolean precondition at start point S2 is satisfied) leading to the execution of responsibility R3.

UCM Modeling of Fault Recovery-Preparation and Repair

Figure (a) illustrates an example of a system with three components C1, C2 and C3 participating in one hot redundancy configuration (i.e. Group ID: G1).

C1 and C2 are in active role (i.e. Role: Active) while C3 is in standby role (i.e. Role: Stdby)

None of these three components is taking part in voting activity (i.e. Voting : false).

Such annotations are static and cannot be modified at run-time. So, if a component needs to change its role, for instance because of the occurrence of a switchover, it should be documented part of the scenario execution path.

Physical links can also be protected using the same schema: 1+1, 1:N and M:N. Figure (b) shows how this can be represented in UCM models.

UCM Modeling of Fault Recovery-Reintroduction

The figure illustrates a feature configuration scenario on a dual route processor (RP) system. The feature configuration details are embedded within the static stub FeatureConfiguration and not shown here.

This scenario may result in active and standby route processors (respectively RP1 and RP2) being out of synchronization.

The detection of this issue would trigger an exception path (i.e. precondition OutOfSych is satisfied) and causes both RPs to synchronize again (using responsibilities StateSynchronization between AND-Fork and AND-Join). Similarly, Rollback tactic can be represented using the exception path.

UCM Fault Prevention Modeling

Failure points can be annotated with comments specifying a removal from service property.

Similarly, responsibilities can be annotated with comments about their transactional properties.

Finally, components can be annotated with health monitoring capabilities

ISSU – In Service Software UpgradeUCM Fault Recovery Preparation Modeling

Conclusion

This paper proposes a novel approach to describe availability requirements using Use Case Maps language.

All availability tactics that proposed by Bass et al. has been covered

This approach of incorporating availability tactics allow for further model refinement and smooth moving towards more detailed design models.