• Categories
• Objeto (Ciencias de la Computación)
• Ingeniería de software
• Software
• Lenguaje de programación
• Informática

Citation preview

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. 2. 3. 4. 5.

Comunicación Planeacion Modelado Construcción 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. 2. 3. 4. 5. 6. 7. 8.

Seguimiento y control del proyecto de software Administración del riesgo Aseguramiento de la calidad del software Revisiones técnicas Medición Administración de la configuración Administración de la reutilización Preparación y producción del producto de trabajo

LA PRACTICA DE LA INGENIERA DE SOFTWARE

La esencia de la pratica 1. 2. 3. 4.

Entender el problema (comunicación y análisis) Planear la solución (modelado y diseño del software) Ejecutar el plan (generación del código) 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. 2. 3. 4.

Hacer contacto con el participante por via telefónica Analizar los requerimientos y tomar notas Organizar las notas por escrito en una formulación breve de los requerimientos 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.