Unidad 4

Unidad 4 .Diseño Orientado a Objeto

 

• Patrones de diseño, componentes, diseño de interfases del sistema, notación de diseño.
• Medición de los atributos del diseño.

Diseño orientado a objetos

Diseño orientado a objetos es una fase de la metodología orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en términos de objetos, en vez de procedimientos, cuando planifican su código. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La ‘interfaz del objeto’, esto es, las formas de interactuar con el objeto, también se definen en esta etapa. Un programa orientado a objetos se caracteriza por la interacción de esos objetos. El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el análisis orientado a objetos.

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 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 Patterns escrito 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.

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.

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.
• 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.
• 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 usuario 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 acceso global a dicha instancia.

Patrones estructurales

• Adapter (Adaptador): 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 (Envoltorio): 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.
• 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.
• 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 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, 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 usuarios. 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.

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 usuario, 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 usuario).
• 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.

Notaciones para el diseño

La notación de diseño, junto con los conceptos de programación estructurada, permite al diseñador representar detalles procedimentales de manera que se facilite la traducción a código. Hay disponibles notaciones gráficas, tabulares y de texto.

Gráfica del diseño
Es incuestionable que las herramientas gráficas, tales como los diagramas de flujo o diagramas de caja, proporcionan una excelente forma gráfica que describen muy bien el detalle procedimental.
Sin embargo, si se emplean mal las herramientas gráficas, una imagen incorrecta puede conducir a un software erróneo.
El diagrama de flujo es un gráfico muy sencillo. Se usa una caja (cuadro/rectángulo) para indicar un paso del proceso. Un rombo representa una condición lógica y las flechas indican el flujo de control.

Notación tabular del diseño
Las tablas de decisión proporcionan una notación de procedimientos a una forma tabular. Es difícil que la tabla se pueda interpretar mal, e incluso puede usarse como entrada interpretable por la máquina para un algoritmo manejado por tabla.
La tabla se divide en cuatro secciones el cuadrante superior izquierdo contiene una lista de todas las condiciones. El cuadrante inferior izquierdo contiene una lista de todas las acciones posibles basándose en combinaciones de las condiciones. Los cuadrantes de la derecha forman una matriz que indican las combinaciones de las condiciones y las correspondientes acciones que se han de producir para cada combinación específica. Por lo tanto, cada columna de la matriz puede interpretarse como una regla de procesamiento.

Marcos (frameworks) y Patrones

• Marco: conjunto de clases reutilizable, librería
• reutilizar desarrollos
• Patrón: estructura que proporciona una determinada función
• reutilizar ideas

Relación entre ambos:

• Los marcos implementan patrones
• Los marcos pueden implementar otras ideas que no sean “patrones”
• Los patrones pueden implementarse directamente sin usar marcos

3.- Componente

• Bloque de construcción modular para software de computadora.

• “Una parte modular, entregable y remplazable de un sistema que encapsula su implementación y expone un conjunto de interfaces” según la OMG

Unified Modeling Language Specification.

• Se puede definir y usar componentes desde 3 puntos de vista:

• Orientado a Objetos
• “Convencional”
• Relacionado a procesos

Orientado a objetos :

• Desde este punto de vista, un componente contiene un conjunto de clases que colaboran entre sí.
• El diseño de un componente implica añadir a la definición de clases en el análisis(dominio del problema) información para su implementación en software.

Ejemplo de elaboración de un componente de diseño

[Pressman 2005]

4.- Medición de Atributos de calidad y entidades de diseño

En primer lugar debemos acotar el contexto en el que nos movemos, ya que la calidad, en el software, se puede entender como calidad de proceso o de producto. La calidad de proceso ha sido objeto de mucho interés en las últimas décadas (Humphrey,1989) y su desarrollo ha concienciado a los profesionales de la necesidad de aplicar la calidad a otros aspectos del software. En nuestro caso estamos claramente centrados en la calidad del producto software y, dentro de ella, en el producto derivado de la fase de diseño(Software de sign, part 2 , 2004). Fenton y Pfleeger (1998) explican que es un paso previo al establecimiento de las métricas el definir qué atributos o propiedades de qué elementos son los que queremos medir. Posteriormente podremos establecer si para medir dichos atributos es necesario medir otros y derivar los que nos interesan de ellos o bien se puede hacer directamente. En nuestro caso la única norma que hemos encontrado en la literatura que da una definición de calidad de producto software en base a atributos es ISO 9126 (ISO/IEC, 2001). Dicha norma establece que la medición de la calidad de un producto software debe hacerse en base a sus atributos, siendo éstos internos, propiedades características de cómo se estructura el software, o externos, cualidades observables aún sin conocer cómo está construido. De hecho no se habla de calidad, en general, sino de calidad interna y calidad externa, afirmándose que la calidad interna de un producto software influye directamente en su calidad externa. De algún modo se está diciendo que mejorando la calidad interna se mejora directamente la calidad observada en atributos de uso del producto software. Tanto la calidad interna como la externa se definen, en ISO 9126, como un conjunto de 6 características:

Funcionalidad:

la capacidad del software de proveer las funciones que cumplen con las necesidades implícitas y explícitas cuando el mismo es utilizado bajo ciertas condiciones.

Fiabilidad:

La capacidad del software de mantener un nivel específico de rendimiento bajo determinadas condiciones de uso.

Usabilidad:

La capacidad del producto software de ser entendido, aprendido, usado y atractivo al usuario, cuando se usa bajo ciertas condiciones.

Eficiencia:

La capacidad del software de ofrecer el rendimiento apropiado con respecto a la cantidad de recursos utilizados, bajo condiciones prefijadas.

Mantenibilidad:

La capacidad del producto de ser modificado. Dichas modificaciones pueden incluir correcciones, mejoras o adaptaciones a cambios en el entorno y en los requisitos y especificaciones funcionales.

Portabilidad:

la capacidad del software de ser trasladado de un entorno (informático) aotro.Estas características son generales para cualquier tipo de programa informático o software independientemente de si el paradigma empleado para construirlo es el Orientado a Objetos, el estructurado u otro cualquiera, sin embargo si que afectará a la manera de medirlas. Dichas características se dividen a su vez en sub características tal como se puede ver en el siguiente esquema.

“Convencional”

• Desde este punto de vista, un componente es un elemento funcional de un programa que incluye lógica de procesamiento, estructuras de datos internas requeridas para implementar dicha lógica y una interfaz que permite que el componente sea invoca doy que se le puedan pasar datos.
• Normalmente llamado “módulo”.
• Roles de un componente “convencional”
• Componente de control: Coordina el llamado a otros componentes del dominio del problema.
• Componente del dominio del problema: implementa una función completa o parcial que es requerida por el usuario.
• Componente de infraestructura: responsable de las funciones que apoyan el procesamiento requerido en el dominio del problema.
• Utilizan cartas de estructura para describir sistemas.

Relacionado a procesos

• Reutiliza software.
• Cuando se desarrolla la arquitectura, se escogen componentes o patrones de diseño de un catálogo, los cuales fueron creados para ser reutilizados.

 

Diseñando componentes basados en clases:

Hay 4 principios básicos de diseño que se pueden aplicar:

1.  Principio “abierto-cerrado” : Un componente debe estar abierto a extensiones pero debe estar cerrado para modificaciones. El/la diseñador(a) debe especificar el componente de manera que puede extenderse sin necesidad de hacer modificaciones internas al código.
2.  Principio de substitución de Liskov : las subclases deben ser sustituibles por sus clases bases. Cualquier clase derivada de una clase base debe cumplir con cualquier contrato implícito de la clase base con respecto a los componentes que la usan. Un“ contrato” es una precondición que debe ser verdadera antes de que el componente use la clase base, y una post-condición debe ser verdadera después de que el componente usa la clase base.
3.  Principio de dependencia de inversión: “Se debe depender de abstracciones, no de eventos concretos”
4.  Principio de segregación de interfaces: “Varias interfaces dependientes del cliente son mejor que una interfaz de propósito general”
5. Principio de equivalencia de liberación y re uso :“La granularidad del reusó es la gran ularidad de liberación.” Agrupar clases reusables en paquetes que se puedan administrar y controlar cuando una nueva versión se genere.
6. Principio de agrupamiento común :“Las clases que cambian al mismo tiempo deben agruparse”
7.  Principio de re uso común: “Las clases que no se reúsan al mismo tiempo no deben agruparse”