1 / 26

From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems

From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems. Shmuel Katz and Awais Rashid The Technion Lancaster University Haifa, Israel Lancaster, UK. Overview.

dori
Download Presentation

From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems Shmuel Katz and Awais Rashid The Technion Lancaster University Haifa, Israel Lancaster, UK

  2. 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

  3. 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?

  4. 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?

  5. 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

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

  7. 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

  8. Toll Collection System: Authorised Vehicle Toll Gate Euro 20

  9. Toll Collection System: Unauthorised Vehicle Toll Gate

  10. 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

  11. 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 Viewpoints

  12. 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>

  13. 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

  14. Subrequirements 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>

  15. 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.

  16. Composition Rule for Response Time Requirements Action and operator specifying how the viewpoint requirements are constrained by the specific aspectual requirements <Composition> -<Requirement aspect="ResponseTime" id="1.1"> -<Constraint action="enforce" operator="between"> <Requirementviewpoint="Vehicle" id="1" /> <Requirementviewpoint="Vehicle" id="2" /> </Constraint> -<Outcome action="satisfied"> <Requirementviewpoint="Gizmo" id="1" children="include" /> </Outcome> </Requirement> Subrequirements must be explicitly excluded or included Describes whether another (or a set of) viewpoint requirement must be satisfied or merely the constraint specified fulfilled.

  17. 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))

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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”

  23. 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”)

  24. 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

More Related