Disciplina de Construcción

del Software
Clase # 1
Ing. Christian Vega
Uso de API y manejo de errores

Clase # 1
Ing. Christian Vega
 Propósito de la Clase

• Al finalizar la asignatura, el estudiante estará en condiciones de

implementar el software de su proyecto de fin de curso a partir del
análisis, requerimientos y diseño de software. 
 Motivación

• Hoy en día casi todo jefe de proyecto, diseñador o desarrollador habla

de la ‘economía API’ como el nuevo mundo. Las interfaces de
desarrollo de aplicaciones no son algo novedoso, pero sí es cierto que
su universalización se está produciendo en estos días. 2020 y 2021
serán los años en los que la utilización de APIs se generalice entre la
mayoría de empresas que busca aumentar y diversificar sus canales
de creación y de ingresos. No solo grandes corporaciones, también
pymes y startups.
 Índice

• Diseño y uso del API

• Parametrización y clases genéricas
• Aserciones, diseño por contrato y programación defensiva
• Manejo de errores, manejo de excepciones y tolerancia a los fallos
 Qué es una API

• Son un conjunto de comandos, funciones y protocolos informáticos

que permiten a los desarrolladores crear programas específicos para
ciertos sistemas operativos.
• Las API simplifican en gran medida el trabajo de un creador de
programas, ya que no tiene que «escribir» códigos desde cero. Estas
permiten al informático usar funciones predefinidas para interactuar
con el sistema operativo o con otro programa.
 Ejemplo de una API

• Cuando el usuario compra entradas a través de la página web de una

sala de cine e introduce la información de su tarjeta de crédito, la web
usa una API para enviar dicha información de forma remota a otro
programa que verifica si los datos bancarios son correctos.
• Una vez que se confirma el pago, la aplicación remota envía la
información al sitio web del cine y le da un «OK», por lo que esta
página emite los tickets.
 Ejemplo de una API

• En todo ese proceso, el usuario solo ve una cara del proceso, la página
del cine, pero tras bambalinas hay muchas aplicaciones que se están
comunicando gracias a las API.
• En la web encontramos site donde hay una columna lateral que tiene
varios iconos de redes sociales, como Facebook, Twitter y Google+.
Estos son enlaces que se encargan de «llamar» a las APIs asociadas a
esos servicios para que el usuario pueda «tuitear» o compartir la
información en Facebook sin tener que salir de la página web.
Cronología de la historia de las API
 ¿Para qué necesitamos una API?

• Ofrecer datos a aplicaciones que se ejecutan en un movil

• Ofrecer datos a otros desarrolladores con un formato más o
menos estándar.
• Ofrecer datos a nuestra propia web/aplicación
• Consumir datos de otras aplicaciones o sitios Web
 Características que debe tener una API

• La comunidad de desarrolladores siempre tiene presente cuatro

características fundamentales para puntuar la calidad de una API:
1. Debe ser útil y fácil de aprender
2. Estable frente a las mejoras
3. Segura
4. Ofrecer una buena documentación
 Características que debe tener una API
Debe ser útil y fácil de aprender

• Si una API no es fácil de usar y su adopción por un desarrollador

no es intuitiva, la API no cumplirá con su cometido: captar
clientes y expandir la influencia de una empresa más allá de las
cuatro paredes de su oficina.
• No tiene sentido desarrollar una API que no es un tentáculo, una
extensión de los valores, del talento para dar servicio y generar
ingresos. En ese camino, la primera meta es que el desarrollador
llegue lo antes posible a una implementación básica de la API.
 Características que debe tener una API
Debe ser útil y fácil de aprender

• La API es un instrumento, no una meta en sí misma: es preferible

utilizar formatos conocidos y habituales como JSON que inventar
la rueda. O seguir los pasos más racionales a la hora de
desarrollar una API REST o SOAP.
• Dar soporte para la corrección de errores: los desarrolladores
pueden informar de fallos y posibles mejoras en una API si se
genera un espacio para feedback. Así se puede perfeccionar la
API y, al mismo tiempo, generar comunidad.
 Características que debe tener una API
Estable frente a las mejoras

• Si no es estable, es un problema para un desarrollador es una API

que cambia continuamente. Las mejoras están bien, pero a veces
se corre el riesgo de que vayan en contra de la propia estabilidad
del servicio. Sobre todo si no existe la posibilidad de mantener sin
cambios las versiones previas de la propia API.
• Eso provocó que en 2011, la interfaz de desarrollo de aplicaciones
de Facebook fuera calificada como la peor API del mercado para
la comunidad de desarrolladores. Una de las razones: los cambios
continuos en la herramienta sin previo aviso.
 Características que debe tener una API
Estable frente a las mejoras

• Para evitar esos problemas, puede considerarse como una buena práctica
en la mayoría de ocasiones el uso de un control de versiones en la API.
• Normalmente mediante la creación de distintas URLs por cada proceso de
incorporación de nuevas características y su impacto en las aplicaciones de
terceros. Eso genera también un listado de versiones con fecha y
novedades en cada caso. Sucede, por ejemplo, con servicios como
Microsoft Azure y Amazon Web Services.
• En la misma línea ha trabajado Facebook desde 2011, introduciendo un
sistema de control de versiones más razonable para la comunidad de
desarrolladores.
 Características que debe tener una API
Estable frente a las mejoras

• En ese procedimiento, cada desarrollador sabe de antemano que

habrá cambios en la API cada dos años, con fechas ya publicadas:
la versión 2.3 se publicó el 25 de marzo de 2015 y está prevista
su expiración en agosto de 2017. El cuadro siguiente es un
ejemplo de cómo es el proceso de versiones de las APIs y los
SDKs dentro de Facebook
 Características que debe tener una API
Segura

• El tema de la seguridad siempre es complejo. Hay que analizar el

papel que juegan los protocolos OAuth y OAuth2 en la necesidad de
desarrollar APIs seguras en su uso por terceros. Los procesos de
autenticación deben ofrecer las máximas garantías sin dificultar en
exceso el acceso al servicio por parte de otras compañías.
• OAuth 2 es un protocolo relativamente sencillo de implementar con
bibliotecas en numerosos lenguajes de programación: PHP, Java,
Python, Scala, Objective C, Swift, Ruby, JavaScript, Node.js o .NET.
 Características que debe tener una API
Segura

• Es cuestión de entrar y escoger la que se desee. Lo que permite

el protocolo OAuth 2 basado en la asignación de tokens de
acceso seguro para la identificación de cada usuario es evitar
ataques CSRF (Cross-Site Request Forger)
• Falsificación de petición en sitios cruzados), un tipo de
vulneración cada vez más frecuente basado en el uso de cookies
para la identificación de usuarios. Añadir temporalidad a los
tokens de acceso añade aún más solidez.
 Características que debe tener una API
Segura

• Las APIs que basan su seguridad en un protocolo de token de

acceso lo que hacen es identificar a cada cliente que hace una
petición HTTP mediante ese token que, previamente, ha sido
almacenado en el lado del cliente (navegador) con JavaScript. En
este artículo de Carlos Azaustre se explica a la perfección el
proceso de token.
 Características que debe tener una API
Ofrecer una buena documentación

• Cuando se desarrolla una aplicación, el público objetivo es el

usuario medio. El uso del producto debe ser claro, sencillo,
intuitivo…
• Cuando se diseña una API, el público objetivo es un programador,
un profesional con conocimientos técnicos. Aunque eso es así, la
calidad de la interfaz final no solo depende del producto,
también de la documentación que explica cómo hacer un mejor
uso de él. Aunque ese usuario final tenga conocimientos
técnicos, una buena documentación es clave.
 Características que debe tener una API
Ofrecer una buena documentación

• Una de las APIs mejor valoradas hoy en día es la de Stripe, una

pasarela de pagos online que compite en el mercado con PayPal o
Braintree, por poner dos ejemplos. La razón fundamental por la que
Stripe tiene una gran acogida entre la comunidad de desarrolladores
es su interfaz de desarrollo de aplicaciones. Y uno de sus puntos
fuertes es la documentación, que se basa en dos pilares esenciales:
• Cada método de la API se documenta en varios idiomas y se utiliza un lenguaje
sencillo, claro, sin excesiva jerga técnica. Es totalmente accesible.
• No solo contiene información sobre especificaciones de la API, sino también
tutoriales prácticos bien documentados sobre cómo afrontar cada trabajo.
 Diseño del API

• El término diseño de API hace referencia al proceso de desarrollo de 

interfaces de programación de aplicaciones (API) que expone las
funcionalidades de las aplicaciones y los datos para que las utilicen los
usuarios y los desarrolladores.
• Las API son importantes para las empresas modernas, ya que
permiten incorporar capacidades nuevas que abarcan desde las
operaciones y los productos hasta las estrategias de asociación. No es
exagerado decir que la mayoría de las empresas ya no preguntan si es
conveniente contratar programas de API, sino cómo hacerlo.
 Diseño del API

• Cada API está diseñada en un lenguaje de programación concreto y

con unas especificaciones distintas que la definen. Las APIs pueden
incluir especificaciones para estructuras de datos y rutinas, clases de
objetos o variables, a partir de las cuales se basa el uso de esa
interfaz.
• Además, suele ser habitual que cada una de ellas disponga de
documentación completa y eficaz (un conjunto de tutoriales,
manuales y reglas de buenas prácticas para esa interfaz de
programación).
 Diseño del API

• Un programa de API eficaz debe basarse en la estrategia corporativa

general de una empresa y contribuir a sus objetivos. Sabrá que tiene
los elementos que se necesitan para una gran estrategia cuando
pueda responder las siguientes tres preguntas de forma clara:
1. ¿Por qué queremos implementar las API?
2. ¿Cuáles son los resultados concretos a los que queremos llegar con estas
API?
3. ¿Cómo pensamos ejecutar el programa de API para lograrlo?
 Diseño del API
El motivo

• Por lo general, las personas no suelen interpretar esta pregunta de

manera correcta. En primer lugar, en vez de centrarse en el valor de la
API, es útil considerar el valor de su efecto.
• No olvide que lo valioso es el negocio principal de la empresa, no
necesariamente la API. Una API es valiosa cuando se convierte en un
medio para proporcionar tipos nuevos de acceso al valor actual que
ofrece una empresa.
• Otra idea errónea común es creer que una API solo tiene valor si los
usuarios están dispuestos a pagar por ella. Esto es cierto solo en los
casos en que la API es un producto en sí.
 Diseño del API
El motivo

• Sin embargo, este no es el caso en la mayoría de los modelos. Por lo

general, las API impulsan alguna otra métrica, como las ventas, la
derivación de afiliados, el conocimiento de la marca, etc.
• El valor de la API para los usuarios es el resultado de la llamada a la
API (la solicitud del servicio y su respuesta), en lugar de la llamada en
sí.
 Diseño del API
El motivo

• Según una encuesta de Cutter Consortium y Wipro a 152 empresas, los

objetivos comerciales más comunes que impulsan la adopción de
programas de API son desarrollar asociaciones nuevas, aumentar los
ingresos, aprovechar los modelos comerciales nuevos, mejorar el
tiempo de comercialización y desarrollar canales nuevos de
distribución.
• Los principales objetivos tecnológicos son mejorar la integración de las
aplicaciones y la integración móvil, y admitir la conexión a más
dispositivos. Los beneficios empresariales deben ser lo suficientemente
importantes para que la decisión de invertir en las API sea obvia para la
empresa.
 Diseño del API
El objetivo

• La segunda pregunta debe ser "¿cuáles son los resultados concretos a

los que queremos llegar con estas API?". Es decir, "¿qué hacen las API
realmente y cómo influyen en la estrategia comercial general?”
• Tanto el concepto de enfoque interno como el de enfoque externo de
una empresa permiten definir el objetivo de la API. El enfoque interno
hace referencia a los recursos específicos y valiosos de una empresa.
Cuanto más valiosos y exclusivos sean los servicios y los recursos que
ofrece, más conveniente será la adopción de un programa de API.
 Diseño del API
El objetivo

• Una empresa que posee datos únicos puede aprovechar este recurso
permitiendo el acceso a él a través de una API. Gracias al contenido,
los datos y los servicios únicos, el acceso a la API puede ser
sumamente valioso.
• A la hora de decidir qué deben hacer las API por una empresa,
es preciso analizar los dos enfoques. Por lo tanto, la decisión acerca
del objetivo suele ser una combinación de ambos.
 Diseño del API
El objetivo

• En definitiva, si bien es poco probable que el motivo cambie con

frecuencia, el objetivo puede variar de forma significativa en función
de los factores externos, como el mercado, las consideraciones
técnicas o las condiciones económicas. La orientación interna sobre el
valor de un recurso puede cambiar, lo que también podría influir en lo
que debería lograrse con una API.
 Diseño del API
El método

• La última pregunta, "¿cómo diseñar el programa de API para alcanzar

nuestros objetivos?", se trata de la implementación y la ejecución.
• Los equipos deben preguntarse lo siguiente:
• ¿Qué tecnología se utiliza para diseñar las API?
• ¿Cómo se diseñan las API?
• ¿Cómo se mantienen?
• ¿Cómo se promocionan dentro de la empresa o cómo se comercializan al mundo
exterior?
• ¿Cuáles son los recursos disponibles?
• ¿Quiénes deberían formar parte del equipo?
• ¿Cómo realizamos un seguimiento del éxito en relación con los objetivos comerciales
que se han establecido?
Como funciona un API
Uso de una API
Uso de APIs
 Tipos de APIs

• SOAP (Simple Object Access Protocol) Es un

protocolo estándar que define cómo dos
objetos, en diferentes procesos, pueden
comunicarse por medio de intercambio de
datos XML.
• REST (Transferencia de Estado
Representacional) Es una forma sencilla de
enviar y recibir datos entre el cliente y el
servidor y que no dispone de muchos
estándares. Puede enviar y recibir datos
como JSON, XML o incluso texto sin
formato.
 API REST qué es y cuáles son sus ventajas en la construcción de proyectos

• REST cambió por completo la ingeniería de software a partir del 2000.

• Este nuevo enfoque de desarrollo o contsrucción de proyectos y
servicios web fue definido por Roy Fielding, el padre de la
especificación HTTP y uno los referentes internacionales en todo lo
relacionado con la Arquitectura de Redes, en su disertación
‘Architectural Styles and the Design of Network- based Software
Architectures’.
• En el campo de las APIs, REST (Representational State Transfer-
Transferencia de Estado Representacional) es, a día de hoy, el alfa y
omega del desarrollo de servicios de aplicaciones.
 API REST qué es y cuáles son sus ventajas en la construccion de proyectos

• En la actualidad no existe proyecto o aplicación que no disponga de una

API REST para la creación de servicios profesionales a partir de ese
software. Twitter, YouTube, los sistemas de identificación con Facebook…
hay cientos de empresas que generan negocio gracias a REST y las APIs
REST.
• Sin ellas, todo el crecimiento en horizontal sería prácticamente imposible.
Esto es así porque REST es el estándar más lógico, eficiente y habitual en
la creación de APIs para servicios de Internet.
• Buscando una definición sencilla, REST es cualquier interfaz entre
sistemas que use HTTPs para obtener datos o generar operaciones sobre
esos datos en todos los formatos posibles, como XML y JSON.
 API REST qué es y cuáles son sus ventajas en la construccion de proyectos

• Es una alternativa en auge a otros protocolos estándar de

intercambio de datos como SOAP (Simple Object Access
Protocol), que disponen de una gran capacidad pero también
mucha complejidad. A veces es preferible una solución más
sencilla de manipulación de datos como REST.
 Características de REST

• Protocolo cliente/servidor sin estado: cada petición HTTP contiene toda

la información necesaria para ejecutarla, lo que permite que ni cliente
ni servidor necesiten recordar ningún estado previo para satisfacerla.
Aunque esto es así, algunas aplicaciones HTTP incorporan memoria
caché.
• Se configura lo que se conoce como protocolo cliente-caché-servidor sin
estado: existe la posibilidad de definir algunas respuestas a peticiones
HTTP concretas como cacheables, con el objetivo de que el cliente
pueda ejecutar en un futuro la misma respuesta para peticiones
idénticas. De todas formas, que exista la posibilidad no significa que sea
lo más recomendable.
 Características de REST

• Las operaciones más importantes relacionadas con los datos en

cualquier sistema REST y la especificación HTTP son cuatro: POST
(crear), GET (leer y consultar), PUT (editar) y DELETE (eliminar).
• Los objetos en REST siempre se manipulan a partir de la URI. Es
la URI y ningún otro elemento el identificador único de cada
recurso de ese sistema REST. La URI nos facilita acceder a la
información para su modificación o borrado, o, por ejemplo, para
compartir su ubicación exacta con terceros.
 Características de REST

• Interfaz uniforme: para la transferencia de datos en un sistema

REST, este aplica acciones concretas (POST, GET, PUT y DELETE)
sobre los recursos, siempre y cuando estén identificados con una
URI. Esto facilita la existencia de una interfaz uniforme que
sistematiza el proceso con la información.
• Sistema de capas: arquitectura jerárquica entre los
componentes. Cada una de estas capas lleva a cabo una
funcionalidad dentro del sistema REST.
 Características de REST

• Uso de hipermedios: hipermedia es un término acuñado por Ted

Nelson en 1965 y que es una extensión del concepto de
hipertexto. Ese concepto llevado al desarrollo de páginas web es
lo que permite que el usuario pueda navegar por el conjunto de
objetos a través de enlaces HTML.
• En el caso de una API REST, el concepto de hipermedia explica la
capacidad de una interfaz de desarrollo de aplicaciones de
proporcionar al cliente y al usuario los enlaces adecuados para
ejecutar acciones concretas sobre los datos.
 Ventajas de REST

1. Separación entre el cliente y el servidor: Mejora la portabilidad de

la interfaz a otro tipo de plataformas, aumenta la escalabilidad de
los proyectos y permite que los distintos componentes se puedan
evolucionar de forma independiente.
2. Visibilidad, fiabilidad y escalabilidad: Esta separación facilita tener
en servidores distintos el front y el back y eso convierte a las
aplicaciones en productos más flexibles a la hora de trabajar
3. La API REST siempre es independiente del tipo de plataformas o
lenguajes: Este tipo de API se adapta al tipo de sintaxis o
plataformas con las que se estén trabajando, lo que ofrece una gran
libertad a la hora de cambiar o probar nuevos entornos dentro del
desarrollo.
 Herramientas para desarrollar APIs

• Para programar una API desde cero existen plataformas, herramientas

y también lenguajes que permiten a los equipos de desarrolladores
diseñar, desarrollar, probar y documentar sus propias APIs para
facilitar la programación de productos a terceros y generar ingresos.
• A día de hoy existen varios referentes importantes: Restlet Studio,
Swagger, API Blueprint, RAML, Mockable.io, Loader.io, BlazeMeter,
Apiary e InstantAPI. Existen más herramientas, pero estas son las más
conocidas entre las comunidades de desarrolladores. A continuación
se realiza un análisis de las características de algunas de ellas.
 Parametrización y clases genéricas

• Los genéricos son tipos parametrizados compatibles con Common

Language Runtime. Un tipo parametrizado es un tipo que se define
con un parámetro de tipo desconocido que se especifica cuando se
usa el tipo genérico.
¿Por qué usar genéricos?
• C++ admite plantillas y tanto estas como los genéricos admiten tipos
parametrizados para crear clases de colección con tipo. Sin embargo,
las plantillas proporcionan parametrización en tiempo de
compilación. 
• No se puede hacer referencia a un ensamblado que contenga una
definición de plantilla y crear especializaciones de la plantilla. 
 Parametrización y clases genéricas

¿Por qué usar genéricos?

• Una vez compilada, una plantilla especializada se parece a cualquier
otra clase o método. En cambio, los genéricos se emiten en MSIL
como un tipo parametrizado que se sabe que lo es en tiempo de
ejecución; el código de origen que hace referencia a un ensamblado
que contiene un tipo genérico puede crear especializaciones del tipo
genérico. 
 Parametrización y clases genéricas
Funciones y tipos genéricos

• Las funciones miembro de clase estática e instancia y las funciones

delegadas y globales también pueden ser genéricas. Las funciones
genéricas pueden ser necesarias si los parámetros de la función son
de un tipo desconocido, o si la propia función debe funcionar con
tipos genéricos.
• En muchos casos donde System::Object se puede haber usado en el
pasado como parámetro para un tipo de objeto desconocido, se
puede usar en su lugar un parámetro de tipo genérico, lo que permite
más código de seguridad de tipos. 
 Parametrización y clases genéricas
Funciones y tipos genéricos

• Las mismas ventajas se aplican a las clases de colección basadas en

genéricos. En el pasado, las clases de colección
usaban System::Object para almacenar elementos de una
colección. La inserción de objetos de un tipo para el que la colección
no estaba diseñada no se marcaba en tiempo de compilación y, con
frecuencia, ni siquiera cuando se insertaban los objetos. 
• Normalmente, un objeto se convertía en algún otro tipo cuando se
accedía a él en la colección. Solo si la conversión producía error, se
detectaba el tipo inesperado. Los genéricos resuelven este problema
en tiempo de compilación al detectar cualquier código que inserta un
tipo que no coincide con (o se convierten implícitamente en) el
parámetro de tipo de la colección genérica.
 Parametrización y clases genéricas
Terminología usada con los genéricos

• Parámetros de tipo
• Una declaración genérica contiene uno o varios tipos desconocidos conocidos
como parámetros de tipo. A los parámetros de tipo se les asigna un nombre
que representa el tipo dentro del cuerpo de la declaración genérica. El
parámetro de tipo se utiliza como tipo dentro del cuerpo de la declaración
genérica. La declaración genérica de List<T> contiene el parámetro de tipo T.
• Argumentos de tipo
• El argumento de tipo es el tipo real utilizado en lugar del parámetro de tipo
cuando el genérico se especializa para uno o varios tipos específicos. Por
ejemplo, int es el argumento de tipo en List<int> . Los tipos de valor y los
tipos de manipulador son los únicos tipos que se permiten como argumento
de tipo genérico.
 Parametrización y clases genéricas
Terminología usada con los genéricos

• Tipo construido
• Un tipo construido a partir de un tipo genérico se conoce como tipo
construido. Un tipo no especificado completamente, como List<T> es un tipo
construido abierto; un tipo completamente especificado,
como List<double>, es un tipo construido cerrado o un tipo especializado. 
• Los tipos construidos abiertos pueden usarse en la definición de otros
métodos o tipos genéricos y no se pueden especificar completamente hasta
que no se especifica el propio genérico envolvente. 
 Parametrización y clases genéricas
Terminología usada con los genéricos

• Tipo construido
• Por ejemplo, este es un uso de un tipo construido abierto como clase base
para un genérico:
 Parametrización y clases genéricas
Clases genéricas

• Las clases genéricas encapsulan operaciones que no son específicas

de un tipo de datos determinado. El uso más común de las clases
genéricas es con colecciones como listas vinculadas, tablas hash, pilas,
colas y árboles, entre otros. 
• Las operaciones como la adición y eliminación de elementos de la
colección se realizan básicamente de la misma manera
independientemente del tipo de datos que se almacenan.
 Parametrización y clases genéricas
Clases genéricas

• Al crear sus propias clases genéricas, entre las consideraciones

importantes se incluyen las siguientes:
• Los tipos que se van a generalizar en parámetros de tipo.
• Como norma, cuantos más tipos pueda parametrizar, más flexible y reutilizable será su
código. En cambio, demasiada generalización puede crear código que sea difícil de leer o
entender para otros desarrolladores.
• Las restricciones, si existen, que se van a aplicar a los parámetros de tipo
• Una buena norma es aplicar el máximo número de restricciones posible que todavía le
permitan tratar los tipos que debe controlar. Por ejemplo, si sabe que su clase genérica
está diseñada para usarse solo con tipos de referencia, aplique la restricción de
clase. Esto evitará el uso no previsto de su clase con tipos de valor, y le permitirá usar el
operador as en T, y comprobar si hay valores NULL.
 Parametrización y clases genéricas
Clases genéricas

• Al crear sus propias clases genéricas, entre las consideraciones

importantes se incluyen las siguientes:
• Si separar el comportamiento genérico en clases base y subclases.
• Como las clases genéricas pueden servir como clases base, las mismas consideraciones
de diseño se aplican aquí con clases no genéricas. Vea las reglas sobre cómo heredar de
clases base genéricas posteriormente en este tema.
• Si implementar una o más interfaces genéricas.
• Por ejemplo, si está diseñando una clase que se usará para crear elementos en una
colección basada en genéricos, puede que tenga que implementar una interfaz como 
IComparable<T> donde T es el tipo de su clase.
Parametrización y clases genéricas
Clases genéricas
 Aserciones

• Es posible establecer aserciones más fuertes que otras. Ahora bien

¿qué significa que una aserción es más fuerte que otra? Se puede
definir, que dadas dos aserciones P y Q, P es más fuerte o igual que Q
si P implica Q. El concepto de fortificar o debilitar aserciones es usado
en la herencia cuando es necesario redefinir rutinas.
• En Eiffel (y en general en las herramientas disponibles para otros
lenguajes) el lenguaje para soportar aserciones tiene algunas
diferencias con el cálculo de predicados: no tiene cuantificadores
(aunque el concepto de agentes provee un mecanismo para
especificarlos) , soporta llamadas a funciones y además existe la
palabra reservada old (usada en las poscondiciones) para indicar el
valor anterior a la ejecución de la rutina de algún elemento.
 Programación defensiva VS Diseño por contrato

• El diseño y la programación por contratos es en cierto sentido

opuesto a lo que se denomina programación defensiva (Meyer,1992).
Si bien existen diversas acepciones para el concepto de programación
defensiva, se tomará aquí la idea por la cual la programación
defensiva incita a los programadores a realizar todas las verificaciones
posibles en sus rutinas de tal forma de prevenir que una llamada
pueda producir errores.
• Básicamente la idea de programación defensiva no apunta a que los
elementos de software garanticen especificaciones bien conocidas
sino que sean textos ejecutables en condiciones arbitrarias.
 Programación defensiva VS Diseño por contrato

• Supóngase una clase que representa una cuenta bancaria que cuenta
con una rutina depositar que recibe un importe como parámetro y
agrega ese importe al saldo:
 Programación defensiva VS Diseño por contrato

• La solución del Diseño por Contratos, basado en el principio de no

redundancia, implica que se debe especificar claramente bajo que
condiciones debe llamarse a la rutina (mediante las precondiciones) y
a partir de ello se establece cual es el resultado (las poscondiciones).
Las precondiciones deben ser parte de la interfaz de la rutina. Para el
ejemplo anterior:
 Manejo de errores, manejo de excepciones y tolerancia a los fallos

• En un programa podemos encontrarnos con distintos tipos de errores

pero a grandes rasgos podemos decir que todos los errores
pertenecen a una de las siguientes categorías.
• Errores de sintaxis
• Errores semánticos
• Errores de ejecución
 Manejo de errores, manejo de excepciones y tolerancia a los fallos

• Errores de sintaxis: estos errores son seguramente los más simples de

resolver, pues son detectados por el intérprete (o por el compilador,
según el tipo de lenguaje que estemos utilizando) al procesar el
código fuente y generalmente son consecuencia de equivocaciones al
escribir el programa. En el caso de Python estos errores son indicados
con un mensaje SyntaxError. Por ejemplo, si trabajando con Python
intentamos definir una función y en lugar de def escribimos dev.
 Manejo de errores, manejo de excepciones y tolerancia a los fallos

• Errores semánticos: se dan cuando un programa, a pesar de no

generar mensajes de error, no produce el resultado esperado. Esto
puede deberse, por ejemplo, a un algoritmo incorrecto o a la omisión
de una sentencia.
 Manejo de errores, manejo de excepciones y tolerancia a los fallos

• Errores de ejecución: tos errores aparecen durante la ejecución del

programa y su origen puede ser diverso. En ocasiones pueden
producirse por un uso incorrecto del programa por parte del usuario,
por ejemplo si el usuario ingresa una cadena cuando se espera un
número.
• En otras ocasiones pueden deberse a errores de programación, por
ejemplo si una función intenta acceder a la quinta posición de una
lista de 3 elementos o realizar una división por cero. Una causa
común de errores de ejecución que generalmente excede al
programador y al usuario, son los recursos externos al programa, por
ejemplo si el programa intenta leer un archivo y el mismo se
encuentra dañado.
 Manejo de excepciones

• Para el manejo de excepciones los lenguajes proveen ciertas palabras

reservadas, que nos permiten manejar las excepciones que puedan
surgir y tomar acciones de recuperación para evitar la interrupción del
programa o, al menos, para realizar algunas acciones adicionales
antes de interrumpir el programa.
• En el caso de Python, el manejo de excepciones se hace mediante los
bloques que utilizan las sentencias try, except y finally.
 Manejo de excepciones

• Dentro del bloque try se ubica todo el código que pueda llegar

a levantar una excepción, se utiliza el término levantar para referirse a
la acción de generar una excepción.
• A continuación se ubica el bloque except, que se encarga de capturar
la excepción y nos da la oportunidad de procesarla mostrando por
ejemplo un mensaje adecuado al usuario. Veamos qué sucede si se
quiere realizar una división por cero:
 Manejo de excepciones

• En este caso, se levantó la excepción ZeroDivisionError cuando se

quiso hacer la división. Para evitar que se levante la excepción y se
detenga la ejecución del programa, se utiliza el bloque try-except.

• No se permite la división por cero

 Tolerancia a los fallos

• El nivel de tolerancia a fallos lo podemos describir con este esquema:

• Tolerancia total: el sistema continua funcionando después de un fallo por un
tiempo limitado, en este tiempo no se afecta ni la funcionalidad ni el
rendimiento del sistema.
• Caída suave: el sistema sigue funcionando después de un fallo pero con
aspectos de funcionalidad deteriorados
• Fallo seguro: se establece una parada segura que no produce efectos en la
tolerancia respecto a otros componentes del sistema
 Tolerancia a los fallos

• Las técnicas de tolerancia a fallos se basan en la adición al sistema de

elementos que permiten la recuperación, estos elementos se llaman
redundantes en el sentido de que su uso no es necesario en caso del
funcionamiento normal del sistema.
• Respecto al hardware existen dos estrategias de tolerancia a fallos:
• Estática (enmascaramiento): módulos redundantes hardware que realizan la
misma función, el sistema debe comparar los diferentes resultados para ser
capaz de desechar los resultados incorrectos.
• Dinámica, la redundancia se produce dentro del propio componente, el
mismo componente informa del error en la salida.
 Tolerancia a los fallos

• También podemos hablar de tolerancia a fallos en el software:

• Estático, Programación N-versiones, se trata de introducir diferentes
componentes software que sean capaces de producir cálculos
alternativos de la misma función y proporcionar resultados a
comparar para asegurar que están libres de errores.
• Los programas son ejecutados por un programa director que los
ejecuta concurrentemente y serán comparados por el mismo. Los
resultados (votos) deben ser idénticos, si alguno es diferente este
resultado será considerado como erróneo.
 Tolerancia a los fallos

• El éxito de la programación de N-versiones depende de:

• Correcta especificación inicial: la especificación del diseño provocará que los
diferentes componentes software funcionen de forma correcta.
• Independiencia en el diseño: es importante que se utilicen diferentes
personas y herramientas para la implementación de los diferentes
componentes.
• Presupuesto adecuado para desarrollar las tres versiones
 Tolerancia a los fallos

• Redundancia dinámica
• El error es informado por el propio módulo, que debe detectarlo. La
detección puede ser por el entorno o por la apliación.
• El módulo debe ser capaz de confinar el error y valorar sus daños. El
confinamiento consiste en establecer cortafuegos que delimiten el alcance
del efecto de los errores. Se pueden realizar por:
• Descomposición modular: delimita la difusión del error en el módulo.
• Acciones atómica: en caso de error devuelve el sistema a un estado de consistencia
 Tolerancia a los fallos

• Redundancia dinámica
• Recuperación de errores, hay que tratar de volver al estado de operación
normal o de degradación en la funcionalidad. Existen dos tipos de
recuperación:
• Recuperación hacia adelante, se continua con la ejecución del sistema haciendo
correcciones selectivas de su estado
• Recuperación de errores hacia atrás, en caso de error el sistema se restaura a un estado
seguro previo y se ejecuta desde ese punto - checkpoint
 Tolerancia a los fallos

• Bloques de recuperación
• Se trata de bloques normales de programación con un punto de recuperación
al principio y un test de aceptación al final que comprueba que el sistema se
encuentra en un estado aceptable al finalizar la ejecución del bloque.
• Si existe un fallo se restaura el estado de ejecución al inicio del bloque
continuando con un procedimiento alternativo. Si todas las alternativas
presentan error el bloque mostrará un estado de error.
• Es el test de aceptación el que se encarga de la detección de el error lo que
puede suponer una sobrecarga. Por eso se introduce cierto margen de
tolerancia para la aceptación.
Gracias por su atención