De lo operativo a lo estratégico: un modelo de management de diseño
La prueba del software y los special purpose languages
1. “…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
2. 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
3. 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
4. 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
5. 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
6. Inicialmente confundida con debugging y
conceptualizada para ganar confianza.
Myers: el objetivo es detectar errores.
Una definición:
2.Qué es la Prueba de Software?
Proceso paralelo al de desarrollo para
determinar si el producto alcanza el nivel de
calidad acordado.
Con apoyo de herramientas (CAST) se
ejercita el sistema a probar (SUT)
aplicándole estímulos (TCs) diseñados con
métodos ingenieriles para detectar
insatisfacción de requerimientos.
8. 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”].
9. Alcances teóricos: no-decidible (Hk),
pero automatizable en algunos aspectos
semidecidibles
no-decidibles
Alcances de la Prueba de Software
semidecidibles
P
Testing
NP
10. 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).
11. 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
12. 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
14. 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
LLLLffff
Finite 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/
Recursive
Phrase
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
15. 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
18. LIT número
LOD variable
STO dirección
Un Conjunto de Instrucciones
STO dirección
JMP dirección
JMC dirección
OPN +|-|*|/|=|≥|…
19. 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; ...
20. • 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…
21. • 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
23. • 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.)
24. 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”).
25. 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 tiposbá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”).
26. • 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?
27. • Compilers: Aho, Sethi, Ullman;
Addison-Wesley
• Artículo “Software’s chronic Crisis”:
http://www.di.ufpe.br/~java/graduacao/refere
ncias/SciAmSept1994.html
Un poco de Bibliografía
• Formal Methods: hay una gran cantidad
de información en el web; algunos links
útiles son
http://www.fmeurope.org/
http://en.wikipedia.org/wiki/Formal_method
s #Formal_methods_and_notations
28. “…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