SLAM sistema basado en componentes Basado en Building

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

INTRODUCCIÓN • 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

Ejemplo Especificación de una pila 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)

Conceptos básicos en CBSE • 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”

Especificación de componentes software • 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.

Técnicas actuales de especificación de componentes • 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)

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

Especificación de la semántica de los componentes • 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 * 1 Restricción Componente * * * 2 1 Interfaces_entrada * 1 Estado * * Interfaz 1 Interfaces_salida * 1 * * * Invariante * * Precondición * * Parámetro_entrada * * 1 Operación 1 * Postcondición 1 * * Parámetro_salida

Relación con Slam-sl • 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 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 public function f 1 (C): D pre. . . pos. . . class Interfaz_B public function f 2 (E): F pre. . . pos. . . class Component inherits interfaz_A, interfaz_B. . .

Especificación semántica: Niveles de formalismo • 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 get. Record (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

El lenguaje de especificación Slam-sl • 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

SLAM como S. B. Componentes • 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

Bibliografía • “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