Instituto Tecnolgico de ChilpancingoSistemas y ComputacinIngeniera en Sistemas Computacionales

PATRONES DE ANALISIS Y DISEO

MATERIA: Fundamentos de Desarrollo de Sistemas

PROFESOR.: Maria Zavala Hurtado

ALUMNOS: ngel Bello Guzmn 09520393Marco Antonio Tolentino Alarcon09520383

Chilpancingo, Gro., Abril del 2013Resumen

El objetivo de este documento es transmitir conocimientos acerca de la construccin de un modelo que permita elaborar el diseo del software de un sistema en base al negocio donde funcionar dicho sistema. Se muestra una forma de trabajo que reune la informacin generada por los modelos de Casos de Uso y de Dominio, la cual genera como resultado un modelo de Anlisis rico en conocimiento del negocio y con la estructura necesaria para constituirse en el inicio del diseo posterior.

ContenidoResumen2Patrones de Analisis4LOS PATRONES EN ORIENTACION A OBJETOS6Los Patrones en el Proceso de Desarrollo de Software7Algunas Consideraciones Sobre los Patrones de Anlisis9Catlogos10Patrn de diseo12Breve resea histrica12Objetivos de los patrones13Categoras de patrones14Estructuras o plantillas de patrones15Relacin de principales patronesGoF(Gang Of Four)16Patrones creacionales16Patrones estructurales17Patrones de comportamiento18Patrones de interaccin19Aplicacin en mbitos concretos20

Patrones de Analisis

El software tiene un papel cada vez mas preponderante en el mundo moderno, por lotanto toman relevancia los objetivos de reduccin de tiempos y costos e incremento de la calidad en su proceso de desarrollo.Segn Jacobson [Jacobson, 1997], para lograr los objetivos planteados en la construccin 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 realizacin de muchas actividades, pero esto no ha conducido a una mejora record de tipo universal. Por lo tanto, para la mayora 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 ingeniera de software. Ser exitoso con la ingeniera de software orientada a objetos en la industria requiere que el reuso de software a gran escala sea puesto en prctica.Una de las principales ventajas que incorpora el paradigma orientado a objetos en la ingeniera de software es facilitar el reuso a muchos niveles. Segn 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. Segn Coad [Coad, 1995] la comprensin es uno de los prerrequisitos para el reuso ya que ste puede hacerse efectivo slo si los desarrolladores pueden encontrar y entender algo que es usado exitosamente ms de una vez. Segn Champeaux [Champeaux, 1997], el reuso de un dominio especfico no es algo trivial, encontrar el artefacto adecuado no es obvio y adaptar un artefacto o construirlo tiene su costo. Goldberg y Rubin [Goldberg, 1995], hablan de estrategia de reuso y de modelos de proceso de reuso en una organizacin.Segn Coad [Coad, 1995] los patrones son una plantilla de objetos que interactan y que pueden ser usados una y otra vez por analoga y el propsito de las estrategias y de los patrones es reducir el tiempo al construir modelos de objetos.Segn Beck [Beck, 1997], los patrones permiten el desarrollo de cdigo con rapidez,con menor riesgo, fcil de mantener y reusar, se disean en general para cubrir necesidades a corto y largo plazo y se pueden incorporar al proceso existente. Forman una base flexible para producir variaciones sistemticas en software. Cada patrn registra una solucin a un problema recurrente, incluyendo cmo reconocer la presencia del problema y cmo generar la solucin para adaptarse al contexto. Los patrones conducen naturalmente uno a otro formando un tipo de fbrica de decisiones que puede resolver problemas de gran escala.Segn Martin y Odell [Martin, 1998], "La orientacin a objetos es a menudo descripta en trminos de estructura y comportamiento. La palabra estructura es una metfora visual, espacial, que se refiere a una visin esttica de cmo los objetos se proyectan en el espacio. La estructura puede especificar varias configuraciones de objetos, tales como empleados, documentos y diseos de ingeniera. En contraste, el comportamiento se refiere a cmo nuestro mundo cambia a travs 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". Segn Jacobson [Jacobson, 1995], un modelo orientado a objetos de una compaa muestra las funciones de la misma en el mundo, qu, cuando y cmo lo hace. Enfatiza en la arquitectura pero tambin describe los distintos cursos de eventos que tienen lugar dentro de la compaa.LOS PATRONES EN ORIENTACION A OBJETOS

Los patrones han tomado relevancia recientemente en los desarrollos de software. Segn Coad [Coad, 1992], un patrn orientado a objetos es una abstraccin formada por un pequeo 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 introduccin, los define como una plantilla de objetos que interactan.Segn Martin Fowler [Fowler, 1997], un patrn es una idea que ha sido til en un contexto prctico y probablemente lo sea en otros. Es una solucin prctica para un problema concreto. Si un patrn 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 prctico con el significado de que los patrones evolucionan de la experiencia prctica en proyectos reales. Como consecuencia considera que un patrn se descubre y no que se inventa.Coad [Coad, 1992], plantea que cuando se encuentra un patrn uno comienza a pensar en base a ese nuevo bloque de construccin, mas que basndose en sus partes. Esto induce a pensar que el nombre que se le da a un patrn adquiere gran importancia. Segn Fowler [Fowler, 1997], dar nombres puede ser una de las actividades mas difciles del modelado. Los patrones existentes que se pueden combinar ante un nuevo requerimiento sevuelven mas sutiles y extensibles [Hay, 1996]. Segn Schmidt [Schmidt, 1996], "Cuando los patrones se combinan construyen un lenguaje que provee un proceso para la resolucin ordenada de problemas de desarrollo de software. Los lenguajes de patrones no son lenguajes formales, sino mas bien una coleccin de 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 bibliografa se puede observar patrones que cubren distintas actividades de desarrollo de software como anlisis, diseo y codificacin. Los patrones de anlisis 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 cmo la gente percibe el mundo. Es valioso basar un diseo de sistemas en ellos, e inclusive para cambiar la percepcin, lo cual conduce a un proceso de reingeniera [Fowler,1997]. Se enuncian de la forma problema-solucin.Los patrones de anlisis reflejan la estructura conceptual del proceso de los negocios, ms que de la implementacin del software. Aunque en general se piensa que no existen marcadas diferencias entre anlisis y diseo orientado a objetos, es en la fase de anlisis cuando se trata de comprender los detalles concernientes al problema y se busca detrs 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 anlisis involucra el modelado de un dominio. Es entonces fundamentalmente diferente al diseo de software, el cual es orientado a la implementacin".Segn Gamma [Gamma, 1995], los patrones de diseo describen soluciones simples y elegantes que resuelven problemas especficos de diseo. Captan soluciones que han sido desarrolladas y han evolucionado en el tiempo, es decir, que tienen cierto nivel de abstraccin. Por consiguiente no son diseos que se tienden a generar inicialmente, reflejan el esfuerzo que los desarrolladores 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 estndares 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 descripcin de cundo se aplica, es decir el problema y su contexto), la solucin (describe los elementos que integran el diseo, sus relaciones y colaboraciones) y las consecuencias (resultados y consideraciones de aplicar el patrn y que, en general se refieren a compromiso de espacio y tiempo). Los presenta siguiendo las siguiente plantilla: Intencin Otro nombre por el que se lo conoce Motivacin Aplicabilidad Estructura Colaboraciones Consecuencias Implementacin Ejemplo de codificacin Usos conocidos Patrones relacionados

Coad en [Coad, 1995] presenta 31 patrones de diseo con la siguiente estructura: Interacciones tpicas 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 programacin y proporcionan gran cantidad de material para discusin en la enseanza para aplicar a una situacin particular, cubren tcticas de programacin diaria y se refieren mas al estilo de programacin. Cada patrn presenta: Problema recurrente que se presenta en el quehacer diario Consideraciones que afectan las soluciones del problema Receta concreta para crear la solucin del problema.Algunas Consideraciones Sobre los Patrones de Anlisis

Las tcnicas de anlisis intentan ser independientes de la tecnologa de software. Idealmente una tcnica de modelado conceptual debera ser independiente de la tecnologa de software pues esto logra evitar que la tecnologa oculte la comprensin del problema y que el modelo resultante sea igualmente til en cualquier tecnologa de software [Fowler, 1997].En anlisis 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 anlisis aun es prematuro determinar cuales sern las clases que finalmente intervendrn en el diseo; no obstante muchas de ellas podrn coincidir con los tipos del anlisis.Segn Martin y Odell [Martin, 1998], "Un tipo es un concepto (es una nocin o una idea que nosotros aplicamos a los objetos en nuestra conciencia). Es un tipo de objeto".Catlogos

Schmidt [Schmidt, 1996] expresa que las disciplinas maduras de ingeniera disponende manuales o guas que describen soluciones satisfactorias para encarar problemas planteados. Por ejemplo los diseadores de automviles no disean autos usando directamente las leyes de la fsica, en su lugar ellos reusan diseos estandarizados exitosos. En la ingeniera de software encontramos por ejemplo la obra de Gamma [Gamma, 1995], donde se encara un catlogo de patrones de diseo y en Beck [Beck, 1997], 92 patrones de Smalltalk..Ward Cunningham manifiesta (en la seccin 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 implementacin.Segn Fowler [Fowler, 1997], "as como leer buen cdigo ensea mucho acerca de programacin, buenos modelos ensean mucho sobre anlisis y diseo". Los patrones son por definicin buenos modelos.Los catlogos, al intensificar la evolucin hacia un lenguaje comn incrementan la comunicacin, con lo cual incrementan la performance en el desarrollo de software.Segn Beck [Beck, 1997], para el que dirige un proyecto de software los patrones indican cmo aplicar bien los principios de la ingeniera de software y pueden ser la base para un vocabulario comn de los desarrolladores. En Acua [Acua, 1998, a] se habla de la relevancia de los procesos de comunicacin, integrados por el proceso de conformacin de equipo y el proceso de adquisicin de informacin 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 anlisis la constituyen en etapas tempranas de desarrollo lo cual puede reportar mayores beneficios, dado que ayudan en la etapa de comprensin del problema disminuyendo entonces los errores y mejorando la performance. El manejo de los patrones catalogados debera ser incorporado al modelo de proceso de reuso de una organizacin madura.

Patrn de diseo

Lospatrones de diseoson la base para la bsqueda de soluciones a problemas comunes en el desarrollo desoftwarey otros mbitos referentes al diseo de interaccin o interfaces.Un patrn de diseo resulta ser una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado suefectividadresolviendo problemas similares en ocasiones anteriores. Otra es que debe serreutilizable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias.Breve resea histrica

En 1979 elarquitectoChristopher Alexanderaport al mundo de la arquitectura el libroThe Timeless Way of Building; en l propona el aprendizaje y uso de una serie de patrones para la construccin de edificios de una mayor calidad.En palabras de este autor, "Cada patrn describe un problema que ocurre infinidad de veces en nuestro entorno, as como la solucin al mismo, de tal modo que podemos utilizar esta solucin un milln de veces ms adelante sin tener que volver a pensarla otra vez."Los patrones que Christopher Alexander y sus colegas definieron, publicados en un volumen denominadoA Pattern Language, son un intento de formalizar y plasmar de una forma prctica generaciones de conocimiento arquitectnico. Los patrones no son principios abstractos que requieran su redescubrimiento para obtener una aplicacin satisfactoria, ni son especficos a una situacin particular o cultural; son algo intermedio. Un patrn define una posible solucin correcta para un problema de diseo dentro de un contexto dado, describiendo las cualidades invariantes de todas las soluciones.Ms tarde, en 1987,Ward CunninghamyKent Beckusaron varias ideas de Alexander para desarrollar cinco patrones de interaccin hombre-ordenador (HCI) y publicaron un artculo en OOPSLA-87 tituladoUsing Pattern Languages for OO Programs.No obstante, no fue hasta principios de la dcada de 1990 cuando los patrones de diseo tuvieron un gran xito en el mundo de la informtica a partir de la publicacin del libroDesign Patternsescrito por el grupoGang of Four(GoF) compuesto porErich Gamma,Richard Helm,Ralph JohnsonyJohn Vlisides, en el que se recogan 23 patrones de diseo comunes.Objetivos de los patrones

Los patrones de diseo pretenden: Proporcionar catlogos de elementos reusables en el diseo de sistemas software. Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente.

Asimismo, no pretenden: Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo.No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrn, 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".Categoras de patrones

Segn la escala o nivel de abstraccin: Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software. Patrones de diseo: Aquellos que expresan esquemas para definir estructuras de diseo (o sus relaciones) con las que construir sistemas de software. Dialectos: Patrones de bajo nivel especficos para un lenguaje de programacin o entorno concreto.Adems, tambin es importante resear el concepto de "antipatrn de diseo", que con forma semejante a la de un patrn, intenta prevenir contra errores comunes de diseo en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseos muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejn sin salida por haber cometido los mismos errores.

Adems de los patrones ya vistos actualmente existen otros patrones como el siguiente:Interaccin: Son patrones que nos permiten el diseo de interfaces web.Estructuras o plantillas de patrones

Para describir un patrn se usan plantillas ms o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicacin uniforme entre diseadores. Varios autores eminentes en esta rea han propuesto plantillas ligeramente distintas, si bien la mayora definen los mismos conceptos bsicos.La plantilla ms comn es la utilizada precisamente por elGoFy consta de los siguientes apartados: Nombre del patrn: nombre estndar del patrn por el cual ser reconocido en la comunidad (normalmente se expresan en ingls). Clasificacin del patrn: creacional, estructural o de comportamiento. Intencin: Qu problema pretende resolver el patrn? Tambin conocido como: Otros nombres de uso comn para el patrn. Motivacin: Escenario de ejemplo para la aplicacin del patrn. Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrn. Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrn. Participantes: Enumeracin y descripcin de las entidades abstractas (y sus roles) que participan en el patrn. Colaboraciones: Explicacin de las interrelaciones que se dan entre los participantes. Consecuencias: Consecuencias positivas y negativas en el diseo derivadas de la aplicacin del patrn. Implementacin: Tcnicas o comentarios oportunos de cara a la implementacin del patrn. Cdigo de ejemplo: Cdigo fuente ejemplo de implementacin del patrn. Usos conocidos: Ejemplos de sistemas reales que usan el patrn. Patrones relacionados: Referencias cruzadas con otros patrones.

Relacin de principales patronesGoF(Gang Of Four)

Patrones creacionales

Object Pool(no pertenece a los patrones especificados por GoF): se obtienen objetos nuevos a travs de la clonacin. 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 clonacin. El proceso de clonacin se inicia instanciando un tipo de objeto de la clase que queremos clonar.Abstract Factory(fbrica 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.Builder(constructor virtual): abstrae el proceso de creacin de un objeto complejo, centralizando dicho proceso en un nico punto.Factory Method(mtodo de fabricacin): centraliza en una clase constructora la creacin de objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear.Prototype(prototipo): crea nuevos objetos clonndolos de una instancia ya existente.Singleton(instancia nica): garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso 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 podra utilizarla. Bridge(Puente): Desacopla una abstraccin de su implementacin. Composite(Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. Decorator(Decorador): Aade funcionalidad a una clase dinmicamente. 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 idntica informacin. Proxy: Mantiene un representante de un objeto. Mdulo: Agrupa varios elementos relacionados, como clases, singletons, y mtodos, utilizados globalmente, en una entidad nica.

Patrones de comportamiento

Chain of Responsibility(Cadena de responsabilidad): Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada.Command(Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma.Interpreter(Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas necesarias para interpretarlo.Iterator(Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementacin de estos.Mediator(Mediador): Define un objeto que coordine la comunicacin 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 automticamente todos los objetos que dependen de l.State(Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.Strategy(Estrategia): Permite disponer de varios mtodos para resolver un problema y elegir cul utilizar en tiempo de ejecucin.Template Method(Mtodo plantilla): Define en una operacin 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 jerarqua de clases sin modificar las clases sobre las que opera.Patrones de interaccin

El primer intento por aplicar este concepto en el diseo de las interfaces de usuario 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, yShort Menu. En aos ms recientes investigadores como Martin Van Welie, Jennifer Tidwell, Jaime Muoz han desarrollado colecciones de patrones de interaccin para laWorld Wide Web. En dichas colecciones captan la experiencia de programadores y diseadores expertos en el desarrollo de interfaces usables y condensan esta experiencia en una serie de guas o recomendaciones, que puedan ser usadas por los desarrolladores novatos con el propsito de que en poco tiempo adquieran la habilidad de disear interfaces que incidan en la satisfaccin de los usuarios. Los patrones de interaccin buscan la reutilizacin de interfaces eficaces y un manejo ptimo de los recursos de laspginas web, haciendo ms eficaz el consumo de tiempo en el diseo delsitio weby permitiendo a los programadores novatos adquirir ms experiencia.

Aplicacin en mbitos concretos

Adems de su aplicacin directa en la construccin de software en general, y derivado precisamente del gran xito que han tenido, los patrones de diseo han sido aplicados a mltiples mbitos concretos producindose "lenguajes de patrones" y extensos "catlogos" de la mano de diversos autores.En particular son notorios los esfuerzos en los siguientes mbitos:Patrones deinterfaces de usuario, esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-mquina (vaseInteraccin persona-computador,Interfaz grfica de usuario).Patrones para la construccin de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstraccin importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.Patrones para la integracin de sistemas (vaseIntegracin de aplicaciones empresariales), es decir, para la intercomunicacin y coordinacin de sistemas heterogneos.Patrones deflujos de trabajo, esto es para la definicin, construccin e integracin de sistemas abstractos de gestin de flujos de trabajo y procesos con sistemas empresariales. Vase tambinBPM.

REFERENCIAS[Acua, 1998] Acua, S.; Lasserre, C.; Quincoces,V.E.y otros. Proceso softwaresimbitico: Validacin y Refinacin[Champeaux, 1997] Champeaux, D. Object Oriented Development Process andMetrics. Prentice Hall Building. 1997.[Martin, 1994] Martin, J.; Odell, J. Anlisis y diseo Orientado a Objetos. EditorialPrentice Hall. 1994.[Martin, 1997] Martin J., Odell J. Mtodos Orientados a Objetos: ConsideracionesPrcticas. Editorial Prentice Hall Hipanoamericana S.A., 1997.[Martin, 1998] Martin, J.; Odell J. "Object Oriented Methods: A Foundation". EditorialPrentice Hall PTR. 2nd. Ed. 1998.[Quincoces, 1998,] Quincoces, V.E.; Giandini. R.S. Patrones de Anlisis Orientado aObjetos para el Dominio Tributario. [Eric Evans, Addison-Wesley, 2004.] Domain Driven Design. [Grady Booch, 1994. ] Object-Oriented Analysis and Design with Applications (2nd Edition) 6