Upload
yolanda-lozano-marin
View
226
Download
0
Embed Size (px)
Citation preview
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
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
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 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
Conceptos básicos en CBSEConceptos 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 CBSEConceptos 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 CBSEConceptos 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 CBSEConceptos 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 CBSEConceptos 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 CBSEConceptos 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
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
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
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
Especificación de la semántica de los componentes
Especificación de la semántica de los componentes
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-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...
Relación con Slam-slRelació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-slRelació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-slRelació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 claseclass Dictionaty
invariant self.is_ordered
state a (...)... state b (...)...
Relación con Slam-slRelació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ú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...
Relación con Slam-slRelació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
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
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
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
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. 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