ANÁLISIS Y DISEÑO DE Software Principios

Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía.

1

Universidad Nacional del Sur – Departamento de Ciencias e Ingeniería de la Computación Análisis y Diseño de Sistemas – 1er.Cuatrimestre de 2013.

Mg. María Mercedes Vitturini

[[email protected]]

Dpto. Cs. e Ing. de la Computación

Universidad Nacional del Sur

ANÁLISIS Y DISEÑO DE

SISTEMAS

Clase XIX: Especificación

Formal Primer Cuatrimestre 2013

AyDS2012 - Clase 20- MMV 2

Principios de Ingeniería de Software

Principios – enunciados generales y abstractos que

describen las propiedades deseables de los procesos y

productos de software.

• Principios de IE: rigor y formalismo, separación de

intereses, modularización, abstracción, generalización y

anticipo al cambio.

• Para aplicar los principios se requieren;

– Métodos: guías generales que gobiernan la ejecución

de alguna actividad. Son aproximaciones rigurosas,

semánticas y disciplinadas.

– Técnicas: guías más técnicas y mecánicas que los

métodos.


Principios de Ingeniería de Software ...

• Una metodologías provee una

aproximación estable para resolver un

problema, preseleccionando los

métodos y técnicas a ser usadas.

Metodología = métodos + técnicas

• Las Herramientas se desarrollan

para colaborar con la aplicación de

técnicas, métodos y metodologías.

HERRAMIENTAS

METODOLOGÍA

MÉTODOS Y TÉCNICAS

PRINCIPIOS DE IS


Rigor y Formalismo • Si bien el desarrollo de software es una actividad

“creativa”, la rigurosidad es el complemento necesario en la creación de cualquier actividad de ingeniería.

• El nivel más alto de rigurosidad es el formalismo.

• Formalismo: requiere que el software sea evaluado y derivado mediante reglas matemáticas y lógicas.

– Rigor o formalismo? Depende de la tarea y su criticidad.

Sólo con aproximaciones rigurosas se pueden producir productos confiables.

Rigor y Formalismo

• Las metodologías vistas hasta ahora en este curso son “rigurosas”:

– Las especificaciones de análisis y diseño usan una combinación de modelos, diagramas, textos, tablas, etc.

• Metodologías formales:

– Las especificaciones de análisis y diseño requieren de sintaxis y semántica formal.

– Usan técnicas matemáticas para describir las propiedades de funcionalidad y comportamiento esperadas.

AyDS2013 - Clase 18- MMV 5 AyDS2012 - Clase 20- MMV 6

Modelos de Proceso - Repaso

Modelo Transformacional – define el desarrollo de software como una secuencia de pasos que gradualmente transforma la especificación en implementación.

• El proceso de desarrollo está basado en transformaciones.

• Es pre-requisito contar con la especificación formal del sistema.

• La especificación es transformada a través de una serie de

pasos que preservan la correctitud.


2



Modelo Transformacional

AyDS2012 - Clase 20- MMV

Métodos Formales

• Los métodos formales para desarrollo de software son técnicas con sólidas bases matemática para describir y validar las propiedades del sistema.

– Proporcionan el marco de referencia para especificar, desarrollar y verificar los sistemas de manera sistemática.

8

Método

Lenguaje de Especificación

• La base matemática de un método formal está dada por un lenguaje de especificación formal.

– Un lenguaje de especificación formal define los requisitos de diseño en forma única.

Especificación de Requisitos

• Propiedades deseadas de una especificación de requerimientos:

– Consistencia

– Integridad

– Falta de ambigüedad

• Deficiencias de los enfoques menos formales:

– Contradicciones

– Ambigüedades

– Vaguedades

• Obs: ninguno de los enfoques asegura completitud. AyDS2012 - Clase 20- MMV 9

Más simples de alcanzar con

una especificación formal

Especificaciones Formales • Las especificaciones formales fundamentalmente se

prefieren en los sistemas críticos.

• Entre los beneficios de una especificación formal está la posibilidad de demostrar que el resultado se ajusta a los requerimientos (usando reglas de inferencia).

• La aplicación de métodos formales aumenta los costos y esfuerzos requeridos en las etapas de análisis y especificación y disminuye los tiempos y costos de las etapas de diseño y prueba.



Especificaciones Formales vs Informales

COSTO

Lenguajes de Especificación Formal

• La base de un método formal generalmente está dada por un lenguaje de especificación formal.

• Un lenguaje formal está compuesto de:

– Sintaxis: que define la notación para representar la especificación.

– Semántica: que indica cómo el lenguaje representa los objetos del sistema.

– Un conjunto de reglas



3



Lenguajes de Especificación Formal

• Los lenguajes de especificación formal tradicionalmente se dividen en:

– Algebraicos u Orientados a propiedades: el sistema se describe en utilizando definiciones axiomáticas en términos de las operaciones y sus relaciones.

– Orientados a modelos: se construye un modelo del sistema utilizando constructores matemáticos concretos como conjuntos y sucesiones. Las operaciones están definidas en base a cómo modifican el estado del sistema.

13

+

A B S T R A C C I O N

-


Especificación Orientada a Modelos

scheme PadronPersonas =

class

type

Persona = Text,

Padron = Persona-set,

value

vacio : Padron = { },

insertar : Persona >< Padron-> Padron

insertar (per, pad) pad {per},

check: Persona >< Padron-> Bool

check (per, pad) per pad

end

14

La solución propuesta

construye un modelo del

sistema utilizando elementos

matemáticos concretos, en este

caso conjuntos.


Especificación Algebraica scheme PadronPersonas =

class

type

Padron, Persona

value

vacio: Padron,

insertar : Persona >< Padron-> Padron


axiom

per: Persona • check(per, vacio) false,

per1, per2: Persona, pad: Padron •

check(per2, insertar(per1,pad)) per2 = per1 check(per2,pad)

end

15

El sistema se describe en

términos de definiciones

axiomáticas .

• El álgebra como formalismo matemático:

– Álgebra homogénea: un solo conjunto de valores posibles y varias operaciones. Las álgebras tradicionales son homogéneas. • Ejemplo: números enteros y sus operaciones.

– Álgebra heterogénea: colección de conjuntos diferentes en los cuales se definen diferentes operaciones.

• Ejemplo: el tipo cadenas de caracteres y la operación longitud. La longitud de la cadena es un número natural.

Algebras



Especificaciones Algebraicas

Las especificaciones algebraicas definen al sistema como un álgebra heterogénea.

Signatura del álgebra: es la colección de conjuntos que componen el álgebra heterogénea. Para definir un álgebra heterogénea:

– Especificar la signatura.

– Especificar las operaciones involucradas.

– Especificar dominios y rangos de las operaciones.

• Existe relación entre álgebras heterogéneas y tipos de datos abstractos.

17

RAISE

Rigurous Approach to Industrial Software Engineering


4



RAISE

• RAISE: Rigorous Approach to Industrial Software Engineering

“RAISE is a formal method. It provides facilities for the industrial use

of Formal Methods in the development of software systems”

• Consiste de :

– Método para desarrollo de software.

– Un lenguaje de especificación formal: RSL - RAISE Specification Language.

– Herramientas automáticas.

19 AyDS2012 - Clase 20- MMV

RAISE ...

• Background:

– Orientados a Modelos: VDM, Z, ...

– Orientados a Propiedades: Larch, ...

– Concurrentes: Redes de Petri, CSP, ...

– Secuenciales: Z, VDM, Larch ...

– Herramientas.

20

El método

• El método RAISE propone su propio modelo de proceso para las actividades del desarrollo de sistema, incluyendo captura de requerimientos y gestión de proyectos.

• El método se sustenta en cuatro principios:

– Desarrollo por partes.

– Desarrollo paso a paso.

– Inventar y verificar.

– Rigor (más que formalismo).

AyDS2012 - Clase 20- MMV 21 AyDS2012 - Clase 20- MMV

Desarrollo por Partes

• Definir la especificación de forma que actúe como un contrato que indique de forma precisa las propiedades esenciales de los elementos especificados.

• Importancia de las especificaciones:

– El desarrollo de sistemas es una actividad de descomposición y composición.

– En la mayoría de los sistemas existen personas trabajando sobre componentes distintas en simultáneo.

22


Desarrollo Paso a Paso

• El desarrollo de software involucra una secuencia evolutiva de pasos.

• Usando el método RAISE

– Encontrar los requerimientos (mayor nivel de abstracción).

– Iterar: refinar tomando decisiones de diseño (evoluciones en la especificación).


Inventar y verificar - Rigor • Inventar y verificar

– Inventar y verificar es un estilo que fuerza a los desarrolladores a pensar un nuevo diseño y luego verificarlo.

– Las justificaciones de RAISE usan técnicas de transformación, pero aplicadas a expresiones lógicas (no a programas).

• Rigor

– No es práctico probar todo.

– Se requiere de métodos formales para las justificaciones.

24


5



El Método RAISE

Requerimientos de usuario

Especificación 0

...

...

...

Especificación n

Programa

Pasos del

Desarrollo

Inventar y Verificar


Lenguaje de Especificación RSL

• Características del lenguaje RSL

– Es formal.

– Posee facilidades de estructuración.

– Es un lenguaje de amplio espectro:

• Orientado a modelos y a propiedades.

• Aplicativo e imperativo.

• Secuencial y concurrente.

26


Objetivos de RSL

• Soportar grandes especificaciones modulares.

• Soportar un amplio rango de especificación: – Abstractas (cercanas al análisis).

– Concretas (cercanas al diseño).

• Proveer distintos estilos de especificación: – Axiomáticas y basadas en modelos.

– Aplicativas e imperativas.

– Secuenciales y concurrentes.


Abstracción en RSL

• Qué en lugar de Cómo

• RSL permite:

– Abstracción de datos.

– Abstracción de operaciones.


Abstracciones de Datos

type Persona && persona abstracto

type Persona = Text

type Persona = Nat

type Base && base abstracta

type Base = Persona-set && base usando conjuntos

type Base = Persona* && base usando listas


Abstracción de Operaciones

• Distintos estilos para definir funciones:

– Explícitas (Ejemplo 1)

– Axiomáticas (Ejemplo 2)

– Implícitas (Ejemplo 3)

30


6



Ejemplo 1 – Definición Explícita

• Definición de funciones explícita:

value


check (p, pad) p pad


Ejemplo 2 – Definición Axiomática

• Definición de función axiomática:

value


axiom

p: Persona check (p, vacia) false,

p, p1: Persona, pad: Padron

check(p1, insertar(p, pad)) p1= p check(p1,pad)

32


Ejemplo 3 – Definición Implicita

• Definición de funciones implícitas:

value

raiz: Real -~-> Real

raiz (r) as s

post s * s = r s 0.0

pre r 0.0


Relación de Refinamiento

Especificación Anterior

Especificación Nueva

1. Preserva Signaturas: La nueva signatura incluye la anterior.

2. Preserva Propiedades: Las propiedades anteriores se mantienen en la nueva (condiciones de refinamiento).

34


Ejemplo: un Paso del Desarrollo

Definición Abstracta para Padrón

Definición para Padrón utilizando Conjuntos


Condiciones de Refinamiento

p, p1: Persona, pad: Padron

check(p1, insertar(p,pad)) p1 = p check(p1,pad)

insertar : Persona >< Padron -> Padron

insertar (p, pad) pad {p},

check: Persona >< Padron -> Bool

check (p, pad) p pad

36


7



Verificación check(p1, insertar(p, pad)) p1 = p check(p1,pad)

• -->> unfold insertar

check(p1, pad {p}) p1 = p check(p1, pad)

• -->>unfold check

p1 (pad {p}) p1 = p p1 pad

• pertenece a la unión

p1 pad p1 {p} p1 = p p1 pad

• -->> pertenece al conjunto unitario

p1 pad p1 = p p1 = p p1 pad

• -->> conmutativa

p1 = p p1 pad p1 = p p1 pad

• -->> reducción

true

qed


Validación vs. Verificación

• VALIDACIÓN: es el chequeo de que se está creando lo correcto, esto es, lo que piden los requerimientos: “resolviendo el problema correcto”. Como los requerimientos son en lenguaje natural, la validación es informal.

• VERIFICACIÓN: chequea que el proceso de desarrollo es correcto. Incluye la formulación y justificación de relaciones formales entre pasos del desarrollo: “resolviendo el problema correctamente”. Puede tener distintos grados de formalidad.

38

RSL

• Las especificaciones en RAISE se hacen usando RSL:

– RAISE Specification Language, el lenguaje de especificación de RAISE

• A continuación vamos a presentar la definición del lenguaje, sus expresiones, constructores, etc.

• Se deja disponible un resumen con los conceptos del lenguaje que se requieren para en este curso (AyDS_Introduccion_RAISE-RSL.pdf).

• Más información se puede obtener en el link http://iist.unu.edu/search/node/RAISE


Organización RSL

• Una especificación en RSL consiste de definiciones de módulos.

• Los módulos son el medio para descomponer la especificación en partes manejables, comprensibles y reusables. Un módulo puede ser usado para definir otro módulo.

• Existen dos clases de módulos

– Esquemas (expresiones de clases)

– Objetos (instancias de los esquemas)



Módulos

Cada módulo consta de una colección de declaraciones con nombre.

• Una declaración comienza con una palabra reservada que indica el tipo de declaración, seguida por una o más definiciones de dicho tipo separadas por comas.

41

Declaraciones

Keyword Define …

Object Módulos embebidos

Type Tipos

Value Valores: constantes y funciones

Variable Variables que pueden almacenar valores

Channel Canales de entrada o salida

Axiom Propiedades lógicas que deben verificarse

Test case Expresiones a ser evaluadas por un traductor o Intérprete


http://iist.unu.edu/search/node/RAISE

http://iist.unu.edu/search/node/RAISE


8



Ejemplo – Padrón electoral

Presentación del problema:

– Una aplicación para un sistema electoral debe soportar la administración del padrón, identificando a todas las personas registradas como votantes.

– El sistema debe proveer las siguientes funciones:

• Registrar: Registra a una persona en la base de datos del padrón.

• Check: controla si una persona ha sido registrada en la base de datos del padrón.


Especificación RSL PADRON =

class

type

Persona,

Padron = Persona-set

value

vacio: Padron,

registrar: Persona X Padron → Padron,

check: Persona X Padron → Bool

axiom

vacio { },

p: Persona, pd : Padron registrar(p,pd) {p} pd,

p: Persona, pd : Padron check(p,pd) p pd

end

44


Definición de Tipos • Las definiciones de tipo tienen la forma:

type

definicion_tipo1,

….

definicion_tipon con n>=1

• Las expresiones de tipo se definen a partir de:

– Tipos predefinidos (build-in).

– De constructores de tipo.

– Subtipos de una expresión de tipo.

– Tipos definidos por el usuario.


Definición de Tipos

– Abreviadas: “id = expresión de tipo”

type

Punto = Real >< Real,

– Abstractas (o sorts). Para tipos no cuya definición final no se ha decidido.

type

Punto,

– Tipos registros

– Tipos variantes

46


Definición de Tipos - Ejemplos

type

Persona,

Padron = Persona-set

Donde:

• El tipo Persona es abstracto.

• El tipo padrón está definido como un conjunto de personas. El operador “-set” lo transforma en un tipo compuesto.

47

Tipos Predefinidos



9


Constructores de tipo


Ejemplos

Constructor Ejemplo Operadores

><

Nat >< Bool ><

Char (1,true,'a') ~

-set Int-set {}, {1, 2} ,card,\

* Int* <>,<1,2>

hd, tl, ,len,

elems, inds

-m-> Char->Bool

[], ['a'->true,

'b'->false]

dom, rng, hd,

\

50

Registros

• Similar a los registros en otros lenguajes:

type

Libro ::

titulo : Text

autor : Text

precio : Real


Definición de Valor

• Representan los valores para los tipos.

• Definen – constantes y

– funciones.

• Ejemplos value

x : Int,

cardinalidad : Int ● cardinalidad >= 2,

52


Definición de Valor: Constantes

• Constantes:

– Definición de valores explícita

value

x :Int = 1

– Definición de valores implícita

value

x : Int ● x >0

– Tipos (+ axiomas)

value

x : Int

axiom x >0 53 AyDS2012 - Clase 20- MMV

Definición de Valor: Funciones

• Definición de función explícita

value

f : Int → Int

f(x) ≡ x + 1

• Definición de función implícita

value

f : Int → Int

f(x) as r post r > x

• Tipos (+ axioms)

value f : Int → Int

axiom x: Int ● f(x)>x

54


10



Ejercicio Colas con listas Dada las siguientes definiciones:

type Elemento, Cola = Elemento*

value vacia : Cola = <>

capacidad: Nat = 10,

• Definir las funciones: – Encolar

– Desencolar

55

Object Constraint Language • Muchas veces un diagrama UML (i.e. un diagrama de

clases) no provee todos los aspectos importantes de la especificación.

– Es necesario poder describir restricciones extras sobre los objetos que figuran en el modelo

– Las restricciones especifican condiciones invariantes que deben ser satisfechas por el sistema a construir. Las restricciones pueden ser escritas en lenguaje natural, pero podrían resultar ambiguas.

• (-) Los lenguajes formales permiten escribir restricciones no ambiguas, pero en general no son de dominio masivo

• (+) OCL: es un Lenguaje Formal usado para expresar restricciones simple de escribir y leer.


OCL

OCL (Object Constraint language) es un lenguaje, que se puede ver como un agregado a la especificación 2.0 de UML.

• Provee una manera para expresar restricciones y lógica sobre los modelos.

Ejemplo: Sea un modelo sobre empleados y sucursales de una empresa, podemos querer expresar algunas restricciones adicionales a las que el modelo nos permite expresar:

– La edad de un empleado debe estar entre 18 y 70.

– Cada sucursal debe tener una secretaria cada 10 empleados.

– El legajo de un empleado no puede ser un valor nulo.


Características de OCL

OCL no modifica el modelo ni causa efectos colaterales (query only)

– La evaluación de una expresión OCL retorna un valor.

– La evaluación no altera el estado del sistema.

– Puede usar expresiones OCL para especificar un estado de cambio (por ejemplo, como post condición).

No es un lenguaje de programación

– No expresa lógica de programación.

– No puede invocar procesos.

Es un lenguaje tipado: cada expresión tiene un tipo

– Las expresiones bien formadas deben respetar las reglas de tipo.

– Los clasificadores definidos en UML representan tipos en OCL.

– Tiene un conjunto de tipos predefinidos.

La evaluación de una expresión OCL es instantánea


¿Cuando usar OCL?

Usar expresiones OCL para:

• Definir invariantes sobre clases del modelo de clases y sus propiedades (atributos).

• Describir condiciones pre y post de operaciones y métodos.

• Para describir guardas.

• Para especificar restricciones sobre operaciones.

• Especificar invariantes de estereotipos.

• Como un lenguaje de navegación.


OCL

• A continuación se presentan algunos elementos de la definición del lenguaje.

• Se deja disponible en la página de la materia un resumen con los conceptos del lenguaje que se requieren para en este curso (AyDS_Introduccion_OCL.pdf).

• Más información se puede obtener en el link http://www.omg.org/spec/OCL/2.3.1/


http://www.omg.org/spec/OCL/2.3.1/


11


OCL Tipos Predefinidos

• Tipos:

• Operaciones:


Tipos definidos por el usuario

• Además, todo clasificador (clase, asociación, interface, datatype) en UML es reconocido como un tipo en OCL.

– Ejemplo si se cuenta en el modelo con la clase CURSO, para OCL Curso es un tipo.

• OCL es fuertemente tipado, por lo tanto no se pueden comparar valores de un tipo directamente con valores de otro tipos.

• OCL soporta casting de objetos.


Contexto y Self

• Cada expresión OCL se escribe en el contexto de una instancia de un tipo específico.

Ejemplo: context Compañia

• La palabra reservada self se usa para referir a la instancia contextual.

• Por ejemplo, si el contexto es Compañía, entonces self se refiere a una instancia de Compañía.


Objetos y propiedades • Todas las propiedades (atributos, roles de asociaciones,

métodos y operaciones) definidas para los tipos de un modelo UML se pueden usar en expresiones OCL.

• El valor de la propiedad de un objeto definido en el diagrama UML se especifica con el punto seguido por el nombre de la propiedad.

• Ejemplos:

– En el contexto Persona self.edad, donde edad es un atributo de Persona. El tipo de la expresión es el tipo del atributo edad (int).

– En el contexto Persona self.empleador.nombre_compañia nombre de la compañía donde trabaja.

– En el contexto Compañía self.darNombre() denota el valor de la operación darNombre para la instancia definida por self.


Restricciones sobre operaciones

• También pueden usarse expresiones OCL asociadas a las operaciones para capturar pre y post condiciones, utilizando los keywords pre y post respectivamente.

• Para hacer referencia al resultado de una operación, en una expresión de poscondición se utiliza el keyword result

• Al igual que con las invariantes se puede dar un nombre a las expresiones.

context Factura::agregarItem(p: Producto): Boolean

pre hayStock: p.unidades > 0

post registracionExitosa: result = true


Temas de la clase de hoy

• Especificaciones Formales. – Generalidades

– Especificaciones Algebraicas

• RAISE – RSL – Presentación del Método.

• OCL

• Bibliografía: – Ingeniería de Software – Ian Sommerville (6ta Edición).

Capítulo 9.

– The RAISE Method – Introducción (Capítulo 1)

– The RAISE Specification Language

66

ANÁLISIS Y DISEÑO DE Software Principios

Documents

Transcript of ANÁLISIS Y DISEÑO DE Software Principios