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

Toll Collection System: Authorised Vehicle Toll Gate Euro 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 - The vehicle enters the system when it is within ten meters of the toll gate. The vehicle enters the toll gate. The vehicle leaves the toll gate. The vehicle leaves the system when it is twenty meters away from the toll gate. - The vehicle number plate will be photographed.

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 tag with tag Simple XSLT transformation Reflect the aspectual nature of the concern

Response Time Concern - - The system needs to react in-time in order to: read the gizmo identifier; turn on the light (to green or yellow); display the amount to be paid; photograph the plate number from the rear; sound the alarm; respond to gizmo activation and reactivation. Subrequirements

Concern/Viewpoint Relationships                                Legend: Pol: Police; Gz: Gizmo; DS: Debiting System; ATM: ATM; TG: Toll Gate Vh: Vehicle; UV: Unauthorised Vehicle; VO:Vehicle Owner; Adm: Administrator.

Composition Rule for Response Time Requirements - - 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- gizmo  gizmo-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)/\ E  E3 /\ 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

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