slam sistema basado en componentes basado en: “building realiable component- based software...

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ÓNINTRODUCCIÓN

class Stack inherits Collectionstate emptystate non_empty (top : Object, rest : Stack)

constructor make_empty pre truecall make_emptypost result = empty

observer is_empty : Booleanpre truecall 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)



• 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 CBSEConceptos 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


• 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”


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


• 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


• 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”


– 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”


• 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

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

Técnicas actuales de especificación de componentes

Especificación de la sintáctica de los componentes

Especificación de la sintáctica de los componentes

Componente

Interfaz

Operación

Parámetro

Parámetro_entrada Parámetro_salida

Parámetro_entrada_salida

Nombre

Tipo

Interfaces_entrada*

*

Interfaces_salida

*

*1

1

1

1

11

*

*

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



• 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)





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-slRelación con Slam-sl

class Liststate emptystate 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...


• 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


• 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)


• 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 claseclass Dictionaty

invariant self.is_ordered

state a (...)... state b (...)...


• Un componente puede implementar más de un interfaz.

• Se puede simular en Slam-sl mediante la especialización en herencia múltipleclass Interfaz_A class Interfaz_B

public function f1 (C):D public function f2 (E):Fpre ... pre ...pos ... pos ...

class Component inherits interfaz_A, interfaz_B...


• 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



• 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



• 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. ComponentesSLAM 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íaBibliografía

slam sistema basado en componentes basado en: “building realiable component- based software...

Documents