From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems

Shmuel Katz and Awais Rashid The Technion Lancaster University

Haifa, Israel Lancaster, UK

Overview The problem: Early aspects—Requirements

(and Design) --- are disconnected from an implemented aspect-oriented system

The idea: generate precise proof obligations for implemented aspects, using semi-structured requirements (and design)

Achieves requirement traceability, provides precise semantics for aspect requirements

Some Key Questions What are Aspects? How are aspect requirements given? What are proof obligations? What are the key techniques that

connect the two? How can we design a framework for

generating proof obligations from requirements?

Implementation-Level Aspects

Module that cross-cuts usual classes Describes

changes/augmentations (advice) where to apply them (join points)

Language extensions: AspectJ over Java Question: what do we expect from such

aspects, and can they be reused as components?

Aspects and Concerns on the Requirements Level ARCADE: Aspectual Requirements

Composition and Decision Support Tool Viewpoints

Specify stakeholder requirements Concerns that are treated by Aspects

Broadly scoped properties XML

Extensible language for specification of viewpoints, candidate aspects and their composition

DOM, SAX and eXist Native XML database

Concerns Security Response Time Multi-Access Compatibility Accuracy of Computations Availability Handicapped Usability Rate Discount Policies

Aspect Proof Obligations Temporal logic formulas about aspects Group individual formulas to those

treating each aspect Especially needed for program-level

aspects Must treat potential conflicts among

aspects (as identified in requirements) Show original specification of system

without aspects is not violated PROBE: Proof Obligation Environment

ARCADE

Temporal LogicGenerator

UML Analyzer

IntegrationConflict Analysis

Ontology

UML design

Instantiation Proof Obligations

Mappings

Implementation

PROBE

Input

PROBE Component

Legend

Toll Collection System: Authorised Vehicle

Toll GateEuro 20

Toll Collection System: Unauthorised Vehicle

Toll Gate

Concrete Instantiation of the Model Viewpoints

Specify stakeholder requirements Concerns

Broadly scoped properties XML

Extensible language for specification of viewpoints, candidate aspects and their composition

ARCaDe: Aspectual Requirements Composition and Decision Support Tool DOM, SAX and eXist Native XML database

Viewpoints ATM Vehicle

Unauthorised Vehicle

Gizmo Toll Gate

Entry Toll Paying Toll

Single Toll Exit Toll

Police Debiting System System

Administrator Vehicle Owner

Registration Billing Activation

Vehicle Viewpoint - <Viewpoint name="Vehicle">  <Requirement id="1">The vehicle enters the system when

it is within ten meters of the toll gate.</Requirement>   <Requirement id="2">The vehicle enters the toll

gate.</Requirement>   <Requirement id="3">The vehicle leaves the toll

gate.</Requirement>   <Requirement id="4">The vehicle leaves the system when

it is twenty meters away from the toll gate.</Requirement> - <Viewpoint name="UnauthorisedVehicle">

  <Requirement id="1">The vehicle number plate will be photographed.</Requirement>

  </Viewpoint>  </Viewpoint>

Identify Candidate Aspects Concerns influencing and constraining

multiple viewpoints Response Time: Gizmo, ATM, Toll Gate,

Vehicle Compatibility: Police, Debiting System, ATM

Transform XML definition of concern Replace <concern> tag with <aspect> tag

Simple XSLT transformation Reflect the aspectual nature of the concern

Response Time Concern - <Concern name="ResponseTime">

- <Requirement id="1"> The system needs to react in-time in order to:

  <Requirement id="1.1">read the gizmo identifier; </Requirement>

  <Requirement id="1.2">turn on the light (to green or yellow);</Requirement>

  <Requirement id="1.3">display the amount to be paid;</Requirement>

  <Requirement id="1.4">photograph the plate number from the rear;</Requirement>

  <Requirement id="1.5">sound the alarm; </Requirement>   <Requirement id="1.6">respond to gizmo activation and

reactivation.</Requirement>   </Requirement>  </Concern>

Subrequirements

Concern/Viewpoint Relationships

Concerns Pol Gz DS ATM TG ... Vh UV VO ... AdmResponse Time

Availability

Security

Legal Issues

Compatibility

Correctness

Multi Access

Legend: Pol: Police; Gz: Gizmo; DS: Debiting System; ATM: ATM; TG: Toll GateVh: Vehicle; UV: Unauthorised Vehicle; VO:Vehicle Owner; Adm: Administrator.

Composition Rule for Response Time Requirements

  <Composition>

- <Requirement aspect="ResponseTime" id="1.1">- <Constraint action="enforce"

operator="between">  <Requirement viewpoint="Vehicle" id="1" />   <Requirement viewpoint="Vehicle" id="2" />   </Constraint>

- <Outcome action="satisfied">  <Requirement viewpoint="Gizmo" id="1"

children="include" />   </Outcome>  </Requirement>

Action and operator specifying how the viewpoint requirements are constrained by the specific aspectual requirements

Describes whether another (or a set of) viewpoint requirement must be satisfied or merely the constraint specified fulfilled.

Subrequirements must be explicitly excluded or included

Temporal logic formulas for implementation aspects

Gp: from now on, p is true Fp: eventually, p will be true pUq: p is true until q becomes true Can be input for formal methods tools G((veh-ent-sys((Fveh-ent-toll)/\

((¬veh-ent-toll)Uread-gizmo)))/\(read-gizmogizmo-effects) /\ (time(veh-ent-toll) – time(veh-ent-sys) < N))

The Temporal Logic Generator

Use patterns of formulas for keywords from ARCADE

Generate predicate and function names from the ARCADE text

Use a generic natural language processor with a temporal logic facility

Exploit semi-structured ARCADE and XML facilities

Extended Ontology Library of temporal formulas for keywords

Treat E between E1 and E2 ==> G(E1((F E2) /\ ((~E2) U E)))

Fuller patterns for reusable concerns Response time (for us) E between E1 and E2 causing

E3: (above)/\ EE3 /\ time(E2) – time (E1)<N))

Repository of predicate names to be later associated with implementation terms React-to-stimuli, turn-on-light, vehicle-enters-toll

Conflict Analysis One viewpoint may be constrained by

multiple aspects with contradictory requirements Availability (backup system) vrs. Response Time

Often requires preferring one over the other or weakening for real conflicts

Our solution: weakened properties in the Ontology, for use with conflicts Weak Resp. Time:… time(E2) – time (E1)<N+Extra

Proof of Interference Freedom can show apparent conflict is not really a problem

ARCADE

Temporal LogicGenerator

UML Analyzer

IntegrationConflict Analysis

Ontology

UML design

Instantiation Proof Obligations

Mappings

Implementation

PROBE

Input

PROBE Component

Legend

Integration and Instantiation

Integration: maps and merges properties from requirements to those from design (UML based—not seen here)

Instantiation: Connect predicate names to implementation events or data Turn-on-light connects to a method call Green-on connects to a value of a Color

variable

More on Instantiation Requirements aspect can map to:

Implementation aspect (in, e.g., AspectJ) Groups of requirements in relevant classes Design decisions (e.g., backup system to

ensure availability) Temporal logic formulas can map to input

format of formal methods or testing tools Can have multiple instantiations, like a

compiler “backend”

The resultant proof obligations

Collection of temporal formulas from the requirements with predicates instantiated

Possibly weakened versions for conflicts Assertion of non-interference among

aspects Assertion that desirable properties of

the original system are still true in augmented (aspects “do no harm”)

Summary Design of a modular Proof Obligation

Environment from Requirements (PROBE) Exploits semi-structured ARCADE with XML Extended Ontology with generic temporal logic

formulas and predicate names Extensive treatment of conflicts, weakening Status: key elements exist, rest under

development Provides traceability, and a semantics for aspect

requirements