李彤《软件工程》教学课件ch32.pptVIP

Inventory use cases Inventory extension use-case An AOSD process UML extensions Expressing an aspect oriented design in the UML requires: A means of modelling aspects using UML stereotypes. A means of specifying the join points where the aspect advice is to be composed with the core system. An aspect-oriented design model A partial model of an aspect Verification and validation The process of demonstrating that a program meets it specification (verification) and meets the real needs of its stakeholders (validation) Like any other systems,aspect-oriented systems can be tested as black-boxes using the specification to derive the tests However, program inspections and ‘white-box’ testing that relies on the program source code is problematic. Aspects also introduce additional testing problems Testing problems with aspects How should aspects be specified so that tests can be derived? How can aspects be tested independently of the base system? How can aspect interference be tested? How can tests be designed so that all join points are executed and appropriate aspect tests applied? Program inspection problems To inspect a program (in a conventional language) effectively, you should be able to read it from right to left and top to bottom. Aspects make this impossible as the program is a web rather than a sequential document. You can’t tell from the source code where an aspect will be woven and executed. Flattening an aspect-oriented program for reading is practically impossible. White box testing The aim of white box testing is to use source code knowledge to design tests that provide some level of program coverage e.g. each logical branch in a program should be executed at least once. Aspect problems How can source code knowledge be used to derive tests? What exactly does test coverage mean? Aspect problems Deriving a program flow graph of a program with aspects is impossible. It is therefore difficult to design tests systematically that ensure that all combinations of b