“…A testing company with comparable assessment results is hard to

find in the world. Only companies in high-risk industries, e.g.

pharmaceutics, defense and aviation, achieve higher scores”.

Martin Pol

Polteq, 2008

Agenda

1. “Crisis del Software”• Problemática y Soluciones planteadas

2. Prueba de Software• Definición y Alcances

3. Métodos formales3. Métodos formales• Planteamiento general

4. Lenguajes de Computación propietarios• Clases, Tipos, Enfoque

5. Preguntas clave para desarrollarlos• Cuestionamientos importantes iniciales

1. Incremento en la demanda�Legacy systems; embedded software

�Cada vez más áreas de aplicación

1.La “Crisis del Software”

�Herramientas y capacitación para

técnicos y no-técnicos

�Re-Uso de software

2. Incremento en la complejidad�Sistemas de software+firmware+

hardware

�Tamaño

Crisis del Software

�Tamaño

�Ambientes de desarrollo (CASE Systems)

�Lenguajes de computación

�Metodologías

3. Exigencia en la calidad�Critical systems

�Globalización y educación de los clientes

Crisis del Software

� Total Quality Management for software

� Mejora de procesos (CMMI,MoProSoft,etc.)

� Prueba de Software

Inicialmente confundida con debugging yconceptualizada para ganar confianza.

Myers: el objetivo es detectar errores.

Una definición:

2.Qué es la Prueba de Software?

Proceso paralelo al de desarrollo paradeterminar si el producto alcanza el nivel decalidad acordado.

Con apoyo de herramientas (CAST) seejercita el sistema a probar (SUT)aplicándole estímulos (TCs) diseñados conmétodos ingenieriles para detectarinsatisfacción de requerimientos.

e1

e2

e3

isóceles

equilátero

escaleno

Un Ejemplo clásico

no es triángulo

Cuántos Casos de Prueba?

Cuántos recursos para probar?

Automatizar?

(105 ) 3 = 1015

4,000*25*400=4*107

Alcances prácticos:

� Cantidad de posibilidades inmanejable [“Principio Heurístico sobre Algorítmico”].

� Una técnica de prueba (pesticida) no es suficiente para detectar todos los defectos (bugs) [“Principio del Pesticida”].

Alcances de la Prueba de Software

(bugs) [“Principio del Pesticida”].

� La organización que desarrolla no debe probar [“Principio de la Independencia”].

� La complejidad del software (y por lo tanto la de los errores) crece hasta los límites de nuestra habilidad para manipular esa complejidad [“Principio de la complejidad”].

Alcances teóricos: no-decidible (Hk),

pero automatizable en algunos aspectos

semidecidibles

no-decidibles

Alcances de la Prueba de Software

semidecidibles

P

Testing

NP

Detectar, con recursos limitados,

la mayor cantidad de defectos,

Objetivo de la Prueba de Software

lo más nocivo posible,

lo antes posible…

aplicando técnicas ingenieriles (Hks).

1.Establecer alcances,

criterios de éxito y

entregables

2.Estimar del Esfuerzo del

Prueba

3.Planear el Proyecto

Proceso de Prueba (Nivel 1)

4.Reproducir el contexto

del SUT

5.Diseñar y aplicar las

Pruebas

6. Obtener métricas y dar

resultados 7. Administrar Anomalías

8.Cerrar

3. Exigencia en la calidad�Critical systems

�Globalización y educación de los clientes

Crisis del Software

� Total Quality Management for software

� Mejora de procesos (CMMI,MoProSoft,etc.)

� Prueba de Software

� Métodos formales

Requerimientos

formales

Diseño LLLLxxxx

3.Métodos formales: Planteamiento

Diseño

formal

Código

fuente

LLLLyyyy

LLLLzzzz

N → β

N → t | t1 N1LLLL3333

LLLL2222

LR

LL

Type Name Rules Examples .

Regular

Context

free

ai bj ck dm i,j,k,m

independent

ak bk2 cn dn-1

an bn ∪ an b2n

Regular

Expressions

Syntax

Graphs

LLLLffffFinite an bn , K1≤ n≤ K2

ak bn cn d k

an bn, 0≤ n

(det)Computer Lgs

Jerar

quía

de β1 N β2 → β1 α β2LLLL1111

LLLLeeee

LLLL0000

LLLLgggg

Context

sensitive

Decidable/

RecursivePhrase structure/

General

α → β

α → β, |α| ≤ |β|

an bn cn

Graphs

None (it’s impossible)

ak bn ck dn

a

1st Order Pre-

dicate Calculus

{⟨M⟩ | LLLL(M)∈ LLLLe }

L={}, L∈LLLL3,2

n2

?

Recursively enumerable

Natural Lgs

de

Chom

sky

Constitución de un Compilador

Analizador léxico

(scanner)

Analizador sintáctico

(parser)

Analizador

semántico

Brincar

caracteres

Verificar orden de las

cadenas en L1

Validar significado

de las cadenas

Manejador

de Errores

Generador

de Código

caracteres

irrelevantes

Identificar

cadenas

relevantes

Detectar, informar y

saltar errores

Generar código en

otro lenguaje L2

preservando el

significado

token

lexema

Generación automática

de Parsers a partir de

Ejemplo de un Método Formal

de Parsers a partir de

Grafos de Sintaxis

Desarrollo de

Compiladores para

4. Lenguajes propietarios

Compiladores para

proprietary special Purpose

Languages

LIT número

LOD variable

STO dirección

Un Conjunto de Instrucciones

STO dirección

JMP dirección

JMC dirección

OPN +|-|*|/|=|≥|…

LOD A

LOD B

LIT 3

OPN /

OPN +

JMZ L1

LOD B

LIT 1

OPN +

STO A

En la otra Dirección: Patrones

OPN +

LIT 10

OPN ≥≥≥≥

JMP L2

LIT 5

STO B

…

A+B/3≥10 (≈ ⟨C⟩)

L1:

L2:

IF ⟨C⟩ A := B+1;

ELSE B := 5; ...

• Se decía que con FORTRAN se hacía “programación automática”.

• Se argüía que los programas en FORTRAN eran muy ineficientes.

Al inicio…

Antiguos comentarios

• La generación de código incrementaba significativamente la productividad.

• La programación en el lenguaje de alto nivel era menos propensa a errores, lo cual incrementaba la calidad.

Pero…

• De Especificación• De Arquitectura• De Documentación• De Definición de

Procesos

Lenguajes de Computación

Procesos

• De Programación

La Torre de Babel

de la Computación?

☺

– 4GL

Lexical

Analizer

Syntactic Analizer Interme-

diate Code

OptimizerBuffer

De

vic

e

De

vic

e

Ch

ars

Co

de

in L

3

So

urc

eC

od

ein

L1

System…

dependentindependent

but “concrete”

(cuasi-) independent

& abstract

(semi-)

dependentdependent

Back-end

Co

de

op

tim

ize

d

Co

de

in L

2

Front-End

Lexe

me

Constitución de un Compilador (2)

Identifier Table

Target

Code

Generator

Inp

ut

De

vic

e

Ou

tpu

t D

evic

e

Ch

ars

Targ

et

C

od

e

Blo

ck o

f ch

ars

wit

hS

ou

rce

Semantic

Analizer

Error

Recovery

Mechanism

Intermediate

Code

Generator

Inte

rme

dia

teC

od

e

Inte

rme

dia

teC

od

e

Toke

n&

Lexe

me

• Elementos independientes del Dominio de

Aplicación: Mecanismos/Constructos propios

de todo procesamiento: secuenciación,

alternación y repetición de tareas.

Partes de un Lenguaje de Programación

• Elementos dependientes del Dominio de

Aplicación: Mecanismos/Constructos

especiales para facilitar procesos propios del

área (strings, matrices, tablas de empleados, conjuntos, etc.)

Abstracciones de Control

Básicas

Abstracción de pa-

trones comunes de

programación:

- goto’s|

- asignaciones

- llamadas a subru-

Estructuradas

Instrucciones “single-entry,

single-exit”:

- alternación: (guarded) if’s,

switch’es

- repetición:

(guarded) do’s, for’s

De Unidad

Agrupamiento físico

de:

- Abstract Data

Types

- Módulos con ope-

raciones relacio-- llamadas a subru-

tinas

- return’s

(guarded) do’s, for’s

- abstracciones de instrucciones

(bloques, procedimientos,

funciones)

- manejo de excepciones

raciones relacio-

nadas (“librerías”).

Abstracciones de Datos

Básicas

Abstracción de

representaciones

internas de tipos de

datos comunes, i.e.

tipos de datos

básicos (predefini-

Estructuradas

Tipos de datos compuestos

definidos utilizando cons-

tructores de tipos como:

- secuencia (<s1, s2, …, sn >,

v.gr. arreglos y strings)

- registro (×)

De Unidad

Agrupamiento

físico de datos

relacionados:

- Abstract Data

Types

- Módulos con tipos básicos (predefini-

dos):

- ordinal: caracter,

entero, booleano,

enumerado

- continuo: real, con

distintas precisiones

- rangos

- registro (×)

- registro variable (∪)

- función (ƒ:T→U)

- conjunto (℘)

- apuntador

- tipos recursivos (listas; árboles)

- archivos

- “tipo nulo” (void)

- Módulos con tipos

relacinados

(“librerías”).

• Han sistematizado o formalizado (partes de) su proceso de desarrollo?

• Se han especializado en un Dominio de Aplicación?

•Hacen reuso de software sistemática-

5. Preguntas clave para desarrollarlos

•Hacen reuso de software sistemática-mente pero la parametrización es complicada, llena de detalles y propensa a errores??

• Han detectado patrones con los que pudiera desarrollarse un Lenguaje de Programación propietario?

• Compilers: Aho, Sethi, Ullman;Addison-Wesley

• Artículo “Software’s chronic Crisis”:http://www.di.ufpe.br/~java/graduacao/referencias/SciAmSept1994.html

Un poco de Bibliografía

• Formal Methods: hay una gran cantidadde información en el web; algunos linksútiles son

http://www.fmeurope.org/

http://en.wikipedia.org/wiki/Formal_methods #Formal_methods_and_notations

“…A testing company with comparable assessment results is hard to

find in the world. Only companies in high-risk industries, e.g.

pharmaceutics, defense and aviation, achieve higher scores”.

Martin Pol

Polteq, 2008