patrones de diseño jhonny.docx

Patrones de DiseñoPatrones de Diseño Ingeniería del Software

08/01/2014Materia: Fundamentos de Ingeniería de SoftwareAlumno: Lucas Cornejo JonathanProfesor: Juan Nicolás RamírezGrupo: 3621

Alumno: Lucas Cornejo JonathanProfesor: Juan Nicolás RamírezMateria: Ingeniería de Software

Grupo: 3621

ÍNDICE:


Grupo: 3621

Patrones de Diseño

Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.”

En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios).

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: Aquéllos que expresan un esquema organizativo estructural fundamental para sistemas de software.

· Patrones de diseño: Aquéllos 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.


Grupo: 3621

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.

Características:

· Las plantillas son de bajo costo.

· Se utilizan en diferentes tipos de aplicaciones: web, escritorio, app móviles.

· El código es reutilizable; comprada la plantilla, se adquiere la propiedad intelectual de la misma.


Grupo: 3621

Patrones orientados a objetos (Análisis y diseño a objetos)

Tareas del patrón:

· Identificación de casos de uso.

· Definición del modelo conceptual.

· Especificación de diagrama de servicio.

· Definición de clases.

Identificación de casos de uso

Definición:

El caso de uso describe una funcionalidad parcial del sistema que se desarrolla

Notación: Diagrama de casos de uso.


Grupo: 3621

Modelo conceptual

Abarca las abstracciones del mundo real en términos de claves y objetos.

El Modelo Conceptual ilustra:

• Conceptos (Objetos) en el dominio del problema.

• Es el instrumento (artefacto) más importante de crear en el AOO.• Es la representación de cosas del mundo real y NO de componentes de software.

en él NO se definen operaciones.• Puede representarse mediante un diagrama de estructura estático (notación UML).

Características

El modelo conceptual se convierte en el insumo básico del diagrama de clases.

Diagrama de secuencia

Describe espacial y temporal el flujo normal de eventos entre los diferentes conceptos presentes en el sistema.

Definición de clases:

Se especifican las clases presentes en el sistema y se paramétrizan (métodos y atributos para cada clase).


Grupo: 3621

Patrones de diseño vista-control

Ofrece un número mayor de ventajas con respecto al patrón orientado a objetos.

Tiene tres componentes (capas de desarrollo)

• Capa vista: en términos de la interfaz de usuario.

• Capa lógica: se almacena e implementan los objetos de la aplicación, tiene dos presentaciones:

Capa conceptos:

Ejemplo: Usuario y contraseña

Capa conceptos:

Ejemplo: Nombre del usuario y comparar contraseña.

• Capa de almacenamiento: gestión de archivos, Bases de datos.

Ejemplo: gestión de archivos con los nombres de los usuarios El patrón vista-control sugiere un diseño TOP-DOWN con una importancia centrada en la interfaz de usuario la cual debe ser obtenida a partir de los requisitos del producto software.

Requisitos:

Es una necesidad que tiene un usuario o cliente de un producto software.

Necesidad se traduce en términos de funciones.

Características:

• Todos los requisitos no deben dar posibilidad a la ambigüedad• Los requisitos deben permitir entender el domino de la aplicaron• Los requisitos se deben obtener del cliente o usuario


Grupo: 3621

Diagrama de casos de uso

Actor: fuente o sumidero "Externo" al sistema que interactúa con el desencadenado una serie de eventos interrelacionados.

Atributo del sistema: Son requisitos no funcionales, que son necesidades propias del producto software.

Aplicación

Medio físico (Hardware) memoria, etc.

Tolerancia a fallos.

Metáfora de la interfaz: Describe el estándar utilizado para desarrollar la interfaz.

Técnicas para levantar requisitos:

1-Entrevista.

2-JAD (Joint applications Development).

3-Sketch ans story board.

4-Concept Moping.

5-Brainstorming (lluvia de ideas).

6-Layout.

7-Use case.


Grupo: 3621

8-Patrones.

Patrón Arquitectónico de capas

La arquitectura del SI es una descripción de los

Subsistemas y componentes, y las relaciones entre ellos.

· Determina:

· La organización estructural del SI.

· La selección de los elementos estructurales.

· Las interfaces entre ellos.

· El comportamiento de los componentes.

· Un componente es una parte física y reemplazable de un sistema.

Catálogo parcial de patrones arquitectónicos

· Llamada y retorno

· estilo más usado en los grandes SI

· Descomposición modular jerárquica

· Orientado a objetos

· En capas

· Centrado en los datos

· permite la manipulación compartida de datos

· Repositorio

· Pizarra

· Flujo de datos

· permite la transformación incremental de los datos

· Batch secuencial

· Tubos y filtros

· Modelo – vista – controlador

· para sistemas interactivos

Patroness Grasp (General reponsability assignament software pattern)

En diseño orientado a objetos, GRASP son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns" . Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software.


Grupo: 3621

Patrones de software para asignar responsabilidades

Función:

Definir en las clases de análisis.

1-La clase con mayor jerarquía para implementar en ella los métodos.

Clase patrón

2-Asignar responsabilidades a las clases.

Elementos para definir un patrón Grasp.

Diagrama de paquetes

Diagrama de secuencia

Diagrama de paquetes

Paquete: Agrupación de casos de uso con aspectos similares en su funcionalidad. Ejemplo:


Grupo: 3621

Diagrama de secuencia:

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams".


Grupo: 3621

Patrones Grasp

· Patrón experto.

· Patrón creador.

· Patrón bajo acoplamiento.

· Patrón alta cohesión.

· Patrón controlador.

Patrón experto

Determina en un modelo conceptual (Diagrama de clases) la clase que posee la mayor jerarquía para asignarle una responsabilidad "La responsabilidad que se quiera evaluar y debe ser implementado por un método".

Ventajas del patrón experto

Garantizar el encapsulamiento de la información

Facilita el bajo acoplamiento en las aplicaciones

Patrón creador

Se utiliza cuando se quiere a partir de una clase con alta jerarquía obtener clases descendiente o instancias a partir de las clases obtenidas.

Tipos de clases:

Clases abstractas: son las clases que dan origen a otras solamente.

Clases concretas: son las clases a partir de las cuales se pueden obtener instancias.

El patrón creador define dos estructuras dentro de la jerarquía


Grupo: 3621

Estructura AKO

Estructura APO

AKO(A King of): una clase de

APO(A Punto of): una parte de

Patrón bajo Acoplamiento

Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases:

1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)

2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.

3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.

Patrón alto cohesión

Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.

1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.

2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.

3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación deben ser ejecutadas “al mismo tiempo”.

4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.


Grupo: 3621

5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.

6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS

7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.

Patrón controlador

Es el encargado de definir las estructuras para los patrones experto y creador.

Experto: Diagrama de secuencia.

Creadas: Jerarquía: AKO, APO.

Patrones Gof

Gang-of-Four (“pandilla de los cuatro”) Descritos en el libro Design Patterns(Gama1995) definieron un catálogo con 23 Patrones básicos. Los patrones de diseño (design patterns) 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 es 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 reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Relación de principales patrones GoF (Gang Of Four)


Grupo: 3621

Patrones creacionales

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 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 un 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.

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.


Grupo: 3621

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.

Bibliografía:

-Ingeniería del software, un enfoque práctico de Roger Pressman.

-Ingeniería del software de Ian Sommerville:

-Ingeniería de sistemas de software de Gonzalo Leon Serrano:

patrones de diseño jhonny.docx

Documents