El subsistema de Invocaci´ on Impl´ıcita

En la Secci´on 5.2.2.1 se vio que el estilo de Invocaci´on impl´ıcita se implementa a trav´es de un administrador de eventos que captura los eventos anunciados y realiza llamadas a los procedimientos interesados en tales eventos. En Fastest, cada uno de los eventos se representa con una instancia del m´odulo Event, cuya interfaz se presenta a continuaci´on:

Module Event

exportsproc setEventName(iString) getEventName(): String

Cada tipo de evento deber´a estar representado por una clase que herede de Event y que agregue los procedimientos para consultar y establecer los par´ametros particulares que acompa˜nan al evento. Por ejemplo, la interfaz del m´odulo TTreeGenerated, el cual es el tipo de evento que debe anunciarse despu´es de generarse el ´arbol de pruebas para una operaci´on, es:

Module TTreeGenerated inherits from Event imports TClassNode

exportsproc setOpName(i String) getOpName(): String setTTree(i TClassNode) getTTree(): TClassNode

en la que no se especifican los procedimientossetEventNameygetEventName, por heredarlos de Event, pero agrega procedimientos para consultar y establecer los par´ametros propios de TTreeGenerated, que son un ´arbol de pruebas y el nombre de la operaci´on para la que se gener´o un ´arbol. Es funda- mental que el constructor del m´odulo establezca, correctamente, el valor de la variable de estado que almacena el nombre del evento que le corresponda. La importancia de este nombre se debe a que es el que se utiliza para identificar de qu´e tipo de evento se trata cuando es anunciado, y que permita invocar a los procedimientos interesados en el evento.

Precisamente, al momento de ser anunciado el evento, es el administrador de eventos (implemen- tado en una instancia ´unica de EventAdmin) el que debe consultar su tabla de eventos (instancia de EventTable) para invocar los procedimientos interesados en el evento anunciado. Como se de- scribi´o anteriormente, EventAdminconstruye su tabla de eventos leyendo un archivo de configuraci´on que se describir´a m´as adelante. La interfaz del m´odulo EventAdmines la siguiente:

Module EventAdmin

imports ClientUI, Event, IIComponent, File, EventTable exportsproc getInstance(): EventAdmin

announceEvent(i Event) readFile()

setFile(iFile) getFile(i File)

CAP´ITULO 5. DESCRIPCI ´ON DE FASTEST 59

La subrutinagetInstancees necesaria para implementar el patr´on de dise˜noSingletonen relaci´on al administrador de eventos, el que permite forzar la existencia de una ´unica instancia deEventAdmin

en el sistema. setFile y getFile tienen como objetivo, respectivamente, establecer y obtener una referencia al archivo de configuraci´on de eventos. La subrutinareadFileparsea tal archivo y construye la tabla de eventos en el estado del m´odulo EventAdmin. En esta tabla se listan las ternas (evento, componente interesado en el evento, subrutina del componente a ser llamada al lanzarse el evento). Adem´as de completar la tabla de eventos, la subrutina readFile tiene la responsabilidad de crear cada uno de los componentes indicados en la tabla. La subrutinaannounceEventdebe invocar a cada m´etodo interesado en el evento que se pasa como argumento, es decir, a cada m´etodo indicado por los subscriptores listados en la tabla de eventos. En la implementaci´on, se decidi´o hacer cada invocaci´on en un thread diferente, para no forzar un orden entre las distintas invocaciones.

Respecto a los componentes que pueden interesarse en eventos, es importante destacar que cada uno de ellos se representa como una instancia de un m´odulo que herede deIIComponent, cuya interfaz se muestra a continuaci´on:

Module IIComponent imports ClientUI, Event exportsproc manageEvent(iEvent)

setMyClientUI(iClientUI) getMyClientUI(): ClientUI

El m´oduloClientUIque aqu´ı se menciona es el que implementa la interfaz de usuario de Fastest. Como los componentes interesados en eventos pueden necesitar acceder a la interfaz para solicitar o presentar informaci´on al usuario, es necesario que IIComponenttenga una referencia a ella. A trav´es de los procedimientossetMyClientUIygetMyClientUIes posible establecer y obtener esta referencia. Por su parte, el procedimiento manageEventes el que cada componente puede designar como intere- sado en alg´un evento, y es el que ser´a llamado por el administrador de eventos en caso de anunciarse tal evento.

En este prototipo de Fastest, los eventos utilizados son los siguientes:

AllTCasesGenerated, que debe ser lanzado cuando se haya concluido el intento de generaci´on de todos los casos de prueba solicitados.

AllTTreesGenerated, que debe ser lanzado cuando se haya concluido el intento de generaci´on de todos los ´arboles de pruebas solicitados.

AllTCasesRequested, que debe ser lanzado al solicitar el c´alculo de todos los casos de prueba para las operaciones seleccionadas (a trav´es del comando genalltca, a explicarse en la Secci´on

6.3.7). Se lanza este evento por cada ´arbol de pruebas previamente generado.

SpecLoaded, que debe ser lanzado cuando el usuario haya cargado, correctamente, la especifi- caci´on del programa a testear.

CAP´ITULO 5. DESCRIPCI ´ON DE FASTEST 60

TCaseGenerated, que debe ser lanzado despu´es de haberse terminado el intento de generaci´on del caso de prueba abstracto de cierta clase de prueba de una operaci´on particular.

TCaseRequested, que debe ser lanzado al solicitar el c´alculo de un caso de prueba para cierta clase de prueba.

TTreeGenerated, que debe ser lanzado despu´es de generarse el ´arbol de pruebas de cierta opera- ci´on.

TTreeRequested, que debe ser lanzado cuando se haya cargado la informaci´on correspondiente a una operaci´on a testear, esto es, su nombre y lista de t´acticas a aplicar.

Por otra parte, actualmente los componentes que se interesan en eventos son los que se muestran a continuaci´on:

TTreeGen. Este m´odulo es el encargado de organizar la generaci´on de ´arboles de prueba. Se interesa en los eventos de tipoSpecLoaded yTTreeRequested.

TClassExtractor. Se encarga de procesar eventos de tipoAllTCasesRequestedlanzando, para cada uno, sucesivos eventos de tipo TCaseRequested, uno para cada clase de prueba que sea hoja del ´arbol correspondiente. Esto permite, dados la solicitud de generaci´on de los casos de prueba para una operaci´on y el ´arbol de pruebas de la operaci´on, solicitar a trav´es de eventos de tipo TCaseRequested la generaci´on de casos de pruebas para las clases de prueba que sean hojas del ´arbol.

TCaseGenClient. Se encarga de manejar solicitudes para la generaci´on de casos de prueba abs- tractos, las cuales se indican en instancias deTCaseRequested. Por cada solicitud, este m´odulo inicia el proceso de generaci´on de un caso de prueba en un thread diferente, para favorecer cuestiones de desempe˜no.

Controller. Este m´odulo tiene la responsabilidad de mantener referencias a ´arboles de prue- ba, casos de prueba y dem´as resultados del proceso testing. Tambi´en mantiene referencias a la especificaci´on y a la lista de operaciones a ser testeadas junto con la lista de t´acticas a aplicar. Se interesa en los eventos AllTCaseGenerated, AllTTreeGenerated,TCaseGenerated

yTTreeGenerated.