República Bolivariana de Venezuela

Universidad José Antonio Páez
Ministerio del Poder Popular para Educación
Universitaria Ciencia, Tecnología
San Diego, Carabobo
Sección 306C1

Sistema de Programas

Actividades de la Unidad V: Diseño Orientado a
Objeto

Integrantes
Jean Mobayed 26.781.589

San Diego 04/06/2017

7 Contratos……………………………………………………………………………pag..4 Evaluación de diseños………………………………………………………………pag.9 Patrones de Diseño…………………………………………………………………pag.5 Diagramas de secuencias de eventos del sistema……………………………………pag..15 .14 Bibliografía……………………………………………………………………….8 Principios de diseño…………………………………………………………………pag.pag.4 El modelo de clases…………………………………………………………………pag. Índice Introducción…………………………………………………………………………pag..pag.8 Diagrama de Colaboración………………………………………………………….3 Arquitectura de capas……………………………………………………………….10 Conclusión……………………………………………………………………….pag..pag..

Para que una solución sea considerada un patrón debe poseer ciertas características. como los sustantivos en el lenguaje. 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. como ocurre en la programación basada en prototipos. una clase es una plantilla para la creación de objetos de datos según un modelo predefinido. Un objeto puede ser creado instanciando una clase. Introducción En informática. que a su vez constan respectivamente de datos almacenados y de tareas realizables durante el tiempo de ejecución. como ocurre en la programación orientada a objetos. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. y métodos apropiados para operar con dichos datos -el comportamiento. Otra es que debe ser reutilizable. o mediante escritura directa de código y la replicación otros objetos. Cada objeto creado a partir de la clase se denomina instancia de la clase. Las clases se utilizan para representar entidades o conceptos. lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias. Cada clase es un modelo que define un conjunto de variables -el estado. . Por su parte un objeto es una unidad dentro de un software que consta de un estado y de un comportamiento.

2. Esta capa se comunica únicamente con la capa de negocio. en las que los usuarios trabajan e interaccionan con la interfaz del producto y comparten sus opiniones e inquietudes con los diseñadores y desarrolladores.Arquitectura por capas La programación por capas es un modelo de desarrollo software en el que el objetivo primordial es la separación (desacoplamiento) de las partes que componen un sistema software o también una arquitectura cliente-servidor: lógica de negocios capa de presentación y capa de datos. le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Capa de almacenamiento: es donde residen los datos y es la encargada de acceder a los mismos (conocida también como “capa de datos”). es sencillo y mantenible crear diferentes interfaces sobre un mismo sistema sin requerirse cambio alguno en la capa de datos o lógica. solo afectará al nivel requerido sin tener que revisar entre el código fuente de otros módulos. También se consideran aquí los programas de aplicación. auditabilidad y esfuerzo. en el centro del proceso de creación de software. por ejemplo. y con la capa de datos. reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (entendible y fácil de usar) para el usuario. De esta forma. Capa de presentación: la que ve el usuario (también se la denomina "capa de usuario"). Evaluación de diseños según criterios como facilidad de uso. para recibir las solicitudes y presentar los resultados. Esta capa se comunica con la capa de presentación. flexibilidad. Capa de aplicación: es donde residen los programas que se ejecutan (también se le denomina “capa de negocio” o “capa de lógica”). 3. Facilidad de uso El término “facilidad de uso” representa un enfoque que sitúa al usuario. El aspecto más visible de este enfoque son las pruebas de facilidad de uso. dado que se habrá reducido el Acoplamiento informático hasta una interfaz de paso de mensajes. complejidad. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos. Uno de los aspectos centrales que determinan la aceptación de un producto es su funcionalidad. para solicitar al gestor de base de datos almacenar o recuperar datos de él. Si un producto es funcional. 1. seguridad. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y. permitirá alcanzar los objetivos . presenta el sistema al usuario. no al sistema. se reciben las peticiones del usuario y se envían las respuestas tras el proceso. en caso de que sobrevenga algún cambio.

y la reprogramación de un proyecto. cómo lo vamos a hacer. quienes pudieran probar que los estándares del proceso se están siguiendo y realizar sugerencias para la mejora del proceso. Esto no puede ser abordado directamente. Auditabilidad El proceso debería ser comprensible para las personas ajenas a los participantes del proceso.Muchas preguntas con respecto a la seguridad. Information security (La seguridad de información) se refiere a la seguridad de información comúnmente como la protección de sistemas de información contra el acceso desautorizado o la modificación de información. empezando a programar sin más. permite asignar recursos a los proyectos. Complejidad La complejidad de los sistemas informáticos hace a veces necesario el desarrollo de proyectos software de decenas de miles de líneas de código. En particular. los conceptos de utilidad y facilidad de uso que. la seguridad debe de ser preservada durante la operación y el mantenimiento para asegurar la integridad de una parte (pedazo) de software. no se deben utilizar indistintamente. Esfuerzo La estimación de tiempo y esfuerzo es útil para la asignación de recursos. la seguridad del código y el proceso de software. poco han evolucionado con la tecnología en lo relacionado con el diseño computacional. Este concepto engloba.para los que se diseñó. Las metodologías convencionales de Ingeniería de Software tienen mecanismos robustos para hacer un análisis de necesidades y diseño de los sistemas. aunque guardan cierta relación. son relacionadas al ciclo vital de software. Es necesario analizar qué es lo que tenemos que hacer. ahorrando tiempo de desarrollo y costos (tanto desde el punto de vista del cliente como del punto de vista de la empresa desarrolladora) de modo que se puede lograr un acuerdo económico favorable para ambas partes. deben de ser considerados durante la fase del diseño y desarrollo. cómo se van a coordinar todas las personas que van a intervenir en el proyecto y cómo vamos a controlar el desarrollo del mismo de forma que al final obtengamos los resultados esperados. si está en una fase de almacenamiento. Tanto la utilidad como la facilidad de uso son necesarias para lograr la aceptación del producto en el mercado y ambas forman parte del concepto de funcionalidad. Flexibilidad La flexibilidad de un software tiene que ver con la capacidad de este para adaptarse a las necesidades actuales y futuras del usuario ¿Qué ventajas aporta un software flexible? Nos brinda la posibilidad de desarrollar una gran parte del software según los requerimientos estándares del mercado y. apoya la evaluación del impacto de los cambios. procesamiento o tránsito . Seguridad La seguridad de software aplica los principios de la seguridad de información al desarrollo de software. Además. a su vez. facilita su gestión y apoya planificaciones realistas .

Diagrama de Clases Un diagrama de clase es el corazón de UML. Aquí tenemos los siguientes niveles de acceso con sus símbolos correspondientes:  Público (+)  Privado (-)  Protegido (#)  Paquete (~)  Derivado (/)  Estático (subrayado) . Las operaciones describen cómo una clase puede interactuar con los datos. Dado que las clases son el bloque de construcción de los objetos. o las interacciones entre clases y objetos. Los componentes de creación de diagramas en un diagrama de clase pueden representar las clases que realmente van a ser programadas.  Sección inferior – Operaciones de la clase (métodos) – Mostrado en formato de lista. Para que la estimación sirva a estos fines debe ser lo suficientemente temprana y precisa.permitiendo que los resultados sean más consistentes con lo planificado. Modificador de acceso de miembro Todas las clases tienen diferentes niveles de acceso dependiendo del modificador de acceso (visibilidad). los diagramas de clase son los bloques de construcción de UML. El diagrama de clase está compuesto de tres partes:  Sección superior – Nombre de la clase – Esta sección siempre es necesaria sin importar si está hablando del clasificador o de un objeto  Sección media – Atributos de la clase – Los atributos describen las variables que describen las cualidades de la clase. cada operación tiene su propia línea. los objetos principales. Esto solamente es necesario al describir una instancia específica de una clase. UML ha sido establecido como un modelo estandarizado para describir un enfoque de programación orientado a objetos. Representa los propósitos fundamentales de UML porque separa los elementos de diseño de la codificación del sistema.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos. fabricantedelcoche) y los métodos de su propia clase (Radio(). Interacciones objeto / clase en los diagramas de clase Las interacciones entre objetos y clases es una parte integral de los diagramas de clase. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas . Hay dos ámbitos para los miembros: clasificadores e instancias. si tenemos el objeto vehículo. el diagrama de secuencia contiene detalles de implementación del escenario. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario. AA/calefacción()). Si está familiarizado con la teoría básica de OO. Los clasificadores son miembros estáticos mientras que las instancias son instancias específicas de la clase. número de pasajeros. limpiaparabrisas(). # de puertas. entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. combustible) y los métodos (moverse(). cambiardedirección()) del padre de clase además de los atributos específicos (tipodemodelo. Herencia Herencia es cuando un objeto hijo asume todas las características de su objeto padre. Por ejemplo.Ámbito del miembro. un hijo de clase Coche heredaría todos los atributos (velocidad. no hay nada innovador. Diagrama de Secuencia Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. La herencia se muestra en un diagrama de clase usando una línea sólida con una flecha cerrada y hueca. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos. detenerse().

y los mensajes pasados entre los objetos como flechas horizontales. Diagrama de Colaboración Un diagrama de colaboración es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. Los elementos juegan en determinados momentos alguno de los dos roles principales proveedores o clientes. Por un lado protege al cliente por especificar cuanto debe ser hecho y por el otro al proveedor por especificar el mínimo servicio aceptable. los . condiciones y bucles. La cooperación establece claramente obligaciones y beneficios. Pueden ser usados en dos formas  De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso). Un contrato entre dos partes protege a ambas. A diferencia de los diagramas de secuencia.discontinuas verticales. Contratos El Diseño por Contratos da una visión de la construcción de sistemas como un conjunto de elementos de software cooperando entre sí. siendo la especificación de estas obligaciones y beneficios los contratos.  Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones ("branches").

Cuando se instancia una comunicación. Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica. Con los métodos. Un uso de un diagrama de colaboración es mostrar la implementación de una operación. mejor: el módulo en cuestión será más sencillo de diseñar. los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. Por otra parte. Podemos . ¿Qué ocurriría con los otros dos? Las clases tendrán alta cohesión cuando se refieran a una única entidad. y volver a hacer el test. Un diagrama de comunicación muestra relaciones entre roles geométricamente y relaciona los mensajes con las relaciones. así como asociaciones más permanentes. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales. la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa. Un test que se suele hacer a los módulos funcionales para ver si son cohesivos es analizar que puedan describirse con una oración simple.diagramas de colaboración. En el diseño orientado a objetos las cosas son más complejas. con un solo verbo activo. Como dijimos. hay tres tipos de módulos: clases. La comunicación muestra los parámetros y las variables locales de la operación. se logra alta cohesión cuando cada módulo (función o procedimiento) realiza una única tarea trabajando sobre una sola estructura de datos. Si hay más de un verbo activo en la descripción del procedimiento o función. En el diseño estructurado. deberíamos analizar su partición en más de un módulo. también llamados diagramas de comunicación. A mayor cohesión. Principios de diseño Cohesión La cohesión tiene que ver con que cada módulo del sistema se refiera a un único proceso o entidad. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales. métodos y paquetes. probar y mantener. Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. un diagrama de comunicación no muestra el tiempo como una dimensión aparte.  Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común. programar. podemos adoptar las mismas definiciones y recetas que para los procedimientos y funciones del diseño estructurado. pero las relaciones son implícitas. pero las secuencias temporales están menos claras. por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes. muestran explícitamente las relaciones de los roles. Dicha implementación es llamada "enlace". Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. tales como argumentos de procedimiento o variables locales del procedimiento. Cuando se implementa el comportamiento.  Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro.

En este caso. Sin embargo. nadie nos impide aplicarle los mismos tests que a las clases. de manera que cuando uno de los objetos cambia su estado. Los patrones de comportamiento describen no solamente estructuras de relación entre objetos o clases sino también esquemas de comunicación entre ellos y se pueden clasificar en función de que trabajen con clases . también habría que tratar de “sustantivarla” y aplicarle la prueba para ver si es cohesiva. Patrones de Diseño Observador Observador (en inglés: Observer) es un patrón de diseño que define una dependencia del tipo uno-a-muchos entre objetos.garantizar una fuerte cohesión disminuyendo al mínimo las responsabilidades de una clase: si una clase tiene muchas responsabilidades probablemente haya que dividirla en dos o más. podemos ayudarnos con un diagrama de paquetes. programar. Decimos que hay dependencia entre paquetes cuando hay clases de un paquete que dependen de clases de otro paquete. que debido a que nos muestra dependencias entre conjuntos de clases. por ejemplo). Si la clase estuviera representando alguna operación (por la aplicación de algún patrón de diseño. que vamos a ver ahora. Sin embargo. Una clase. podemos analizarlos con los mismos criterios que a los módulos del diseño estructurado. Una clase con alta cohesión suele cumplir el principio de única responsabilidad. sea por herencia. Estructurales y de Comportamiento). de mayor a menor: generalización/herencia. como pasó con la cohesión. el diseño orientado a objetos nos complica las cosas con sus tres tipos de módulos. En los paquetes no es usual analizar cohesión. está relacionado con algoritmos de funcionamiento y asignación de responsabilidades a clases y objetos. Para visualizar estas cuestiones. tendrá bajo acoplamiento cuando tenga la menor dependencia posible de otras clases. composición. Las dependencias que importan son. Esta dependencia significa que – si bien puede haber muchas clases que dependen de una – debería haber pocas dependencias hacia otras clases desde una sola. los diagramas de clases son herramientas fundamentales. ¿Y los paquetes? Un paquete debe cumplir con estos mismos requisitos. probar y mantener. mejor: el módulo en cuestión será más sencillo de diseñar. reduciendo la cantidad y complejidad de los parámetros y disminuyendo al mínimo los parámetros por referencia y los efectos colaterales. En el diseño estructurado. es decir. se logra bajo acoplamiento reduciendo las interacciones entre procedimientos y funciones. en el sentido de que debe tener vinculaciones mínimas con otros paquetes. notifica este cambio a todos los dependientes. lo crucial en los paquetes es el acoplamiento. asociación y dependencia débil. asociación o simple dependencia débil. A los métodos. De nuevo. Acoplamiento El acoplamiento mide el grado de relacionamiento de un módulo con los demás. nos sirve para eliminar problemas de acoplamiento. Y el test a aplicar sería ver si podemos describir a la clase con una oración simple que tenga un único sustantivo en el sujeto. Se trata de un patrón de comportamiento (existen de 3 tipos: Creación. A menor acoplamiento. en cambio.

incluso en tiempo de ejecución. sino que podrían incorporar otro tipo de lógica (por ejemplo.. Por otro lado los iteradores no tienen por qué limitarse a recorrer la estructura. Cualquier programa que ofrezca un servicio o función determinada.). que pueda ser realizada de varias maneras. Estrategia. Algunos de los métodos que podemos definir en la interfaz Iterador son: Primero(). Observador. Siguiente(). Es más. se crea una superclase que almacene el comportamiento común y que hará de interfaz hacia las clases concretas.(Método Plantilla) u objetos (Cadena de Responsabilidad. Recuerdo.. . filtrado de elementos). es candidato a utilizar el patrón estrategia. Visitante). recorrido con saltos. Se clasifica como patrón de comportamiento porque determina cómo se debe realizar el intercambio de mensajes entre diferentes objetos para resolver una tarea. define una interfaz que declara los métodos necesarios para acceder secuencialmente a un grupo de objetos de una colección. Dependiendo de la función que se desea realizar con dicha referencia podemos distinguir diferentes tipos de proxies:  proxy remoto: representante local de un objeto remoto. Apoderado El patrón Proxy es un patrón estructural que tiene como propósito proporcionar un subrogado o intermediario de un objeto para controlar su acceso. el patrón de diseño Iterador. Estado. Puede haber cualquier número de estrategias y cualquiera de ellas podrá ser intercambiada por otra en cualquier momento. El patrón estrategia permite mantener un conjunto de algoritmos de entre los cuales el objeto cliente puede elegir aquel que le conviene e intercambiarlo dinámicamente según sus necesidades. HayMas() y ElementoActual(). Además diferentes iteradores pueden presentar diferentes tipos de recorrido sobre la estructura (recorrido de principio a fin. Comando. Estrategia El patrón Estrategia (Strategy) es un patrón de diseño para el desarrollo de software. Iterador En diseño de software. El patrón iterator permite el acceso al contenido de una estructura sin exponer su representación interna. Este patrón de diseño permite recorrer una estructura de datos sin que sea necesario conocer la estructura interna de la misma. Si muchas clases relacionadas se diferencian únicamente por su comportamiento. dados diferentes tipos de estructuras. El patrón proxy se usa cuando se necesita una referencia a un objeto más flexible o sofisticada que un puntero. el patrón iterador permite recorrerlas todas utilizando una interfaz común uniforme. Iterador.

Compuesto El patrón Composite sirve para construir objetos complejos a partir de otros más simples y similares entre sí. pero puede resultar contraproducente cuando se añaden nuevos productos o cambian los existentes. gracias a la composición recursiva y a una estructura en forma de árbol. todos pertenecientes a la misma familia.  proxy de protección: controla el acceso al objeto original (ejemplo de proxy de protección: [1])  proxy de referencia inteligente: sustituto de un puntero que lleva a cabo operaciones adicionales cuando se accede a un objeto (ej. sino otras que la implementan y se asocian a la primera.  proxy virtual: crea objetos costosos bajo demanda (como la clase ImagenProxy en el ejemplo de motivación). Fabrica Abstracta Abstract Factory (Fábrica Abstracta) es un patrón de diseño para el desarrollo de software. El patrón Abstract Factory está aconsejado cuando se prevé la inclusión de nuevas familias de productos. Por ejemplo: las bibliotecas para crear interfaces gráficas suelen utilizar este patrón y cada familia sería un sistema operativo distinto. Esto nos permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad.  Añadir responsabilidades a objetos individuales de forma dinámica y transparente  Responsabilidades de un objeto pueden ser retiradas  Cuando la extensión mediante la herencia no es viable  Hay una necesidad de extender la funcionalidad de una clase. pero no hay razones para extenderlo a través de la herencia.  Existe la necesidad de extender dinámicamente la funcionalidad de un objeto y quizás quitar la funcionalidad extendida. puesto que afectaría a todas las familias creadas. por ejemplo. Decorador El patrón Decorator responde a la necesidad de añadir dinámicamente funcionalidad a un Objeto. control de concurrencia de acceso tal como bloquear el objeto para impedir acceso concurrente). Así pues. . contar número de referencias al objeto real. el usuario declara un Botón. cargar un objeto persistente bajo demanda en memoria. pero de forma más interna lo que está creando es un BotónWindows o un BotónLinux. Contexto: Debemos crear diferentes objetos. El problema que intenta solucionar este patrón es el de crear diferentes familias de objetos.

). ya que al poseer todos ellos una interfaz común. pueden aplicarse procedimientos al total o una de las partes de la estructura compuesta como si de un nodo final se tratara. Un videojuego puede contener diferentes capas "layers" de sprites (como una capa de enemigos) pudiéndose invocar un método que actúe sobre toda esta capa de sprites a la vez (por ejemplo. .Esto simplifica el tratamiento de los objetos creados. para ocultarlos. aunque dicha parte esté compuesta a su vez de muchas otras. se tratan todos de la misma manera. Un claro ejemplo de uso extendido de este patrón se da en los entornos de programación 2D para aplicaciones gráficas. darles un filtro de color etc. Dependiendo de la implementación.

.Los patrones de diseño describen la solución a problemas que se repiten una y otra vez en nuestros sistemas.Los principios de diseño sirven como estándares para hacer software que cumpla con los requerimientos de nuestro cliente. . La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y. para así conocer su reacción y anticipar cualquier imprevisto que se pueda dar al momento de implementarlo.Evaluar un software. Capturan el conocimiento que tienen los expertos a la hora de diseñar y ayudan a generar software “maleable” (software que soporta y facilita el cambio.El uso de diagramas nos permite estudiar las distintas partes que conforman al sistema y cómo interactúan estas. . la reutilización y la mejora). . .La arquitectura de capas nos permite implementar los componentes de una forma más flexible. Para tal fin nos podemos apoyar de los diagramas de clases. solo afectará al nivel requerido sin tener que revisar entre el código fuente de otros módulos. nos permite conocer su comportamiento bajo situaciones de alta demanda. Conclusiones . protocolos e intercambio de señales. en caso de que sobrevenga algún cambio. estructura compuesta y comunicación. de forma que se puede usar esa solución siempre que haga falta. Reflejando las interfaces.

com www. Roger Pressman.sg.com.mx Libros: Ingeniería de Software. 5ta Edición.org www. Bibliografía Páginas web: www.monografias. Ian Somerville. . Ingeniería del Software Un Enfoque Práctico. 9na Edición.wikipedia.