SLAM sistema basado en componentes Basado en: “Building realiable component- based software systems”. Crnkovic & Larsson Noelia Maya Fernández. Junio de 2003

SLAM es un sistema de desarrollo software basado en métodos formales (especificaciones formales y verificación en el diseño) Consta de un entorno de desarrollo que permite: –Verificación de refinamiento de especificaciones –Generación de código eficiente y legible Y de una notación formal: Slam-sl –Lenguaje de especificación formal OO –Basado en modelos abstractos con ciertas características de lenguajes algebraicos INTRODUCCIÓN

class Stack inherits Collection state empty state non_empty (top : Object, rest : Stack) constructor make_empty pre true call make_empty post result = empty observer is_empty : Boolean pre true call is_empty post result = (self = empty) Ejemplo Especificación de una pila

observer top : Object pre not self.is_empty call top post result = self.top modifier push (Object) pre true call push (x) post result = non_empty(x,self) Ejemplo Especificación de una pila

Un componente es una unidad reutilizable de desarrollo a la que se puede acceder a través de un interfaz Debería consistir en: –Un conjunto de interfaces –Código ejecutable Para mejorar la calidad, puede incluir: –La especificación de características no funcionales –Validación de código –Información adicional Conceptos básicos en CBSE

Un interfaz especifica los puntos de acceso al componente –Describe las operaciones que un componente proporciona, así como su protocolo de acceso –Idealmente, también se debe especificar la semántica de cada operación. Sin embargo, actualmente, en la mayoría de los casos, la interfaz define sólo la sintaxis. –Semántica: Necesidad de un contrato que especifique claramente el comportamiento Conceptos básicos en CBSE

Un contrato refleja la especificación de los componentes. Asegura que ciertas propiedades se mantendrán durante la ejecución de un componente dentro de su entorno –Meyer: “Un contrato es una lista de restricciones que un componente mantendrá (el invariante)” “Por cada operación del componente, un contrato lista las restricciones que el cliente debe cumplir para que se aseguren las condiciones de salida que en el contrato se establecen” Conceptos básicos en CBSE

El framework es el contexto en el que los componentes pueden utilizarse El framework gestiona los recursos compartidos entre los componentes y proporciona el mecanismo subyacente que permite la comunicación (interacción) entre componentes. Conceptos básicos en CBSE

El concepto de reutilización es diferente al convencional: –La composición de componentes puede hacerse en tiempo de ejecución sin necesidad de compilación –Para permitir la reutilización y la interoperabilidad entre componentes las interfaces deberían estandarizarse Conceptos básicos en CBSE

Objetos y componentes –Szypersky & Pfister: “Un componente es una colección de objetos en la que éstos cooperan entre sí y se entrelazan estrechamente”. “Los objetos de un componente tiene acceso a la implementación de los objetos dentro del mismo componente. Sin embargo, el acceso a la implementación de un objeto fuera del componente debería prevenirse” Conceptos básicos en CBSE

–D´Souza & Wills: “Una cuestión importante es si una clase es o no un componente”. “Si una clase se presentase junto con la definición explícita de los interfaces que requiere e implementa, entonces esta clase sería un componente” Conceptos básicos en CBSE

En su forma más sencilla un componente software contiene código (que puede ejecutarse en ciertas plataformas) y un interfaz que proporciona (el único) acceso al componente. Caja negra. Especificación de componentes software

La especificación de componentes usada en la práctica, hoy en día, de desarrollo sw, está limitada a la especificación sintáctica de las llamadas a operaciones (COM, CORBA, Sun´s Java Beans) Técnicas actuales de especificación de componentes

Especificación de la sintáctica de los componentes Componente Interfaz Operación Parámetro Parámetro_entradaParámetro_salida Parámetro_entrada_salida Nombre Tipo Interfaces_entrada * * Interfaces_salida * * * * 1 * 1*

Puede verse como una extensión del modelo de especificación sintáctica Un componente implementa una serie de interfaces, cada uno de ellos con una serie de operaciones Cada operación tiene asociado un conjunto de precondiciones y postcondiciones (contrato) Especificación de la semántica de los componentes

Una precondición es una aserción que el componente asume que se cumple cuando se hace la llamada a una operación Una postcondición es una aserción que el componente garantiza que se cumplirá cuando se ejecute la operación, si se cumplió la precondición cuando se la invocó. A menudo, las pre y las post dependerán del estado en el que se encuentre el componente Especificación de la semántica de los componentes

Una pre es un predicado sobre los parámetros de entrada de la operación y el estado del componente Una post es un predicado que relaciona los parámetros de entrada, los de salida y el estado del componente Además, un interfaz puede tener asociado un conjunto de invariantes Un invariante es un predicado sobre el modelo de estados del interfaz que siempre se cumplirá (contrato) La especificación del componente también puede incluir predicados sobre el modelo de estados que se deben cumplir en todos sus interfaces (contrato) Especificación de la semántica de los componentes

Componente Interfaz Operación Interfaces_entrada * * Interfaces_salida * * * * Restricción Estado Invariante Precondición Postcondición ParámetroParámetro_entrada Parámetro_salida *1 * * * 1 * 1 * 11 * 2 * * * * * *1 1 * 1*

Una clase puede verse como un componente cuyo interfaz son las operaciones públicas Una instancia se encuentra en un momento determinado en uno y sólo uno de los estados de la clase Relación con Slam-sl

class List state empty state non_empty (first : Object, rest : List) public constructor make_empty... private constructor make_non_empty (Object,List)... public observer is_empty : Boolean... public observer first : Object... public observer length : Nat... Relación con Slam-sl

Cada operación tiene asociado un conjunto de pre y de post (contrato) public observer first : Object pre not self. Is_empty call first post result = self.first Relación con Slam-sl

Un invariante es un predicado sobre el modelo de estados del interfaz: Cada estado puede tener asociado un invariante (contrato) class Point state polar (r : Float, a : Float) invariant r >= 0 and ( r = 0 implies a = pi/2 ) and ( r > 0 implies 0 <=a and a < 2 * pi) state cartesian (x:Float, y:Float) Relación con Slam-sl

La especificación del componente también puede incluir predicados sobre el modelo de estados que se deben cumplir en todos sus interfaces (contrato): Invariante de clase class Dictionaty invariant self.is_ordered state a (...)... state b (...)... Relación con Slam-sl

Un componente puede implementar más de un interfaz. Se puede simular en Slam-sl mediante la especialización en herencia múltiple class Interfaz_A class Interfaz_B public function f1 (C):D public function f2 (E):F pre... pos... class Component inherits interfaz_A, interfaz_B... Relación con Slam-sl

Sin semántica (COM o CORBA IDL, interfaces Java) Semántica intuitiva (comentarios) Semántica Ejecutable: Expresa aspectos de comportamiento de forma que pueden ser comprobados en tiempo de ejecución (aserciones de Java) public R getRecord (int number) throws IOException { System.assert ( (0<=number) && (number <= MAX)) //the implementation of the method } Especificación semántica: Niveles de formalismo

Semántica formal: permite comprobar la consistencia y corrección de los programas con respecto a la especificación. Lenguajes de especificación formal: Z,VDM, orden Especificación semántica: Niveles de formalismo

Slam-sl: –Lenguaje de especificación formal OO con sintaxis abstracta similar a lenguajes y metodologías actuales (UML, Java, etc.) –Basado en modelos abstractos con ciertas características de lenguajes algebraicos –Semántica funcional y basada en lógica de primer El lenguaje de especificación Slam-sl

Las precondiciones, postcondiciones e invariantes, son fórmulas lógicas con notación OO pre not self.is_empty invariant r >= 0 and ( r = 0 implies a = pi/2 ) and ( r > 0 implies 0 <=a and a < 2 * pi) post forall element in list.rest with element < 5 El lenguaje de especificación Slam-sl

Un componente debería consistir en: –Un conjunto de interfaces: especificaciones en Slam-sl –Código ejecutable: SLAM genera código eficiente y legible (en cualquier lenguaje) a partir de la especificación Para mejorar la calidad, puede incluir: –Validación de código: el código que SLAM genera es correcto con respecto a las especificación –Además proporciona verificación en el refinamiento de especificaciones SLAM como S.B. Componentes

“Building realiable component-based software systems”. Crnkovic & Larsson editors. Artech House Publishers. “Component-Based Software Engineering, A Proposed Outline for a Handbook of CBSE”. SEI “Technical Concepts of Component-Based Software Engineering”. SEI Bibliografía