Ingeniería de

Software
Orientado a
Objetos
Segundo parcial

Ing. Jorge Luis Charco Aguirre

Patrones de diseño
 El diseño OO es difícil y el diseño de software
orientado a objetos reutilizable lo es aún más.

 Los diseñadores expertos no resuelven los

problemas desde sus principios; reutilizan
soluciones que han funcionado en el pasado.

 Estos patrones resuelven problemas de diseño

específicos y hacen el diseño flexible y
reusable.
Patrones de diseño
 Un patrón de diseño es una descripción
de clases y objetos comunicándose entre
sí adaptada para resolver un problema
de diseño general en un contexto
particular.

 Eluso de patrones ayuda a obtener un

software de calidad (reutilización y
extensibilidad
Elementos de un Patrón

 Nombre: describe el problema de diseño.

 Elproblema: describe cuándo aplicar el

patrón.

 La solución: describe los elementos que

componen el diseño, sus relaciones,
responsabilidades y colaboración
Clasificación de los
Patrones
 Según su propósito:
– De creación: conciernen al proceso de
creación de objetos.

– De estructura: tratan la composición de clases

y/o objetos.

– De comportamiento: caracterizan las formas

en las que interactúan y reparten
responsabilidades las distintas clases u objetos.
Clasificación de los
Patrones
Patrón Singleton
 Utilidad
 Asegurar que una clase tiene una sola instancia
y proporcionar un punto de acceso global a
ella.

 Ventajas
 Es necesario cuando hay clases que tienen que
gestionar de manera centralizada un recurso.

 Una variable global no garantiza que sólo se

instancie una vez
Aplicación - Singleton
 Aplicación
 Cuando sólo puede haber una instancia
de una clase, y debe ser accesible a los
clientes desde un punto de acceso bien
conocido .

 Cuando el único ejemplar pudiera ser

extensible por herencia, y los clientes
deberían usar el ejemplar de una subclase
sin modificar su código
Aplicación – Singleton
(Solución)
 El constructor de la clase DEBE SER
PRIVADO

 Se proporciona un método ESTÁTICO en

la clase que devuelve

 LA ÚNICA INSTANCIA DE LA CLASE: por

ejemplo: getInstance()
Aplicación - Singleton
Ejemplo - Singleton
Se podrá acceder desde cualquier clase
utilizado un método estático.

Suele utilizarse para almacenar información

global que ha de ser accedida desde
varios objetos o para controlar un recurso
físico único, como una impresora
Ejemplo – Enviar log a la
consola
 Sepuede usar en una sesión de usuario
donde solo exista una única sesión de
usuario en el sistema.

 Enun log donde permita enviar mensajes

a la consola.
Ejemplo - Singleton
public class CSingleton {
private static CSingleton logger;
private CSingleton() { }

public static CSingleton getInstance() {

if (logger == null){
logger = new CSingleton();
}
return laInstancia;
}

public void log(String msg){

System.out.println(msg);
}
}
Ejemplo - Singleton
public static void main(String[] args)
{
CSingleton logger_1 = CSingleton.getInstance();
logger_1.log(“Esto es un singleton”)
}

Por ejemplo: Usado para solucionar problemas donde se

tenga que usar variables globales. No es la única solución.

Puede ser usado en sistemas grandes de tal forma que

solo exista una instancia de cada sistema.
Patrón Observador
 Intención
Definir una dependencia uno a muchos entre
objetos, de tal forma que cuando el objeto
cambie de estado, todos sus objetos
dependientes sean notificados automáticamente.
 Motivación
– En un toolkit de GUI, separar los objetos de
presentación (vistas) de los objetos de datos, de
forma que se puedan tener varias vistas
sincronizadas de los mismos datos (editor-
subscriptor)
Patrón Observador
 Por ejemplo:

Tenemos un objeto que representa una hoja de cálculo y

otro que representa un diagrama de barras, éstos pueden
representar información en la misma aplicación usando
diferentes presentaciones. La hoja de cálculo y el
diagrama de barras no se conocen, pero cuando el
usuario cambia un dato en la hoja de cálculo, se cambia
automáticamente en el diagrama de barras y viceversa.
Patrón Observador
Patrón Observador
 Ámbito de Aplicación
 Cuando una abstracción tiene dos puntos de vista
dependientes uno del otro. Encapsular estos puntos
de vista en objetos separados permite cambiarlos y
reutilizarlos.

 Cuando un cambio en un objeto requiere cambiar

otros y no sabemos cuántos objetos van a cambiar.

 Cuando un objeto debería poder notificar a otros sin

saber cuales son esos otros.
Patrón Observador
 Beneficios
 Acoplamiento abstracto entre el sujeto y el observador: El
sujeto no conoce la clase concreta de cada observador,
los conoce a través de la interfaz. Por tanto el
acoplamiento es abstracto y mínimo.

 Soporte para la comunicación: La notificación se envía

automáticamente a todos los observadores. Al sujeto no le
importa cuántos observadores existan, su única
responsabilidad es notificarlos. Esto da libertad de añadir o
eliminar observadores cuando queramos.
Patrón Observador
 Problemas

 Actualizaciones inesperadas: Debido a que los

observadores no conocen a otros observadores,
pueden no conocer el coste de cambiar de sujeto.
Una operación aparentemente inofensiva en el
sujeto puede resultar en una cascada de
actualizaciones en los observadores
Patrón Observador
Ejemplo – Implementación de
las Interfaces
public interface SujetoObservador
{ /*Avisa que está pisando el acelerador y hay que
arrancar el motor*/
public void notificar();
}

public interface Observador

{ /*Actualiza cuando el sujeto lo notifique o dispare un
evento*/
public void update();
}
Ejemplo – Implementación de
las clases
public class Motor implements Observador{
public Motor(){}

@Override
public void update() {
/*Acción a realizar después de que se entera que el
acelerador esta siendo presionado*/
System.out.println("Subir la potencia, velocidad, revoluciones, etc");
}
}
Ejemplo – Implementación de
las clases
public class Acelerador implements SujetoObservador{

private ArrayList<Observador> observadores;

/* Inicializo el arraylist en el constructor*/
public Acelerador(){
observadores = new ArrayList<Observador>();
}
public void pisarAcelerador(){
//Se tiene que notificar que se ha pisado el acelerador y tiene que
//subir la potencia del motor
notificar();
}
Ejemplo – Implementación de
las clases
/*Se tiene que enlazar los observadores con el sujeto (acelerador)*/
public void enlazarObservadores(Observador o){
observadores.add(o);
}

@Override
public void notificar() {
for (Observador o: observadores){
o.update();
}
}
}
Ejemplo – Main
public static void main(String[] args) {
Motor v8 = new Motor();
Acelerador A1 = new Acelerador();

A1.enlazarObservadores(v8);
A1.pisarAcelerador();
}

Ejercicio:
Agregar dos observadores diferentes de tal forma que el
Sujeto (Acelerador) notifique a todos los observadores las
actualizaciones y se presente las distintas acciones
(mensajes) de cada observador
Pruebas de
Sistema
Orientado a
Objetos
Pruebas.
 Laspruebas son el proceso de análisis de
un sistema, o componente de un sistema,
para detectar las diferencias entre el
comportamiento especificado
(requerido) y el observado (existente).
Pruebas.
 Las pruebas no son determinantes

 Es necesario realizar las pruebas bajo

restricciones de tiempo y presupuesto.

 Los sistemas se entregan sin estar

probados por completo, lo que conduce
a defectos que son descubiertos por los
usuarios finales
Caso real.
 El primer lanzamiento del transbordador espacial
Columbia en 1981, por ejemplo canceló a causa
de un problema que no se detectó durante el
desarrollo. Se encontró que el problema fue
provocado por un cambio hecho dos años antes
por un programador, quien, por error, cambió un
factor de retraso de 50 a 80 milisegundos
Un panorama de las pruebas.-
Confiabilidad
 La confiabilidad es una medida del éxito con
que el comportamiento de un sistema se
apega a la especificación de su
comportamiento.

 La confiabilidad del software es la

probabilidad de que un sistema de software
no causará la falla del sistema durante un
tiempo especificado bajo condiciones
especificadas
Técnicas de control de
calidad
 Haymuchas técnicas para incrementar la
confiabilidad de un sistema de software.

 Seenfoca en tres clases de técnicas para

evitar los defectos, detectarlos y
tolerarlos.
Técnicas para evitar defectos
Técnicas para evitar defectos
 Tratade impedir la ocurrencia de errores
y fallas encontrando defectos en el
sistema antes de lanzarlo. Las técnicas
para evitar defectos incluyen:

 Desarrollo de metodologías
 Administración de la configuración
 Técnicas de verificación
 Revisiones
Técnicas para evitar defectos
 El desarrollo de metodologías:

Incluyen la representación sin

ambigüedades de los requerimientos, el
uso de abstracción y encapsulamiento de
los datos, la definición temprana de las
interfaces de subsistemas
Técnicas para evitar defectos
 La administración de la configuración:

Evita los defectos causados por cambios sin

disciplina en los modelos del sistema. Por
ejemplo, es un error común cambiar una
interfaz de subsistema sin notificarlo a todos
los desarrolladores de los componentes
que lo llaman
Técnicas para evitar defectos
 La verificación:

Trata de encontrar defectos antes de

cualquier ejecución del Sistema. la
verificación tiene sus límites. No está en un
estado lo bastante maduro como para que
pueda aplicarse para asegurar la calidad
de grandes sistemas complejos.
Técnicas para evitar defectos
 Revisión:

Es la inspección manual de algunos o todos los

aspectos del sistema sin ejecutar. Se revisa que
los algoritmos sean eficientes con respecto a los
requerimientos no funcionales.

Por último, revisa los comentarios acerca del

código para encontrar comentários imprecisos
e incompletos.
Técnicas para la detección de
defectos
 Ayudan a encontrar defectos en los sistemas
pero no tratan de recuperar las fallas que
causan. Se aplican durante el desarrollo,
pero en algunos casos también se usan
después del lanzamiento del sistema.

 Distinguimos dos tipos de técnicas para la

detección de defectos:
 La depuración
 Las pruebas.
Técnicas para la detección de
defectos
 Ladepuración:
Asume que los defectos pueden
encontrarse iniciando a partir de una falla
no planeada.

Una vez que Se ha identificado este estado

es necesario determinar el defecto que lo
causa.
Técnicas para la detección de
defectos
 La prueba:

Es una técnica de detección de defectos

que trata de crear fallas o errores en forma
planeada. Esto permite que el desarrollador
detecte fallas en el sistema antes de que
sea lanzado al cliente.
Técnicas para Ia tolerancia de
defectos
 La tolerancia de defectos es la
recuperación de una falla mientras el
sistema está ejecutando.

 Los sistemas de bases de datos

proporcionan transacciones atómicas
para recuperarse de una falla durante
una secuencia de acciones que
necesitan hacerse todas o ninguna.
Técnicas para Ia tolerancia de
defectos
 El tratamiento de las técnicas de
tolerancia de defectos es importante
para los sistemas muy confiables.

 Por ejemplo.- El sistema puede continuar

aunque falle un componente, debido a
que los demás componentes todavía
están realizando la funcionalidad
requerida
Actividades de
las Pruebas
Motivaciones de las Pruebas
Unitarias
Actividades de las Pruebas
 Encuentran defectos aislando un
componente individual y ejercitando al
componente usando un caso de prueba.

 La prueba unitaria se enfoca en los

bloques de construcción del sistema de
software; esto es, los objetos y
subsistemas.
Motivaciones de las Pruebas
Unitarias
 Reduce la complejidad de las
actividades de prueba generales.

 Facilita
resaltar y corregir defectos, ya
que están involucrados pocos
componentes

 Permiteel paralelismo en las actividades

de prueba.
Técnicas para las pruebas
unitarias.
 Prueba de equivalencia

 Prueba de frontera

 Prueba de ruta

 Prueba basada en estado.

Pruebas de Rutas
 La de ruta es una técnica de prueba de
caja blanca que identifica fallas en la
implementación del componente.

 El punto inicial para la prueba de ruta es

el diagrama de flujo. Un diagrama de
flujo consiste en nodos que representan
bloques ejecutables y asociaciones que
representan el flujo de control.
Prueba de ruta básica
Razones para automatizar
pruebas
 Ciclo de prueba manual es muy largo
 Proceso de prueba manual es propenso a
errores
 Liberar a la gente para realizar tareas
creativas
 Obtener realimentación de forma temprana.
 Generar documentación del código
consistente
 Generar una mejor utilización de los recursos
a partir de menores costos
Obstáculos para automatizar
las pruebas
 Actitud de los programadores

 Inversión inicial

 Código que siempre cambia

 Sistemas legacy

 Temor
Trabajo con Test
Manual
Trabajo con Test
Automático
Pruebas de Caja Blanca
 También conocidas como pruebas de
caja de cristal o pruebas estructurales, se
centran en los detalles de procedimientos
del software, por lo que su diseño está
fuertemente ligado al código fuente. Se
trabaja con entradas, salidas y el
conocimiento interno.
Pruebas de Caja Blanca
Técnicas conocidas de Caja
Blanca
 Cobertura.- Verifica que todos los
caminos lógicos de la aplicación son
alcanzables teóricamente en función de
los diferentes valores de entradas de los
parámetros.
Técnicas conocidas de Caja
Blanca
 Mutation Testin.- Se basa principalmente
en realizar ligeras modificaciones en el
programa que darían lugar a un
comportamiento anómalo del mismo
(resultados distintos). Sirve para verificar si
la estrategia de testing utilizada es capaz
de detectar estos cambios.
Técnicas conocidas de Caja
Blanca
 Análisis estático de código.- Tiene como
objetivo principal evaluar (directa o
indirectamente) el grado de
mantenibilidad del sistema. Es decir, un
sistema escalable y que pueda ser
modificado a un coste razonable.
Ejercicio # 1
* Dibujar el grafo
correspondiente

* Calcular complejidad
ciclomática

* Realizar las pruebas

correspondientes
Ejercicio # 2
Ejercicio # 3