Patrones De Analisis Y Diseño 5qci

Instituto Tecnológico de Chilpancingo Sistemas y Computación Ingeniería en Sistemas Computacionales

PATRONES DE ANALISIS Y DISEÑO

MATERIA: Fundamentos de Desarrollo de Sistemas

PROFESOR.: Maria Zavala Hurtado

ALUMNOS: Ángel Bello Guzmán

09520393

Marco Antonio Tolentino Alarcon

09520383

Chilpancingo, Gro., Abril del 2013

Resumen El objetivo de este documento es transmitir conocimientos acerca de la construcción de un modelo que permita elaborar el diseño del software de un sistema en base al negocio donde funcionará dicho sistema. Se muestra una forma de trabajo que reune la información generada por los modelos de Casos de Uso y de Dominio, la cual genera como resultado un modelo de Análisis rico en conocimiento del negocio y con la estructura necesaria para constituirse en el inicio del diseño posterior.

2

Contenido Resumen.......................................................................................................................................... 2 Patrones de Analisis ........................................................................................................................ 4 LOS PATRONES EN ORIENTACION A OBJETOS ............................................................... 6 Los Patrones en el Proceso de Desarrollo de Software ............................................................... 7 Algunas Consideraciones Sobre los Patrones de Análisis .......................................................... 9 Catálogos ................................................................................................................................... 10 Patrón de diseño ............................................................................................................................ 12 Breve reseña histórica ............................................................................................................... 12 Objetivos de los patrones .......................................................................................................... 13 Categorías de patrones .............................................................................................................. 14 Estructuras o plantillas de patrones ........................................................................................... 15 Relación de principales patrones GoF (Gang Of Four) ................................................................ 16 Patrones creacionales ................................................................................................................ 16 Patrones estructurales ................................................................................................................ 17 Patrones de comportamiento ..................................................................................................... 18 Patrones de interacción.............................................................................................................. 19 Aplicación en ámbitos concretos............................................................................................... 20

3

Patrones de Analisis El software tiene un papel cada vez mas preponderante en el mundo moderno, por lo tanto toman relevancia los objetivos de reducción de tiempos y costos e incremento de la calidad en su proceso de desarrollo. Según Jacobson [Jacobson, 1997], para lograr los objetivos planteados en la construcción de software se pueden identificar dos formas: que el software se produzca mas eficientemente o que grandes porciones del mismo sean reusadas. Para la primera forma se ha avanzado en las generaciones de lenguajes y se han incluido herramientas en la realización de muchas actividades, pero esto no ha conducido a una mejora record de tipo universal. Por lo tanto, para la mayoría de las organizaciones que intentan mejorar la performance en el desarrollo de software, objetos y reuso de software deben transformarse en claves para la estrategia de su ingeniería de software. Ser exitoso con la ingeniería de software orientada a objetos en la industria requiere que el reuso de software a gran escala sea puesto en práctica. Una de las principales ventajas que incorpora el paradigma orientado a objetos en la ingeniería de software es facilitar el reuso a muchos niveles. Según Coad [Coad, 1995], se puede hacer reuso de dominio de un problema, de una clase, de una componente, de mecanismos (herencia, vistas) o de patrones. El reuso, al cumplir con los objetivos planteados, otorga, en consecuencia, mayor capacidad competitiva al grupo de desarrollo. Según Coad [Coad, 1995] la comprensión es uno de los prerrequisitos para el reuso ya que éste puede hacerse efectivo sólo si los desarrolladores pueden encontrar y entender algo que es usado exitosamente más de una vez. Según Champeaux [Champeaux, 1997], el reuso de un dominio específico no es algo trivial, encontrar el artefacto adecuado no es obvio y adaptar un artefacto o construirlo tiene su costo. Goldberg y Rubin 4

[Goldberg, 1995], hablan de estrategia de reuso y de modelos de proceso de reuso en una organización. Según Coad [Coad, 1995] los patrones son una plantilla de objetos que interactúan y que pueden ser usados una y otra vez por analogía y el propósito de las estrategias y de los patrones es reducir el tiempo al construir modelos de objetos. Según Beck [Beck, 1997], los patrones permiten el desarrollo de código con rapidez, con menor riesgo, fácil de mantener y reusar, se diseñan en general para cubrir necesidades a corto y largo plazo y se pueden incorporar al proceso existente. Forman una base flexible para producir variaciones sistemáticas en software. Cada patrón registra una solución a un problema recurrente, incluyendo cómo reconocer la presencia del problema y cómo generar la solución para adaptarse al contexto. Los patrones conducen naturalmente uno a otro formando un tipo de fábrica de decisiones que puede resolver problemas de gran escala. Según Martin y Odell [Martin, 1998], "La orientación a objetos es a menudo descripta en términos de estructura y comportamiento. La palabra estructura es una metáfora visual, espacial, que se refiere a una visión estática de cómo los objetos se proyectan en el espacio. La estructura puede especificar varias configuraciones de objetos, tales como empleados, documentos y diseños de ingeniería. En contraste, el comportamiento se refiere a cómo nuestro mundo cambia a través del tiempo. Por ejemplo, el comportamiento puede contratar un empleado o decirnos que el empleado ha alcanzado la edad de retiro. En resumen describe los procesos que consultan o modifican objetos". Según Jacobson [Jacobson, 1995], un modelo orientado a objetos de una compañía muestra las funciones de la misma en el mundo, qué, cuando y cómo lo hace. Enfatiza en la arquitectura pero también describe los distintos cursos de eventos que tienen lugar dentro de la compañía.

5

LOS PATRONES EN ORIENTACION A OBJETOS Los patrones han tomado relevancia recientemente en los desarrollos de software. Según Coad [Coad, 1992], un patrón orientado a objetos es una abstracción formada por un pequeño grupo de clases que resulta ser útil una y otra vez en el desarrollo orientado a objetos y en [Coad, 1995], como ya se vio en la introducción, los define como una plantilla de objetos que interactúan. Según Martin Fowler [Fowler, 1997], un patrón es una idea que ha sido útil en un contexto práctico y probablemente lo sea en otros. Es una solución práctica para un problema concreto. Si un patrón no soluciona exactamente una necesidad, debe ser posible adaptarlo. Habla de idea porque permite manejar el concepto mas ampliamente, como por ejemplo que pueda ser un grupo de objetos colaborando y de contexto práctico con el significado de que los patrones evolucionan de la experiencia práctica en proyectos reales. Como consecuencia considera que un patrón se descubre y no que se inventa. Coad [Coad, 1992], plantea que cuando se encuentra un patrón uno comienza a pensar en base a ese nuevo bloque de construcción, mas que basándose en sus partes. Esto induce a pensar que el nombre que se le da a un patrón adquiere gran importancia. Según Fowler [Fowler, 1997], dar nombres puede ser una de las actividades mas difíciles del modelado. Los patrones existentes que se pueden combinar ante un nuevo requerimiento se vuelven mas sutiles y extensibles [Hay, 1996]. Según Schmidt [Schmidt, 1996], "Cuando los patrones se combinan construyen un lenguaje que provee un proceso para la resolución ordenada de problemas de desarrollo de software. Los lenguajes de patrones no son lenguajes formales, sino mas bien una colección de 6

patrones interrelacionados, si bien ellos proveen un vocabulario para hablar sobre un problema particular".

Los Patrones en el Proceso de Desarrollo de Software En la bibliografía se puede observar patrones que cubren distintas actividades de desarrollo de software como análisis, diseño y codificación. Los patrones de análisis son sugerencias y no prescripciones. Constituyen un punto de partida y no un destino en sí mismos. Proporcionan una idea inicial en el trabajo de modelado para un nuevo dominio. Son importantes porque ayudan a comprender cómo la gente percibe el mundo. Es valioso basar un diseño de sistemas en ellos, e inclusive para cambiar la percepción, lo cual conduce a un proceso de reingeniería [Fowler,1997]. Se enuncian de la forma problema-solución. Los patrones de análisis reflejan la estructura conceptual del proceso de los negocios, más que de la implementación del software. Aunque en general se piensa que no existen marcadas diferencias entre análisis y diseño orientado a objetos, es en la fase de análisis cuando se trata de comprender los detalles concernientes al problema y se busca detrás de los requerimientos de la superficie para ir hacia un modelo mental de lo que se desea alcanzar o hacia donde se dirige el problema [Fowler, 1997]. De acuerdo con Parsons [Parsons, 1997] "El análisis involucra el modelado de un dominio. Es entonces fundamentalmente diferente al diseño de software, el cual es orientado a la implementación". Según Gamma [Gamma, 1995], los patrones de diseño describen soluciones simples y elegantes que resuelven problemas específicos de diseño. Captan soluciones que han sido desarrolladas y han evolucionado en el tiempo, es decir, que tienen cierto nivel de abstracción. Por consiguiente no son diseños que se tienden a generar inicialmente, reflejan el esfuerzo que los desarrolladores 7

han realizado para un mayor reuso y flexibilidad en su software. Son descripciones de clases y objetos que se comunican y que se personalizan para resolver un problema general en un contexto particular. Pueden ser implementados en lenguajes orientados a objetos estándares y, aunque demandan un poco mas de trabajo adicional, éste se compensa con las ventajas que aporta. En general poseen cuatro elementos esenciales: el nombre, el problema (la descripción de cuándo se aplica, es decir el problema y su contexto), la solución (describe los elementos que integran el diseño, sus relaciones y colaboraciones) y las consecuencias (resultados y consideraciones de aplicar el patrón y que, en general se refieren a compromiso de espacio y tiempo). Los presenta siguiendo las siguiente plantilla: -

Intención

-

Otro nombre por el que se lo conoce

-

Motivación

-

Aplicabilidad

-

Estructura

-

Colaboraciones

-

Consecuencias

-

Implementación

-

Ejemplo de codificación

-

Usos conocidos

-

Patrones relacionados

8

Coad en [Coad, 1995] presenta 31 patrones de diseño con la siguiente estructura: -

Interacciones típicas entre objetos

-

Ejemplos

-

Combinaciones

-

Notas (en algunos casos)

Beck [Beck, 1997], enuncia que los patrones en Smalltalk son útiles para acelerar el aprendizaje de la programación y proporcionan gran cantidad de material para discusión en la enseñanza para aplicar a una situación particular, cubren tácticas de programación diaria y se refieren mas al estilo de programación. Cada patrón presenta: -

Problema recurrente que se presenta en el quehacer diario

-

Consideraciones que afectan las soluciones del problema

-

Receta concreta para crear la solución del problema.

Algunas Consideraciones Sobre los Patrones de Análisis Las técnicas de análisis intentan ser independientes de la tecnología de software. Idealmente una técnica de modelado conceptual debería ser independiente de la tecnología de software pues esto logra evitar que la tecnología oculte la comprensión del problema y que el modelo resultante sea igualmente útil en cualquier tecnología de software [Fowler, 1997]. En análisis orientado a objetos se habla de tipo (y subtipo) y no de clase (y subclase), a pesar de estar trabajando con patrones orientados a objetos, pues en la etapa de análisis aun es prematuro determinar cuales serán las clases que finalmente intervendrán en el diseño; no obstante muchas de ellas podrán coincidir con los tipos del análisis. Según Martin y Odell [Martin, 1998], "Un tipo es un concepto (es una noción o una idea que nosotros aplicamos a los objetos en nuestra conciencia). Es un tipo de objeto". 9

Catálogos Schmidt [Schmidt, 1996] expresa que las disciplinas maduras de ingeniería disponen de manuales o guías que describen soluciones satisfactorias para encarar problemas planteados. Por ejemplo los diseñadores de automóviles no diseñan autos usando directamente las leyes de la física, en su lugar ellos reusan diseños estandarizados exitosos. En la ingeniería de software encontramos por ejemplo la obra de Gamma [Gamma, 1995], donde se encara un catálogo de patrones de diseño y en Beck [Beck, 1997], 92 patrones de Smalltalk.. Ward Cunningham manifiesta (en la sección Foreword del libro de Martin Fowler [Fowler, 1997]) que M. Fowler ha brindado su experiencia y ha realizado para los objetos del dominio lo que Gamma [Gamma, 1995] realizó para la implementación. Según Fowler [Fowler, 1997], "así como leer buen código enseña mucho acerca de programación, buenos modelos enseñan mucho sobre análisis y diseño". Los patrones son por definición buenos modelos. Los catálogos, al intensificar la evolución hacia un lenguaje común incrementan la comunicación, con lo cual incrementan la performance en el desarrollo de software. Según Beck [Beck, 1997], para el que dirige un proyecto de software los patrones indican cómo aplicar bien los principios de la ingeniería de software y pueden ser la base para un vocabulario común de los desarrolladores. En Acuña [Acuña, 1998, a] se habla de la relevancia de los procesos de comunicación, integrados por el proceso de conformación de equipo y el proceso de adquisición de información y conocimiento en el modelo de proceso software. Los patrones catalogados constituyen entonces una potente herramienta en el desarrollo de software y en particular los patrones de análisis la constituyen en etapas tempranas de desarrollo lo cual puede reportar mayores beneficios, dado que ayudan en la etapa de 10

comprensión del problema disminuyendo entonces los errores y mejorando la performance. El manejo de los patrones catalogados debería ser incorporado al modelo de proceso de reuso de una organización madura.

11

Patrón de diseño Los patrones de diseño son la base para la búsqueda de soluciones a 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.

Breve reseña histórica En 1979 el arquitecto Christopher Alexander aportó al mundo de la arquitectura el libro The Timeless Way of Building; en él proponía el aprendizaje y uso de una serie de patrones para la construcción de edificios de una mayor calidad. En palabras de este autor, "Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez." Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen denominado A Pattern Language, son un intento de formalizar y plasmar de una forma práctica generaciones de conocimiento arquitectónico. Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicación satisfactoria, ni son específicos a una situación particular o cultural; son algo intermedio. Un patrón define una posible solución

12

correcta para un problema de diseño dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones. Más tarde, en 1987, Ward Cunningham y Kent Beck usaron varias ideas de Alexander para desarrollar cinco patrones de interacción hombre-ordenador (HCI) y publicaron un artículo en OOPSLA-87 titulado Using Pattern Languages for OO Programs. No obstante, no fue hasta principios de la década de 1990 cuando los patrones de diseño tuvieron un gran éxito en el mundo de la informática a partir de la publicación del libro Design Patternsescrito por el grupo Gang of Four (GoF) compuesto por Erich Gamma, Richard Helm, Ralph Johnson y John Vlisides, en el que se recogían 23 patrones de diseño comunes.

Objetivos de los patrones Los patrones de diseño pretenden: -

Proporcionar catálogos de elementos reusables en el diseño de sistemas software.

-

Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.

-

Formalizar un vocabulario común entre diseñadores.

-

Estandarizar el modo en que se realiza el diseño.

-

Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

13

Asimismo, no pretenden: -

Imponer ciertas alternativas de diseño frente a otras.

-

Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Categorías de patrones Según la escala o nivel de abstracción: -

Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.

-

Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.

-

Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Además, también es importante reseñar el concepto de "antipatrón de diseño", que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores.

14

Además de los patrones ya vistos actualmente existen otros patrones como el siguiente: Interacción: Son patrones que nos permiten el diseño de interfaces web.

Estructuras o plantillas de patrones Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos. La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados: -

Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).

-

Clasificación del patrón: creacional, estructural o de comportamiento.

-

Intención: ¿Qué problema pretende resolver el patrón?

-

También conocido como: Otros nombres de uso común para el patrón.

-

Motivación: Escenario de ejemplo para la aplicación del patrón.

-

Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.

-

Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.

-

Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.

15

-

Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.

-

Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.

-

Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.

-

Código de ejemplo: Código fuente ejemplo de implementación del patrón.

-

Usos conocidos: Ejemplos de sistemas reales que usan el patrón.

-

Patrones relacionados: Referencias cruzadas con otros patrones.

Relación de principales patrones GoF (Gang Of Four) Patrones creacionales Object Pool (no pertenece a los patrones especificados por GoF): se obtienen objetos nuevos a través de la clonación. Utilizado cuando el costo de crear una clase es mayor que el de clonarla. Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se utiliza una interfaz del prototipo para crear un nuevo objeto por clonación. El proceso de clonación se inicia instanciando un tipo de objeto de la clase que queremos clonar. Abstract Factory (fábrica abstracta): permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.

16

Builder (constructor virtual): abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto. Factory Method (método de fabricación): centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al la casuística, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear. Prototype (prototipo): crea nuevos objetos clonándolos de una instancia ya existente. Singleton (instancia única): garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de global a dicha instancia.

Patrones estructurales

-

Adapter o Wrapper (Adaptador o Envoltorio): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.

-

Bridge (Puente): Desacopla una abstracción de su implementación.

-

Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.

-

Decorator (Decorador): Añade funcionalidad a una clase dinámicamente.

-

Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.

-

Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.

-

Proxy: Mantiene un representante de un objeto.

17

-

Módulo: Agrupa varios elementos relacionados, como clases, singletons, y métodos, utilizados globalmente, en una entidad única.

Patrones de comportamiento

Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma. Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo. Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos. Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto. Memento (Recuerdo): Permite volver a estados anteriores del sistema. Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él. State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. 18

Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución. Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.

Patrones de interacción El primer intento por aplicar este concepto en el diseño de las interfaces de se dio por Ward Cummingham y Kent Beck quienes adaptaron la propuesta de C. Alexander y crearon cinco patrones de interfaz: Window per task, Few panes, Standard panes, Nouns and verbs, y Short Menu. En años más recientes investigadores como Martin Van Welie, Jennifer Tidwell, Jaime Muñoz han desarrollado colecciones de patrones de interacción para la World Wide Web. En dichas colecciones captan la experiencia de programadores y diseñadores expertos en el desarrollo de interfaces usables y condensan esta experiencia en una serie de guías o recomendaciones, que puedan ser usadas por los desarrolladores novatos con el propósito de que en poco tiempo adquieran la habilidad de diseñar interfaces que incidan en la satisfacción de los s. Los patrones de interacción buscan la reutilización de interfaces eficaces y un manejo óptimo de los recursos de las páginas web, haciendo más eficaz el consumo de tiempo en el diseño del sitio web y permitiendo a los programadores novatos adquirir más experiencia.

19

Aplicación en ámbitos concretos Además de su aplicación directa en la construcción de software en general, y derivado precisamente del gran éxito que han tenido, los patrones de diseño han sido aplicados a múltiples ámbitos concretos produciéndose "lenguajes de patrones" y extensos "catálogos" de la mano de diversos autores. En particular son notorios los esfuerzos en los siguientes ámbitos: Patrones de interfaces de , esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina (véase Interacción persona-computador, Interfaz gráfica de ). Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstracción importante para maximizar factores como la escalabilidad o el mantenimiento del sistema. Patrones para la integración de sistemas (véase Integración de aplicaciones empresariales), es decir, para la intercomunicación y coordinación de sistemas heterogéneos. Patrones de flujos de trabajo, esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales. Véase también BPM.

20

REFERENCIAS [Acuña, 1998] Acuña, S.; Lasserre, C.; Quincoces,V.E.y otros. Proceso software simbiótico: Validación y Refinación [Champeaux, 1997] Champeaux, D. Object Oriented Development Process and Metrics. Prentice Hall Building. 1997. [Martin, 1994] Martin, J.; Odell, J. Análisis y diseño Orientado a Objetos. Editorial Prentice Hall. 1994. [Martin, 1997] Martin J., Odell J. Métodos Orientados a Objetos: Consideraciones Prácticas. Editorial Prentice Hall Hipanoamericana S.A., 1997. [Martin, 1998] Martin, J.; Odell J. "Object Oriented Methods: A Foundation". Editorial Prentice Hall PTR. 2nd. Ed. 1998. [Quincoces, 1998,] Quincoces, V.E.; Giandini. R.S. Patrones de Análisis Orientado a Objetos para el Dominio Tributario. [Eric Evans, Addison-Wesley, 2004.] Domain Driven Design. [Grady Booch, 1994. ] Object-Oriented Analysis and Design with Applications (2nd Edition)

21