Resumen Pressman

Capitulo 1 El software y la ingeniería de Software

LA NATURALEZA DEL SOFTWARE

El software tiene un papel dual. Es un producto y al mismo tiempo es el vehiculo para entregar
un producto. Brinda el potencil de computo incorporado en el hardware de computo o en una
red de computadoras a las que se accede por medio de un hardware local.

Como vehiculo utilizado para distribuir el producto, el software actua como la base para el
control de la computadora (Sistemas operativos), para la comunicación de información y para
la creación y control de otros programas

El software distribuye el producto mas importante: información

DEFINICION DE SOFTWARE

El software es un elemento de un sistema lógico y no de uno físico, por tanto, tiene

características que difieren considerablemente de las del hardware

- El software se desarrolla o modifica con intelecto; no se manufactura en el sentido

clásico.
- El software no se desgasta
- Aunque la industria se mueve hacia la construcción basada en componentes, la mayor
parte del software se construye para un uso individualizado

DOMINIOS DE APLICACIÓN DEL SOFTWARE

Categorías de software

- Software de sistemas: Conjunto de programas escritos para dar servicio a otros

programas
- Software de aplicación: Programas aislados que resuelven una necesidad especifica de
negocios.
- Software de ingeniería y ciencias: Se ha caracterizado por algoritmos devoradores de
números
- Software incrustado: reside dentro de un producto o sistema y se usa para
implementar y controlar características y funciones para el usuario final y para el
sistema en si.
- Software de línea de productos: es diseñado para proporcionar una capacidad
especifica para uso de muchos consumidores diferentes
- Aplicaciones web: software centrado en redes agrupa una amplia gama de
aplicaciones.
- Software de inteligencia artificial: hace uso de algoritmos no numéricos para resolver
problemas complejos que no son fáciles de tratar computacionalmente o con el
análisis directo.

SOFTWARE HEREDADO

Miles de programas de computo caen en uno de los siete dominios amplios de aplicación de la
subsección anterior. Algunos de ellos son software muy nuevo, pero otros son mas viejos, en
ciertos casos muy viejos. Estos programas antiguos- denominados software heredado- han
sido centro de atención y preocupación desde hace décadas.

El software heredado se caracteriza por su longevidad e importancia critica para el negocio.

Hay otra característica presente en este software: mala calidad. La única respuesta razonable
es: hacer nada, al menos hasta que el sistema heredado tenga un cambio significativo. Si el
software heredado satisface las necesidades de sus usuarios y corre de manera confiable, no
necesita repararse.

LA NATURALEZA UNICA DE LAS WEBAPPS

La gran mayoría de las wabapps presenta los siguientes atributos.

 Uso intensivo de redes: residen enuna red y deben atender a las necesidades de una
comunidad divesa de clientes
 Concurrencia: puede acceder a un gran numero de usuarios a la vez
 Carga impredecible: el numero de usuarios de la webapp cambia en varios ordenes de
magnitud de un dia a otro
 Rendimiento: si un usuario de la webapp debe esperar demasiado, el o ella quizá
decidan irse a otra parte
 Disponibilidad: los usuarios de las webapps demandan acceso las 24 horas de los 365
dias del año
 Orientadas a los datos: la función principal es el uso de hipermedios para presentar al
usuario final contenido en forma de texto, graficos, audio y video.
 Contenido sensible: la calidad y naturaleza del contenido constituye un rasgo
importante
 Evolución continua
 Inmediatez
 Seguridad
 Estética

INGENIERIA DE SOFTWARE

- Debe hacerse un esfuerzo concertado para entender el problema antes de desarrollar

una aplicación de software
- El diseño es una actividad crucial
- El software debe tener alta calidad
- El software debe tener facibilidad para recibir mantenimiento.

La ingeniería de software es una tecnología con varias capas. El fundamento para la ingeniería
de software es la capa proceso. El proceso de la ingeniería de software es el aglutinante que
une las capas de la tecnología y permite el desarrollo racional y oportuno del software de
computo. El proceso define una estructura que debe establecerse para la obtención eficaz de
la tecnología de la ingeniería de software
Los métodos de la ingeniera de software proporcionan la experiencia de la técnica para
elaborar software. Incluyen un conjunto amplio de tareas, como comunicación, análisis,
modelación del diseño, construcción del programa, pruebas y apoyo.

Las herramientas proporcionan un apoyo automatizado o semiautomatizado para el proceso y

los métodos.

EL PROCESO DEL SOFTWARE

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a

crearse algún producto del trabajo. Una actividad busca lograr un objetivo amplio y se
desarrolla sin importar el dominio de la aplicación, tamaño del proyecto, complejidad. Una
acción es un conjunto de tareas que producen un producto importante del trabajo, una tarea
se centra en un objetivo pequeño pero bien definido que produce un resultado tangible.ç

La estructura del proceso incluye actividades sombrilla que son aplicables a través de todo el
proceso de software. Una estructura de proceso general para la ingeniería de software consta
de 5 actividades:

1. Comunicación
2. Planeacion
3. Modelado
4. Construcción
5. Despliegue

Las actividades estructurales del proceso de ingeniería de software son complementadas por
cierto numero de actividades sombrilla. Las actividades sombrilla se aplican a lo largo del
proyecto y ayudan al equipo que lo lleva a cabo a administrar y controlar el avance, la calidad,
el cambio y el riesgo. Es común que las actividades sombrillas sean las siguientes

1. Seguimiento y control del proyecto de software

2. Administración del riesgo
3. Aseguramiento de la calidad del software
4. Revisiones técnicas
5. Medición
6. Administración de la configuración
7. Administración de la reutilización
8. Preparación y producción del producto de trabajo

LA PRACTICA DE LA INGENIERA DE SOFTWARE

La esencia de la pratica

1. Entender el problema (comunicación y análisis)

2. Planear la solución (modelado y diseño del software)
3. Ejecutar el plan (generación del código)
4. Examinar la exactitud del resultado (probar y asegurar la calidad)

PRINCIPIOS GENERALES

David hooker propuso siete principios que se centran en la practica de la ingeniería de

software como un todo

1er principio: La razón de que exista todo

Un sistema de software existe por una razón: Dar valor a sus usuarios. Todas las decisiones
deben tomarse teniendo esto en mente.
2do principio: MSE (mantenlo sencillo, estúpido..)
Todo diseño debe ser tan simple como sea posible. Pero no mas.
3er principio: Mantener la visión
Una visión clara es esencial para el éxito de un proyecto de software
4to principio: Otros consumiran lo que usted produce.
Nunca se construye un sistema en el vacio
5to principio: Abrase al futuro
Un sistema con larga vida útil tiene mas valor.
6to principio: planee por anticipado la reutilización
La reutilización ahorra tiempo y esfuerzo
7mo principio: Piense!
Pensar en todo con claridad antes de emprender la acción casi siempre produce mejores
resultados

MITOS DEL SOFTWARE

Mitos de Gestión: los gestores con responsabilidad sobre el software, como los gestores en
la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestas,
hacer que no se retrase el proyecto y mejorar la calidad.

 Mito. libros que contienen estándares y procedimientos para construir software. ¿pero
proporciona la suficiente información que se necesita saber?
 Realidad. los libros contienen demasiada información, el problema es si este se usa, si se
conocen las prácticas modernas de desarrollo de software, si está diseñado para mejorar el
tiempo de entrega mientras se mantiene un enfoque de calidad.

Mitos del Cliente: un cliente que solicita una aplicación de software, en muchos casos cree
en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del
software hacen muy poco para corregir la mala información. los mitos conducen a que el
cliente se cree una falsa expectativa y finalmente, quede insatisfecho.

 Mito. una declaración general de los objetivos es suficiente para comenzar a escribir los
programas, dar detalles.
 Realidad. una mala definición inicial es la principal causa del trabajo perdido en el software.
Es esencial una descripción detallada y formal del ámbito de la información, funciones,
comportamiento, rendimiento, interfaces, etc.
 Mitos de los Desarrolladores: los mitos de los desarrolladores se han fomentado durante 50
años de cultura informática. la programación de veía como un arte. las viejas formas y
actitudes tardan en morir.

 Mito. una vez terminado el programa y lo hago funcionar, mi trabajo a terminado.

 Realidad. cuanto más pronto se comience a escribir el código mas se tarda en terminar. Todo
el esfuerzo dedicado en un programa se inicia después que se le ha entregado al cliente por
primera vez.

Capitulo 2 Modelos del proceso

Una actividad estructural esta formada por un conjunto de acciones de ingeniería de software y
cada una de estas se encuentra por un conjunto de tareas que identifica las tareas del trabajo
que deben realizarse, los productos del trabajo que se producirán, los puntos de aseguramiento
de la calidad que se requieren y los puntos de referencia que se utilizaran para evaluar el avance.

Flujo del proceso: manera en que están organizadas las actividades estructurales y las acciones
y tareas que ocurren dentro de cada una con respecto de la secuencia y el tiempo.

Un flujo de proceso lineal ejecuta cada una de las cinco actividades en secuencia, comenzando
por la comunicación y terminan con el despliegue.

Un flujo de proceso iterativo repite una o mas de las actividades antes de pasar a la siguiente.
Un flujo de proceso evolutivo realiza las actividades en forma circular .

Un flujo de proceso paralelo ejecuta una o mas actividades en paralelo con otras.

DEFINICION DE ACTIVIDAD ESTRUCTURAL

1. Hacer contacto con el participante por via telefónica

2. Analizar los requerimientos y tomar notas
3. Organizar las notas por escrito en una formulación breve de los requerimientos
4. Enviar correo electrónico al participante para que revise y apruebe

PATRONES DEL PROCESO

Un patrón del proceso describe un problema relacionado con el proceso que se encuentra
durante el trabajo de ingeniería de software, identifica al ambiente en el que surge el problema
y sugiere una o mas soluciones para el mismo. Al combinar patrones, un equipo de software
resuelve problemas y construye el proceso que mejor satisfaga las necesidades de un proyecto.

Los patrones se definen en cualquier nivel de abstracción. En ciertos casos, un patrón puede
usarse para describir un problema y su solución.

Se describe con el

Nombre de patrón: nombre significativo que lo describe

Fuerzas: el ambiente en el que se encuentra el patron

Tipo:

- Patrón de etapa: define a un problema asociado con una actividad estructural para el
proceso
- Patrón de tarea: define un problema asociado con una acción o tarea de trabajo de la
ingeniería de software.
- Patrón de fase: define la secuencia de las actividades estructurales que ocurren dentro
del proceso.

Contexto inicial: condiciones en las que se aplica el patrón

Problema

Solución

Contexto resultante: condicientes que resultaran a la vez que se haya implementado el

patrón

Patrones relacionados: lista de patrones directamente relacionados con este.

Usos y ejemplos conocidos: instancias especificas en las que es aplicable el patrón

MODELOS DE PROCESO PRESCRIPTIVO

Los modelos prescriptivos de software fueron ideados originalmente para ordenar el caos
del desarrollo de software, y la historia nos muestro que el uso de estos han tradio tanto un
camino a seguir en el desarrollo de software asi como estructuras utiles. aun que el trabajo
de ingenieria de software y el producto resultante siguen estando en un punto entre el
orden y el caos lo cual indica que no se esta en la estructura completa y que puede haber
 cierta dosis de creatividad en el desarrollo de software y no se esta en la desorganizacion
total de manera que puede seguirse un camino predecible para el proyecto.

Los modelos prescriptivos de software nos definen un conjunto de tareas actividades,

productos de trabajo que se requieren para desarrollar productos de calidad que son
importantes para llevar control, estabilidad y organizacion a una actividad que tiende a ser
caotica, el modelo prescriptivo llena el marco de trabajo con conjuntos de tareas explicitas
para las acciones de la ingenieria de software. Se debe considerar que aun que un proceso
sea prescriptivo esto no se debe asumir como estatico, estos se deben adaptar al personal,
al proyecto y al problema.

Los modelos son llamados prescriptivos ya que prescriven una serie de elementos de
proceso asi como su flujo de trabajo, cada uno de modelos se ajustan al marco de trabjo
estandar pero cada uno aplica diferencias a cada una de las actividades y a su flujo de
trabajo.

EL MODELO CASCADA O CICLO CLASICO

Existen ocaciones en las cual es los requisitos de un sistemas se identifican de manera

razonable y estos fluyen de la comunicacion al despliegue de manera casi lineal. Esto se da
cuando se debe hacer adaptaciones o mejorias a un sistema existente por ejemplo al
agruegar nuevas regulaciones gubernamentales a un programa existente, puede utilizarse
tambien en proyectos nuevos pero unicamente cuando los requisitos estan bien definidos y
son estables en forma razonable.

Las actividades seguidas por este son las siguientes

El modelo cascada es el paradigma mas antiguo en la ingenieria de software pero al utilizar

este paradigma se han observado lo siguiente.

1. Es muy raro que los problemas reales sigan el flujo lineal secuencial propuesto.
2. Es muy dificil para el cliente establecer todos los requisitos de manera explicita el modelo
cascada lo requiere y enfrenta problemas al proponer cambios.
3. El cliente debe tener paciencia.

MODELOS DE PROCESOS INCREMENTALES

En muchas ocaciones encontramos proyectos con requisitos bien definidos razonables pero la
propia naturaleza del proyecto nos impide usar un enfoque puramente lineal, por ejemplo se
necesita tener un conjunto limitado de funcionalidad para luego refinarla y expandirla y esto nos
conduce a modelo incremental el cual combina elementos del modelo en cascada en forma
iterativa.El modelo incremental entrega una serie de lanzamientos llamados incrementos que
proporcionan en forma progresiva mas funcionalidad para los clientes a medida que se entrega
cada uno de los incrementos.

Al utilizar el modelo incremental la primer entrega es un producto esencial que incluye los
requisitos basicos, los detalles tanto conocidos como no conocidos pueden incluirse en
lanzamientos posteriores, esta primera entrega puede ser evaluado por el cliente para incluir
nueva funcionalidad. Este proceso debe ser repetitivo hasta no tener un producto final.
El modelo incremental al igual que el modelo de prototipos es por naturaleza iterativo la gran
diferencia entre ambos es que se debe hacer una entrega funcional en el caso del modelo
incremental.Si el cliente propone una fecha de entrega imposible es conveniente sugerir la
entrega de uno o mas incrementos para dicha fecha de modo que se pueda tener un producto
parcial basico a las necesidades del cliente para ese momento y entregar el resto de incrementos
adicionales luego.

MODELO DRA (DESARROLLO RAPIDO DE APLICACIONES)

es un modelo incremental que hace enfasis en un ciclo de vida corto. y puede verse como una
version a alta velocidad del modelo en cascada en el cual se logra un desarrollo rapido mediante
un efoque basado en componentes. En el cual deberiamos tener un sistema completamente
funcional en un periodo de 60 a 90 dias

DRA tiene los siguientes incomvenientes

1. para proyectos grandes pero escalables DRA necesita sufiente recurso humano para crear el
numero correcto de equipos.

2. si tanto cliente como programador no se compromenten en las actividades rapidas necesarias

para completar el sistema en un marco breve de tiempo los proyectos DRA fracasaran.

3.Si un sistema no se puede modular en forma apropiada para la construccion de componentes

separados sera un gran problema.

4. Si el alto rendimiento es un aspecto importante y se alcanzara al convertir interfaces en

componentes.

5. Inaprpiado con riesgos tecnicos altos.

MODELOS EVOLUTIVOS

Los modelos evolutivos producen una version completa en forma incremental en cada iteracion.
y permiten crear versiones mas completas del software en cada iteracion. y son utilies cuando
se tienen requisitos basicos establecidos pero se deben definir detalles sobre la extencion del
producto o sitema.

CONSTRUCCION DE PROTOTIPOS

El cliente describe un conjunto de de objetivos generales del software pero no identifica los
requisitos detallados de entrada, salida o procesamiento y el desarrollador esta inseguro de la
efectividad del software.

si el cliente tiene un necesidad real del software pero no sepa definir los detalles o el mismo no
sepa bien que es lo que quiere es importante como primer paso desarrollar un prototipo. y
puede mezclarse con cualquier otro metodo.

EL MODELO ESPIRAL

El modelo espiral es un proceso de software evolutivo que conjuga la naturaleza iterativa de la

construccion de prototipos con los aspectos controlados y sistematicos del modelo cascada.
Cuando se aplica el modelo espiral se desarrolla una serie de entregas evolutivas iniciando desde
posiblemente documentacion y prototipos, hasta llegar versiones cada ves mejores del sistema.

el desarrollo espiral es un enfoque realista para el de sarrollo de sistemas a gran escala.entre los
problemas de este modelo podemos ver que es dificil convencer al cliente que el enfoque
evolutivo es controlable, si un riesgo importante no se descubre y administra surgiran
problemas.

MODELO DE DESARRROLLO CONCURRENTE

El modelo de procesos concurrentes define una serie de eventos que se disparan transiciones
de estado a estado para cada una de las actividades, acciones, o tareas de ingenieria de
software.

Se aplica a todos los tipos de desarrollo de software y proporciona una vision exacta del estado
del proyecto es apropiado cuando se encuentran involucrados varios equipos de ingenieria.

DESARROLLO BASADO EN COMPONENTES

Incorpora muchas de las caracteristicas del modelo espiral es evolutivo por naturaleza. el
modelo configura aplicaciones a partir de software empaquetado en forma previa.el modelado
y construccion inician por identificar los componentes candidatos estos pueden ser diseñados
como modulos de software convencionales o como clases o paquetes de clases orientados a
objetos.

MODELO DE METODOS FORMALES

Comprende un conjunto de actividades que conducen a la especificacion matematica del

software de computadora y proporcionan un mecanismo para eliminar problemas dificiles a
traves de un analisis matematico.

el problema principal es el tiempo y los recursos que consume son grandes, no hay gente
suficiente capacitada para aplicar estos metodos y es muy dificil comunicarse con el cliente por
medio de las notaciones especificas.

DESARROLLO DE SOFTWARE ORIENTADO A ASPECTOS

Es un paradigma de ingenieria de software que proporciona un proceso y enfoque metodologico

para definir, especificar, diseñar y construir aspectos. mecanismos mas alla de subrutinas y
legados para localizar la expresion del interes general es posible que el proceso adopte
caracteristicas del proceso espiral y concurrente .

EL PROCESO UNIFICADO

El proceso unificado es el intentod e reunir las mejores caracteristicas de los distintosp

paradigmas de ingenieria de software y se complementa muchos de los mejores principios del
desarrollo agil, hace enfasis en la arquitectura y ayuda a los arquitectos a enfocarse en las metas
correctas

PU abarca la comunicacion y actividades de planeacion, se identifican los requisitos del software

y se propone una arquitectura aproximada del sistema y se desarrolla un plan para la naturaleza
iteretiva incremental que sigue.
los productos que se generan son

visión general de proyecto

modelo de casos de uso
modelo de análisis de PU
modelo de diseño
modelo de implementación

UNIDAD 5 PATRONES DE DISEÑO

Los patrones de diseño son unas técnicas para resolver problemas comunes en el desarrollo
de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución
sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es
que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en
distintas circunstancias.

PATRONES DE CREACION

Facilitan el proceso de creación del sistema

- Abstracción del proceso de instanciación.

- Sistema independiente de las creaciones de objetos.
- Encapsulación del comportamiento de las clases.
- Ocultan cómo las clases se “comunican” entre sí.

Singleton

patrón diseñado para limitar la creación de objetos pertenecientes a una clase. El objetivo de
este patrón es el de garantizar que una clase solo tenga una instancia (o ejemplar) y
proporcionar un punto de acceso global a ella. Esta patrón; por ejemplo, suele ser utilizado
para las conexiones a bases de datos.

Abstract Factory

El patrón Abstract Factory nos permite crear, mediante una interfaz, conjuntos o familias de
objetos (denominados productos) que dependen mutuamuente y todo esto sin especificar cual
es el objeto concreto.

Este patrón se puede aplicar cuando:

Un sistema debe ser independiente de como sus objetos son creados.

Un sistema debe ser 'configurado' con una cierta familia de productos.

Se necesita reforzar la noción de dependencia mutua entre ciertos objetos.

Factory method

Define la interfaz de creación de un cierto tipo de objeto, permitiendo que las subclases
decidan que clase concreta necesitan instancias.

Muchas veces ocurre que una clase no puede anticipar el tipo de objetos que debe crear, ya
que la jerarquía de clases que tiene requiere que deba delegar la responsabilidad a una
subclase.

Este patrón debe ser utilizado cuando:

Una clase no puede anticipar el tipo de objeto que debe crear y quiere que sus subclases
especifiquen dichos objetos.

Hay clases que delegan responsabilidades en una o varias subclases. Una aplicación es grande
y compleja y posee muchos patrones creacionales.

Diagrama UML.
Creator: declara el método de fabricación (creación), que devuelve un objeto de tipo Product.
ConcretCreator: redefine el método de fabricación para devolver un producto.
ProductoConcreto: es el resultado final. El creador se apoya en sus subclases para definir el
método de fabricación que devuelve el objeto apropiado

PATRONES ESTRUCTURALES

Estos patrones de diseño tratan sobre la composición de clases y objetos. Estos patrones usan
herencia para componer interfaces. Definen maneras de componer un objeto para obtener
nuevas funcionalidades.

Adapter

Convertir la interfaz de una clase en otra interfaz esperada por los clientes. Permite que clases
con interfaces incompatibles se comuniquen

Ventajas:

Se quiere utilizar una clase ya existente y su interfaz no se corresponde con la interfaz que se
necesita.

Se quiere envolver código no orientado a objeto con forma de clase

Composite

Componer objetos en jerarquías todo-parte y permitir a los clientes tratar objetos simples y
compuestos de manera uniforme

Ventajas:

¨Permite tratamiento uniforme de objetos simples y complejos así como composiciones

recursivas ¨Simplifica el código de los clientes, que sólo usan una interfaz ¨Facilita añadir
nuevos componentes sin afectar a los clientes

Inconvenientes:

Es difícil restringir los tipos de los hijos ¨Las operaciones de gestión de hijos en los objetos
simples pueden presentar problemas: seguridad frente a flexibilidad

Decorator

Atribuye responsabilidades adicionales a un objeto de forma dinámica. Decorador provee una

alternativa flexible de subclases para extender su funcionalidad
PATRONES DE COMPORTAMIENTO
Se definen como patrones de diseño software que ofrecen soluciones respecto a la
interacción y responsabilidades entre clases y objetos, así como los algoritmos que
encapsulan:

Interpreter

define una representación para su gramática junto con un intérprete del lenguaje.
Se usa para definir un lenguaje para representar expresiones regulares que representen
cadenas a buscar dentro de otras cadenas. Además, en general, para definir un lenguaje que
permita representar las distintas instancias de una familia de problemas.

Este patrón se debe utilizar cuando hay un lenguaje que interpretar y se puede interpretar sus
palabras como árboles sintácticos abstractos. Para ello, la gramática debe ser simple.
Difícilmente el desarrollador utilice este patrón en algún momento de su vida, lo que no quita
que no sea un patrón utilizado. La situación ideal que se debe considerar para aplicar este
patrón es que exista un lenguaje sencillo que pueda interpretarse con palabras. El ejemplo más
claro es JAVA: este lenguaje permite escribir en archivos .java entendibles por humanos y
luego este archivo es compilado e interpretado para que pueda ejecutar sentencias
entendibles por una máquina.
Iterator

Provee un mecanismo estándar para acceder secuencialmente a los elementos de una

colección; define una interface que declara métodos para acceder secuencialmente a los
objetos de una colección. Una clase accede a una colección a través de dicha interface.

La motivación de este patrón reside en la gran diversidad de colecciones y algoritmos que

existe hoy en día para recorrer una colección. Lo que se busca es acceder a los contenidos de
los objetos incluidos sin exponer su estructura.

Podemos decir que este patrón nace para poder soportar diversas formas de recorrer objetos
y para ofrecer una interfaz uniforme para recorrer distintos tipos de estructuras de agregación.

Se utiliza cuando:

Una clase necesita acceder al contenido de una colección sin llegar a ser dependiente de la
clase que es utilizada para implementar la colección, es decir sin tener que exponer su
representación interna.

Una clase necesita un modo uniforme de acceder al contenido de varias colecciones.

Cuando se necesita soportar múltiples recorridos de una colección.

Agregado/Aggregate: define una interfaz para crear un objeto iterator.

Iterator: define la interfaz para acceder y recorrer los elementos de un agregado.

IteradorConcreto: implementa la interfaz del iterador y guarda la posición actual del recorrido
en cada momento.

AgregadoConcreto: implementa la interfaz de creación de iteradores devolviendo una

instancia del iterador concreto apropiado.

Cliente: solicita recorrer una colección y lo hace siguiendo los métodos otorgados por la
interfaz Iterator.

Memento

Este patrón de diseño permite capturar y exportar el estado interno de un objeto para que
luego se pueda restaurar, sin romper la encapsulación.

Su finalidad es almacenar el estado de un objeto (o del sistema completo) en un momento

dado, de manera que se pueda restaurar posteriormente si fuese necesario. Para ello se
mantiene almacenado el estado del objeto para un instante de tiempo en una clase
independiente de aquella a la que pertenece el objeto (pero sin romper la encapsulación), de
forma que ese recuerdo permita que el objeto sea modificado y pueda volver a su estado
anterior.

Hoy en día, muchos aplicativos permiten el "deshacer" y "rehacer" de manera muy sencilla.
Para ciertos aplicativos es casi una obligación tener estas funciones y sería impensado el hecho
que no las posean. Sin embargo, cuando queremos llevar esto a código puede resultar
complejo de implementar. Este patrón intenta mostrar una solución a este problema.

Se usa cuando:

Se necesite restaurar el sistema desde estados pasados.

Se quiera facilitar el hacer y deshacer de determinadas operaciones, para lo que habrá que
guardar los estados anteriores de los objetos sobre los que se opere (o bien recordar los
cambios de forma incremental).

Caretaker: es responsable por mantener a salvo a Memento. No opera o examina su

contenido.

Memento: almacena el estado interno de un objeto Originator. El Memento puede almacenar

todo o parte del estado.Originator: crea un objeto Memento conteniendo una fotografía de su
estado interno.
Observer

Este patrón de diseño permite reaccionar a ciertas clases llamadas observadores sobre un
evento determinado.

Es usado en programación para monitorear el estado de un objeto en un programa. Está

relacionado con el principio de invocación implícita. La motivación principal de este patrón es
su utilización como un sistema de detección de eventos en tiempo de ejecución. Es una
característica muy interesante en términos del desarrollo de aplicaciones en tiempo real.

Debe ser utilizado cuando:

Un objeto necesita notificar a otros objetos cuando cambia su estado. La idea es encapsular
estos aspectos en objetos diferentes permite variarlos y reutilizarlos independientemente.

Cuando existe una relación de dependencia de uno a muchos que puede requerir que un
objeto notifique a múltiples objetos que dependen de él cuando cambia su estado.

Este patrón tiene un uso muy concreto: varios objetos necesitan ser notificados de un evento y
cada uno de ellos deciden como reaccionar cuando esta evento se produzca.

Subject: conoce a sus observadores y ofrece la posibilidad de añadir y eliminar observadores.

Posee un método llamado attach() y otro detach() que sirven para agregar o remover
observadores en tiempo de ejecución.

Observer: define la interfaz que sirve para notificar a los observadores los cambios realizados
en el Subject.

SubjectConcreto: almacena el estado que es objeto de interés de los observadores y envía un

mensaje a sus observadores cuando su estado cambia.

ObserverConcreto: mantiene una referencia a un SubjectConcreto. Almacena el estado del

Subject que le resulta de interés. Implementa la interfaz de actualización de Observer para
mantener la consistencia entre los dos estados.