ingeniería del software automática -...
Post on 03-Oct-2018
215 Views
Preview:
TRANSCRIPT
3
Demandas comerciales
Performance-critical open networkingsystems that are costly to shut down.
Systems that must be secure, trustworthy,lightweight, and extensible.
Systems that must never crash and mustalways meet their deadlines.
4
Lo que se demanda esCalidad
FiabilidadSeguridadRobustezCorrecciónEficiencia
…incluso en el “software de consumo”
5
Software de alta seguridad
Source: NASA Jet Propulsion Lab
Como lograr extensibilidad y seguridad sin sacrificar la eficiencia?
7
Software “de consumo”
A MENUDO SINCONSENTIMIENTO!Se debenREFORZARlas técnicasconvencionales
NetscapeAcrobat
Drivers
Patches
8
Motivación (resumen):Sociedad de la Información
Hace 10 años: Areas de seguridadcrítica
Hoy: Inaceptables lasconsecuenciasde los fallos de software.
9
Fallos del software -> GRAVES catastrofeseconómicas (9% y va en aumento):SOFTWARE QUALITY CRISIS
Y la distinción entre “seguridad crítica” e“informática de consumo” desaparece
Alguien deberá proporcionar tecnología paragarantizar/mejorar la calidad del software.
DESAFÍO:¿ seremos nosotros?
10
Arianne 5
On June 4, 1996, the Arianne5 took off on its maiden flight.
40 seconds into its flight itexploded.
It was later found to be anerror in reuse of a softwarecomponent.
For the next two years,virtually every presentationused this picture.
11
“Better, Faster, Cheaper”
In Sept.’99, NASA lost both theMars Polar Lander and theClimate Orbiter.
Later investigations determinedsoftware errors were to blame.
– Orbiter: Component reuse error.– Lander: Precondition violation.
12
USS Yorktown
“After a crew member mistakenly entered a zero into the data field ofan application, the computer system proceeded to divide anotherquantity by that zero. The operation caused a buffer overflow, inwhich data leaked from a temporary storage space in memory, andthe error eventually brought down the ship's propulsion system. Theresult: the Yorktown was dead in the water for more than twohours.”
13
Security Attacks
The vast majority of security attacks exploit– input validation failure– buffer overflow– VBS (Visual Basic Scripts)
http://www.cert.org/summaries/CS-2000-04.html
Poke fun at Microsoft
14
Mobile/Wireless Devices
In ‘97, 101M mobile phones vs 82MPCs. (40% vs 14%.)
> 95% phones will be WAP enabled by‘06.
Battery life a primary factor.
Efficiency and bandwidth will still beprecious.
15
Warrantees?LIMITED WARRANTY. Microsoft warrants that (a) the SOFTWAREPRODUCT will perform substantially in accordance with theaccompanying written materials for a period of ninety (90) daysfrom the date of receipt, …
LIMITATION OF LIABILITY. TO THE MAXIMUM EXTENTPERMITTED BY APPLICABLE LAW, IN NO EVENT SHALLMICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANYSPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIALDAMAGES WHATSOEVER (INCLUDING, …) ARISING OUT OFTHE USE OF … THE SOFTWARE PRODUCT…MICROSOFT’S ENTIRE LIABILITY … SHALL BE LIMITED TOTHE GREATER OF THE AMOUNT ACTUALLY PAID BY YOU FORTHE SOFTWARE PRODUCT OR U.S. $5.00; PROVIDED...
16
Automotive Analogy
“If the automobile had followed the samedevelopment as the computer, a Rolls-Roycewould today cost $100, get a million miles pergallon, and ...
17
Automotive Analogy
“If the automobile had followed the samedevelopment as the computer, a Rolls-Roycewould today cost $100, get a million miles pergallon, and explode once a year killingeveryone inside." - Robert Cringely
20
España: Plan Nacional 2004-2007
Programa TIN:Acción estratégica “SOFTWARE FIABLE”
EEUU, Informe PITAC:
“la economía y seguridad americanas dependen del software y éstese comporta de manera peligrosa. Las necesidades de correccióncrecen más aprisa que la capacidad actual de producir softwaredemostradamente correcto”
-> triplicar la inversión en MFIS para desarrollar la tecnología quedemanda la SI del siglo XXI
UE: IST 6 Framework Programme: la calidad del SW esfundamental para el liderazgo europeo en la “economía delconocimiento”
23
Ing. Del Software Automáticay MFIS:
(Subcampo de la IS orientado a garantizar laSeguridad, Fiabilidad, Robustez, Corrección,
Eficiencia, Extensibilidad, Escalabilidad)
FMs
Strong FMs
ISA= Lightweight FMs
24
Ing. Del Software Automática:Métodos Formales de la I. S.
“A formal method (of SW development) isa process (for developing SW) thatexploits the power of mathematicalnotation and mathematical proofs”J. Wordsworth
“A strong formal method is a FM that issupported by an automated tool”D.Schmidt
25
Ing. Del Software Automática:
• Salto cualitativo! no avance convencional• Nuevas técnicas y herramientas
automáticas (industriales)
• PARADOJA!!!!!! 20 años atrás
26
Ing. Del Software Automática:
Sólidos fundamentos formales:
• métodos de generación rigurosos• técnicas de análisis y evaluación
basadas en la semántica• soporte automático
27
Rôle of Semantics?? (vs JAVA, UML...)
The excessive optimism of
”EVERYTHING important is provable”
helps to explain the excessive pessimism
of ”NOTHING provable is important”
28
Change your mind:
“Push-button” technology!
NO a los MFIS que requieren:
• un “PhD en Lógica”
• unos recursos que no se pueden
invertir
29
A Lightweight Approach_____________________________________
“A lightweight approach, in comparisonto the traditional approach, lacks powerof expression and breadth of coverage.
A surgical laser likewise produces less powerand poorer coverage than a lightbulb, but itmakes more efficient use of the energy itconsumes, and its effect is more dramatic”
[Jackson and Wing 1996]
30
Características Lightweight:
Parcialidad como criterio (en laexpresividad, en la especificación, etc)
Selectividad (adaptado al dominio) Integración (combinación con métodos
convencionales) Transparencia del formalismo al usuario Bajo coste (e.g. Tecnología Declarativa)
33
Ejemplo:Seguridad del código
Oportunidades y desafíos para:
–lógica aplicada (programaciónlógica,sistemas de tipos)
–diseño de lenguajes deprogramación (compilación)
-> Proof-carrying code (PCC)
INDICEPrimera parte
Motivación (desafíos y oportunidades) Visión tradicional de los MFIS La Trilogía del Sw Lightweight Formal Methods(Lógicas para Aplicaciones Software)
Ing. Del Software Automática
37
¿Qué son los MFIS?http://www.afm.sbu.ac.uk
http://www.comlab.ox.ac.uk/archive/formal-methods.htm
a hundred notations a thousand people
(“formal methodists”)
38
70/80’s Agencia Nacionalde Seguridad EEUU
Especificación Verificación
Certificación Validación
200X’s Aplicaciones paraInternet
RAICES:
¿Qué son los MFIS?
1980
1985
1990
USA ~~~~~~~~~~~~ Europa
Herramientas:
Verificación
Notaciones:
Especificación
RAICES:
¿Qué son los MFIS?
1970
1980
1985
1990
1996 ACM Strategic Directions Workshop (June, MIT)
Hoare, Dijkstra (asertos, wp)
Clarke&Emerson Model Checking Guttag&Parnas ADT’s HerramientasDe Verificación: theorem proversmodel checkers FM’89 CLIne “stack” (Washing.)
Pnueli L. Temporal Milner, Hoare CCS, CSP
Notaciones De Especificación:
Z, B, VDM, OBJ
IBM CICS (Oxford)
USA ~~~~~~~~~~~~ Europa
IDEA POPULAR:
Los Métodos Formales son lenguajes,técnicas y herramientas basados enlas matemáticas (lógica y álgebra) yutilizados para especificar y verificarsistemas software
¿Qué son los MFIS?
verificaciónsi o no
especificación
programa
Aplicaciones de seguridad crítica– Transporte: aviación, trenes,
buques– Medicina, Nuclear, Construcción
Aplicaciones con restricciones detiempo críticas– Transacciones bancarias,– Telecomunicaciones
Aplicaciones de privacidad yseguridad de datos crítica– Comercio electrónico
Estándares– Protocolos, librerías software
Areas de aplicación tradicionales
Menores costes de desarrollo ymantenimiento (detección precoz deerrores, verificación más simple,mayor fiabilidad)
Mejor comprensión del sistema(clarificación de requerimientos deusuario, buena documentación)
¿Por qué usar MétodosFormales?
Thou shalt choose an appropriate notation. Thou shalt formalise but not overformalise. Thou shalt estimate costs. Thou shalt have a formal methods guru on call. Thou shalt not abandon thy traditional
development methods. Thou shalt document sufficiently. Thou shalt not compromise thy quality standards. Thou shalt not be dogmatic. Thou shalt test, test, and test again. Thou shalt reuse.
Los Diez Mandamientos de los MFIS(Bowen & Hinchen, IEEE Computer 95)
Mitos sobre los Métodos Formales (A. Hall, IEEE Software 1990)
1. Pueden garantizar que el software es perfecto.No, pero ayudan a la detección precoz y eliminación de errores
2. Están limitados al área de la demostración automática de teoremas.Numerosas áreas de aplicación en software
3. Útiles únicamente en áreas de seguridad crítica.Pueden traer beneficios en otrás áreas de aplicación
4. Requieren amplios conocimientos de matemáticas.Una especificación formal es más simple de comprender que un programa
5. Incrementan los costes de desarrolloPueden reducir los costes
6. Inaceptables para los clientes.Pueden ser transparentes al cliente
7. No se usan para software a gran escala.Ha habido muchas aplicaciones con éxito en la industria
10 Mitos más sobre Métodos Formales Bowen & Hinchen, IEEE Software 95
8. Retrasan los tiempos de desarrollo.Pueden reducir los plazos
9. No existen herramientas de soporte.Existen algunas herramientas, incluso de dominio público
10. Son alternativos a los métodos tradicionales en ingeniería.Son complementarios
11. Sólo se aplican al diseño del software.Igualmente se aplican al diseño del hardware
12. No son necesarios.Son interesantes en muchas aplicaciones
13. No existen estándares.Existen varios estándares
14. La comunidad de MF’s siempre usa MF’s.Algunos aspectos se abordan mejor de otra forma
INDICEPrimera parte
Motivación (desafíos y oportunidades) Visión tradicional de los MFIS La Trilogía del Sw Lightweight Formal Methods(Lógicas para Aplicaciones Software)
Ing. Del Software Automática
Propiedades
Datos Programas
EspecificacionesRequerimientosTipos...
Juegos de Datos
Seq:TrazasOut: EscenariosIn: Ejemplos
CódigoDocumentación
ANALISIS DISEÑO IMPLEMENTAC. Programa
Ciclo de Vida Clásico
VALIDACIÓN TEST - α TEST - β
MANTENIMIENTO
ANALISIS ESPECIFICACIÓN IMPLEMENTAC. Programa (informal)
Ciclo de Vida con Prototipado
MANTENIMTO.
TEST - α / β
VALIDACIÓN Prototipo
PROTOTIPADO
ANALISIS ESPECIFICACIÓN OPTIMIZACIÓN REQUERIM. FORMAL MECÁNICA
(Prototipo)
Programación Automática
VALIDACIÓN
MANTENIMTO.
Programa
Ejemplo de especialización: Función “x^n”
exp(x,n) = if n=0 then 1
else if par(n)
then exp(x,n/2)^2
else exp(x,n-1)*x
exp(x,5) = exp(x,4)*x » (exp(x,2)^2)*x) » ((x^2)^2)*x
Programa especializado:exp5(x)= ((x^2)^2)*x
Especialización de programas paramétricos: Mejoras de hasta el 400%!
–Reconocimiento de patrones–Sistemas expertos–Redes neuronales–Deductive BD’s queries–Gráficos (ray tracing)–Computación numérica, científica
Optimización de programas
Compilación y Generación de compiladores: PROYECCIONES DE FUTAMURA
Aplicaciones
67
Introducción
Esencia de la PE:[[ P ]] [in1,in2] = output
[[ mix ]] [P,in1] = Pin1[[ Pin1 ]] [in2] = output
[[ P ]] [in1,in2] = [[ Pin1 ]] [in2] = [[ [[mix]] [P,in1] ]] [in2]
mix
in1
P
in2 Pin1 output
in1
in2 P output
68
1ª Proyección Futamura
mix hace el papel de compiladoroutput = [[ fuente ]]S [input]
= [[ int ]] [fuente,input]= [[ [[ mix ]] [int,fuente] ]] [input]
= [[ objeto ]] [input]
objeto = [[ mix ]] [int,fuente]
69
2ª Proyección Futamura
genera compilador a partir de intérprete (automáticamente)
objeto = [[ mix ]] [int,fuente]= [[ [[ mix ]] [mix,int] ]] [fuente]= [[ comp ]] [fuente]
comp = [[ mix ]] [mix,int]
70
3ª Proyección Futamura
produce un “generador de compiladores”
comp = [[ mix ]] [mix,int]= [[ [[ mix ]] [mix,mix] ]] [int]= [[ gen_comp ]] [int]
gen_comp = [[ mix ]] [mix,mix]
Datos Programas
Inferencia Inductiva(Síntesis de Programas a partir de Ejemplos)
Generación Juegos de DatosTesting Estructural (white-box)
1. Definir caminos de prueba 2. Generar bancos o juegosde datos que hagan seguir cada camino(acumulando las ‘constraints’ que definen los arcos del camino yaplicando técnicas deCONSTRAINT SOLVING)
Datos Programas
Generación Juegos de Datos
Datos
Propiedades
Gener
ación
de E
scen
arios
Tes
ting Fu
nciona
l (blac
k-bo
x)
Infere
ncia In
ductiva
(Apr
endiza
je de Es
pecif
icacio
nes)
Minería de Datos
Verificación Formal
Análisis Estático
Inferencia de Tipos
Síntesis Programas
a partir de espec.
Datos Programas
Inferencia Inductiva
Generación EscenariosIn
fere
ncia In
ductiva
Propiedades
Gener
ación
Esce
nario
s
Transformación de Programas
Prototipado
Minería de Datos
Model Checking
Datos Programas
Propiedad3. ¿?
K |= Ψ
2. Compilación
a Kripke K
4. Generaciónde escenarios(contraejemplo)
1. Especificación enLógica Temporal
Ψ
Model Checking
Datos Programas
Propiedad
¿? K |= Ψ
Generaciónde escenarios
errores en protocolos FTP - file transfer autentificación claves coherencia caché disk encriptación alg. div. Pentium comercio electrónico
Fórmulas CTL típicas
Alcanzabilidad EF RestartEs posible alcanzar el estado Restart
Seguridad AG ¬BoomNo es posible alcanzar el estado ¬Boom
Vivacidad AG [Req → AFAck]Todo requerimiento alguna vez se atenderá
Equidad AG AF DeviceEnabledLa propiedad DeviceEnabled se satisfaceinfinitas veces en toda computación
Programas
Propiedades
Datos
DiagnósticoDeclarativo 2. Especificación
de la Semántica(ORACULO)
3. Analiza (abstract)CORRECCIÓNCOMPLETITUD
(1. Síntoma)
4. Diagnosticafuentes de error 5. Reparacódigo
ejemplo de detecciónde una regla incorrecta
Criterio: Si existe A ∈ Tr(S) tal que A ∉ S
entonces r es incorrecta
P.ej., sea el programa incorrecto: par(0). par(s(X)) :- par(X).
y la semántica S={par(0),par(s(s(0))}
Ejemplo de reparación deprograma incorrecto
(síntesis a partir de ejemplos)PROGRAMA INCORRECTO
par(0) = truepar(s(x)) = par(x)
“EJEMPLOS” de los que“aprender”
E+ = {par(0), par(s(s(0))}E- = {par(s(0)}
Ejemplo de reparación deprograma incorrecto
PROGRAMA “desplegado”
par(0) = truepar(s(0)) = truepar(s(s(x))) = par(x)
=> Eliminar reglasegunda
PROGRAMA INCORRECTO
par(0) = truepar(s(x)) = par(x)
“EJEMPLOS” de los que “aprender”
E+ = {par(0), par(s(s(0))}E- = {par(s(0)}
Programas
Propiedades
Datos
Proof Carryingcode
2. Validarprueba
1. CompiladorCertificante:Código + prueba
86
Proof-Carrying CodeUna Analogía
A
B
Prueba formal o“explicación” de seguridad
Código máquina
(optimizado)
rlrrllrrllrlrlrllrlrrllrrll…
Una implementación de PCCcontiene (a nivel de consumidor):
Un lenguaje para expresar la política deseguridad Una semántica formal del lenguaje deimplementación (una lógica que relacioneprogramas con especificaciones) Un lenguaje para expresar las pruebas Un algoritmo para validar las pruebas
http://www.cs.cmu.edu/~petel/
Verificación Formal
Análisis Estático
Inferencia de Tipos
Progr. automática
Datos ProgramasInferencia Inductiva
Gen. Escenarios
Gen. E
scen
arios
Propiedades
Prototipado
DiagnósticoDeclarativo
Transformación
Infere
ncia In
ductiva
PCC Model Checking
Minería de Datos
93
Ing. Del Software Automática
Técnicas formales yherramientas industrialespara desarrollo y mantenimiento racional ysistemático del Software
• especificación, verificación y validación(model checking, PCC)
• diagnóstico y depuración• análisis, síntesis y certificación• transformación, aprendizaje y optimización
INDICEPrimera parte
Motivación (desafíos y oportunidades) ¿Qué son los MFIS? La Trilogía del Sw Lightweight Formal Methods(Lógicas para Aplicaciones Software)
Ing. Del Software Automática
Lógicas para Aplicaciones Software
La lógica proporciona una formulaciónsimbólica e independiente del dominiode las leyes del pensamiento humano
Este doble carácter de la lógica haceposible mecanizar sus técnicas y métodos
PROBLEMA
La lógica clásica se desarrolló para estudiar objetosmatemáticos bien definidos, consistentes einmutables -carácter estático-
Sus nuevas aplicaciones requieren formas másdinámicas (y menos perfectas) de lógica
Los métodos de la lógica, en general, resultan carosen términos computacionales -> es necesarioreducir sus costes sin perder sus buenaspropiedades lógicas
Lógicas para Aplicaciones Software
Lógicas para Aplicaciones Software
SOLUCIÓN: Lógica Computacional (Lógicas para Aplicaciones Software)
Lógicas con la expresividad y la potenciacomputacional adecuadas para:
Modelar el conocimiento impreciso, incompleto,contradictorio, revisable, dinámico, distribuido...
Razonamiento no monótono, aproximado,probabilístico, temporal...
Lógicas para Aplicaciones Software
Lógicas para especificación de Software(prototipado)
Lógicas para validación y certificación de Software (PCC) Lógicas para la verificación y la concurrencia (model checking) Lógicas para el Conocimiento (Web semántica) Lógicas para el Razonamiento aprox.
y probabilistico Lógicas para el Control Lógicas para las Comunicaciones Lógicas para el Diseño de Lenguajes (e.g. visuales)
Lógicas para Aplicaciones Software
Lógicas para especificación de Software L. C. Horn(prototipado) L. Ecuacional Lógicas para validación de Software (PCC) HO + types Lógicas para la Concurrencia (Model Checking) L. Temporal Lógicas para el Conocimiento (Web semántica) R + F + dinámica Lógicas para el Razonamiento probabilistico L. Probabilíst Lógicas para el Control L. Fuzzy Lógicas para las Comunicaciones L. Lineal Lógicas para el Diseño de Lenguajes L. Diagramát (e.g. visuales)
Lógicas para la Ingeniería del Conocimiento y las BDsLógica modal: epistémica, temporal, dinámica, ...
Lógicas para el Razonamiento aprox. y probabilisticoLógica geométrica, lógica probabilística
Lógicas para el Control y las Comunicaciones:Lógica lineal, lógica difusa
Lógicas para la Programación VisualLógica diagramática, lógica pictórica
ICEBERG: Lógicas para otras Areas deEspecialización en Software:
LOGICA DIFUSA (Fuzzy Logica )
*** una LOGICA Multivaluada (en vez de binaria) ***
Se usa para soportar el RAZONAMIENTO APROXIMADO en ROBÓTICA Y SISTEMAS EXPERTOS:
inferencias lógicas sobre propiedades y relaciones imprecisas.
EJEMPLOS: optimización automática del ciclo de lavado de una lavadora en función de la carga, cantidad de detergente, etc; control de ascensores, electrodomésticos, cámaras,
instrumentación de automóviles, naves y armamento nuclear.
En LÓGICA CLÁSICA: 0 or 1, blanco o negro, si o no; (en términos del ALGEBRA BOOLEANA: cada elemento está en un conjunto o en otro, pero no en ambos)
En LOGICA DIFUSA valores entre 0 y 1, tonos del gris (pertenencia parcial a un conjunto)
En lógica difusa, las fórmulas tienen un valor de verdad entre 0 y 1
Los hechos pueden ser ciertos hasta un cierto grado El agua está fría (0.7)
Aplicaciones en Control Difuso (Robótica, S. Expertos)
Lógica Difusa
x elemento; S conjunto; Sx nº real entre 0 y 1 (denotando el grado en que x pertenece a S)
(A∪B)x = max (Ax,Bx) (A∩B)x = min(Ax,Bx) (¬A)x = 1 – Ax
F conjunto de las proposiciones falsas; T verdaderas. t(p)= (1-Fp+Tp)/2 (verdad de p)
t(¬a) = 1 - t(a)t(a∧b) = min(t(a),t(b))t(a→b) = max(1-t(a),t(b))
Lógica Difusa (cont.)
Nuevas conectivas lógicas: ! of course (copiado - replicación)? why not (borrado)
Separación en dos clases de las conectivasestándar :⊗ y & (conjunción acumulativa y alternativa)+ y ⊕ (disyunción directa y tensorial )
Lógica Lineal
Nuevos cuantificadores (modales) � UNIVERSAL (always, necesidad)♦ EXISTENCIAL (sometimes, posibilidad)
para formalizar el tiempo, las creencias, etc..
Ejemplo: estudiante(A) ⇒ ♦ profesional(A)
Lógica Modal
Interpretaciones � A
necesariamente es verdad A debe suceder A
siempre será verdad A
cuando termina el programa, esverdad A
es conocido A (se cree A)
Interpretaciones ◊ A
posiblemente es verdad A puede suceder A
a veces será verdad A
existe una ejecución delprograma que terminasiendo A verdad
no se conoce (no se cree) elopuesto de A
(◊ A = =def ¬ � ¬ A)
Lógicas Modales
Lógicas Modales (taxonomía)
Lógicas Temporales (lógicas del tiempo)– � A (always A)– ◊ A (sometimes A)
Lógicas Dinámicas(lógicas de la acción, lógica modal pararazonar acerca de las acciones y procesos)
Lógicas Epistémicas(lógicas del Conocimiento y dela Creencia/Ignorancia)
Definimos un predicado auxiliar VPcontDecVPcontDec ≡ G [VP(v) → X VP(v’) & v’<v]
Ahora el enunciado temporal se escribiría:
¬PM(M) R VPcontDec
Lógicas Temporales
TAXONOMIA
–Discrete & Linearly Ordered Time(LTL)
–Branching Time (CTL, CTL*)– Interval Logic (FIL y GIL)–Dense Time...
Investigación Básica– Combinación de Teorías Matemáticas (e.g. Lógicas)
y Lenguages Multiparadigma– Integración de Métodos
(Abst Interpretation en PCC, Model Cheching, etc)– Composicionalidad de la semántica
Desarrollo de Herramientas Lightweight(push-button, usuarios inexpertos)
Educación y Transferencia Tecnológica– Nuevos especialistas: metodistas software
(expertos en calidad)– Nuevas “firmas comerciales”: oficinas de “certificación”
Problemas Abiertos
clausal logic Relational(Prolog)
equational logic Functional(Haskell)
many sorted logic typesorder sorted logic inheritancemodal logic: dynamic objects
temporal concurrencyepistemic knowledgedeontic norms
Multiparadigm Programming
Bibliografía
D. Le Metayer et al. Exploring the Software DevelopmentTrilogy, IEEE Software, pp. 75-81, Dec 1998.
K.-K. Lau, M. Van Bossche. Logic Programming for SoftwareEngineering, A Second Chance, Invited talk ICLP’02
G. Necula. Proof-carrying code, Proc. ACM POPL’97, , pp. 106-119
E. Astesiano, G. Reggio. Formalism and Method, TheoreticalComputer Science 236:3-34, 2000
J. Wing. Formal Methods, State of the Art and FutureDirections, ACM Computer Surveys, 28(4):626-643,Dec 1996(http://www.cs.cmu.edu/afs/cs.cmu.edu/user/wing/www/).
top related