Archive for the 'ingeniería de software' Category

02
Oct
13

MVC – Model View Controller (Patrón de diseño)

MVC es un patrón de diseño, que se ubica en la categoría de patrones arquitectónicos; este patrón se especifica bajo la proposición de dividir la aplicación en tres tipos de elementos, el modelo, las vistas (GUIs) y controladores. Estos elementos están separados por límites abstractos lo que convierte a MVC más paradigma que patrón, ya que la comunicación entre sí a través de esos límites no se especifica más. La manera en que los elementos dentro de MVC se comunican difieren y no sólo lo diferencia el tipo de aplicación que se está describiendo (Desktop, WEB),  sino también por la parte de la aplicación que actualmente está mirando (frontend, backend).

MVC

MVC

Sin embargo, en el centro de cada arquitectura MVC se encuentran presentaciones separadas lo que declara una división especifica entre los objetos de dominio que modelan nuestra percepción del mundo real (modelo de objetos), y la presentación de dichos objetos que son los elementos de la GUI que vemos en la pantalla (objetos de vista).

MVC define la separación de estos tres tipos de elementos:

  1. Modelo: elementos (objetos) que contienen los datos y definen la lógica para manipular dichos datos. A menudo los objetos tienen una naturaleza reutilizable, distribuida, persistente y portátil para una variedad de plataformas.
  2. Vista: hace referencia a los elementos que representan algo visible en la interfaz de usuario, por ejemplo, un panel o botones. Con el fin de mostrar datos de los objetos de modelo es posible que desee crear sus propios objetos personalizados, como un gráfico, por ejemplo.
  3. Controlador: actúa como un mediador entre los objetos del modelo y la vista . Un objeto Controller comunica datos de ida y vuelta entre los objetos del modelo y de la vista. Un controlador también realiza todas las tareas específicas de la aplicación, tales como la entrada del usuario o la carga de procesamiento de datos de configuración. Por lo general un se puede ver un controlador por aplicación o ventana, en muchas aplicaciones, el controlador está estrechamente acoplado a la vista. Dado que los controladores son específicos de aplicaciones por lo general es muy difícil encontrar reutilización en otras aplicaciones.

Diseño de una aplicación estrictamente de acuerdo con MVC no es siempre recomendable. Si está diseñando un programa intensivo de gráficos, probablemente tendremos muy pocas vistas y clases de modelo mucho más de lo que sugiere MVC. y al programar una aplicación muy simple es común combinar el controlador con las clases de vista. por otro lado el paradigma MVC no es necesariamente específico para lenguajes de programación orientados a objetos. Por ejemplo, una aplicación escrita en PHP no siendo orientada a objetos, también puede seguir los principios del patrón Modelo Vista Controlador utilizando sistemas de plantillas o marcos MVC diseñado para PHP.

El campo de aplicación de este patrón es bastante amplio casi se puede utilizar en cada aplicación. por supuesto dependiendo de la aplicación puede que algunas clases deben acoplarse a otras más que en otras aplicaciones, sin embargo, en general, siempre es una buena idea estructurar la aplicación en orden a MVC.

El patrón MVC en su implementación embebe diferentes patrones dependiendo de la  naturaleza de la aplicación que se está diseñando. Es común encontrar cosas como Intercepting Filters, View Helpers, Composite Views, Front Controllers, Value Objects, Session facades, Business Delegates y Data Access Objects que son utilizados por el patrón de arquitectura MVC, dentro de las cuales podemos resaltar:

Observer: este patrón es usado entre el Modelo y la Vista. Cuando los datos que están almacenados en los objetos del modelo sufren cambios, los objetos de la vista tienen que ser notificados y/o actualizados con respecto a la información con los cambios más reciente. Con el fin de mantener el acoplamiento entre los componentes Modelo/Vista y también debido al hecho de no tener varias instancias de objetos Vistas, el patrón Observer es el candidato ideal para lograr esto.

Estrategy: frecuente mente se implementa a nivel de modelo. El patrón DAO (Data Acces Object) es una forma del patrón de Estrategy que es utilizado  sobre todo por el modelo para acceder a diferentes formas de fuentes de datos. Por ejemplo, una base de datos MySQL/PostgreSQL, o archivos XML  almacenados en el disco.

Composite: utilizado por la Vista. No puede existir diferentes tipos de vistas dentro de un sistema diseñado de acuerdo con MVC, y alineandose a la finalidad de que todas las implementaciones sean compuestas y cambiadas a petición en tiempo de ejecución, se utiliza el patrón de Composite.

EJEMPLO DEL PATRÓN MVC EN JSP 

Ejemplo MVC en JSP

Ejemplo MVC en JSP

Referencias

Applications Programming in Smalltalk-80(TM)

Modelo Vista Controlador[Wikipedia]

The Ohio State University Software Development in Java Course 2009[Lecture 23]

Seminar Software Entwurf – Leif Singer

Designing Enterprise Applications with the J2EE Platform

Pattern Concepts – Oracle

16
Sep
13

Patrones Arquitectónicos

Los patrones arquitectónicos se utilizan para expresar una estructura de organización base o esquema para un  software. Proporcionando un conjunto de sub-sistemas predefinidos, especificando sus responsabilidades, reglas, directrices que determinan la organización, comunicación, interacción y relaciones entre ellos.

Los patrones arquitectónicos heredan mucha de la terminología y conceptos de patrones de diseño, pero se centran en proporcionar modelos y métodos re-utilizables específicamente  para la arquitectura general de los sistemas de información. En otras palabras quiere decir que a diferencia de los patrones de diseño estas son plantillas incompletas y no se pueden aplicar directamente al código con modificaciones meramente contextuales. Los patrones arquitectónicos a su vez se salen del código puro de la aplicación y suben e incluyen software, hardware, redes, inclusos las personas.

Dentro de los patrones arquitectónicos podemos encontrar:

  • Modelo Vista Controlador: es uno de los modelos más antiguos (Smalltalk-80)  y por lo tanto se convirtió en uno de los patrones fundamentales para el desarrollo de software. MVC a grandes trazos, separa las preocupaciones con respecto a los datos (modelo) y la interfaz de usuario (vista/GUI), permitiendo modificaciones independientes en cada una  las partes sin afectar la otra, o sea, para que los cambios realizados en la interfaz de usuario (GUI) no afectan el manejo de datos, y los datos pueden ser reorganizados sin cambiar la interfaz de usuario.
  • Inyección de Dependencias: es un patrón que a pesar de ser relativamente nuevo es muy complejo. La utilización de inyección de dependencia en un proyecto es tan incidente, que puede modificar en grandes proporciones la arquitectura, de modo que se hace prudente una planificación a futuro sobre la utilización de este patrón. Este patrón puede dar la impresión de ir un poco “al revés”, porque el mismo, se trata de una aplicación de la “Inversión de Control – IoC”, concepto que hace exactamente eso, se invierte el flujo de control. El nombre de “la inyección de dependencia” en realidad se presta a confusión, ya que el modelo permite que se inyecte no dependencias en sí, sino en su lugar, la información para satisfacerlas la relación a las dependencias.
  • Arquitectura dirigida por eventos (Event-driven architecture o EDA): es un patrón de arquitectura software que para orquestar su comportamiento se centra en torno a la producción, detección, consumo y respuestas ante “eventos”. Teniendo en cuenta que un evento es: cualquier ocurrencia identificable que tiene un significado para el hardware o el software del sistema, en otras palabras, cualquier cambio de estado significante para el sistema. Y a su vez este cambio de estado puede ser conocido por otras aplicaciones en la arquitectura, o sea, que cada evento se propaga de manera inmediata a otras partes del sistema en la medida que sea necesario.
  • Arquitectura orientada a servicios: La ‘Arquitectura Orientada a Servicios de cliente’ (Service Oriented Architecture), es un concepto de arquitectura de software donde el software consta de una composición de servicios, prestaciones y reglas, y son los requisitos del negocio los que dictaminan la manera en la que estas se ínter-relaciona. Esta diseñado para que el sistema sea altamente escalable y flexible a nuevos requerimientos.

Referencias

http://www.omg.org/soa/Uploaded%20Docs/EDA/bda2-2-06cc.pdf

http://searchsoa.techtarget.com/definition/event-driven-architecture

http://download.boulder.ibm.com/ibmdl/pub/software/dw/webservices/ws-soa-whitepaper.pdf

http://download.microsoft.com/download/e/9/d/e9d163db-5c96-46bc-9263-aac62fc38831/Service%20Oriented%20Architecture.pdf

09
May
13

Interface (Patrón de diseño)

Una interfaz se define como una “Conexión física y funcional entre dos aparatos o sistemas independientes” [Rae 2013], esta describe las operaciones (la cara al mundo) que una entidad puede realizar, de igual manera establece los limites, niveles de acceso y la manera en que se desarrolla la comunicación entre dos entidades, para nuestro caso caso dos piezas de software. Por lo general, se refiere a una abstracción que proporciona un activo de sí mismo a la parte exterior.

 

La idea principal de una interfaz es separar las funciones (firma de métodos) de las implementaciones (cuerpo del método) . Cualquier solicitud que coincida con la firma de la interfaz de un objeto también puede ser enviada a ese objeto, independientemente de su aplicación. Restando importancia a cual clase realiza la implementación y responda el llamado ya que el llamado se hace sobre la interfaz, brindando la capacidad de poder intercambiar fácilmente la clase que implementa la interfaz sin modificar el código donde se hace el llamado a dicha interfaz.

 

 

El concepto de una interfaz es fundamental en la mayoría de los lenguajes de programación orientados a objetos. En algunos, los objetos son conocidos sólo a través de sus interfaces de modo que no hay manera de acceder a un objeto sin tener que ir a través de su interfaz.

 

Los usos más comunes para las interfaces son:

  • Deseamos describir la el protocolo de comunicación de una clase fuera de su paquete.
  • Se debe cambiar la implementación de una funcionalidad en tiempo de ejecución.
  • Durante el diseño desconocemos cual será la implementación que se usará en tiempo de compilación.

 
Interfaces.java

package ingenio.ds.examples.patrones;

/*definición de la interfaz mensajero*/
interface Mensajero{
	/*definición del método enviar*/
	public void enviar(String titulo,String mensaje);
}

Clases.java

package ingenio.ds.examples.patrones;
import javax.swing.JOptionPane;

class Consola implements Mensajero{
	public void enviar(String titulo,String mensaje){
		System.out.println("Log : "+mensaje);
	}
}

class Popup implements Mensajero{
	public void enviar(String titulo,String mensaje){
		JOptionPane.showMessageDialog(null,
									 mensaje,
									 titulo,
									 JOptionPane.INFORMATION_MESSAGE);
	}
}

Main.java

package ingenio.ds.examples.patrones;

public class Main {
	/*describe el tipo de mensaje que usaremos*/
	public static String TIPO_MENSAJE="CONSOLA";
	public static void main(String argumentos[]){
		/*en este punto no conocemos la implementación que se usará para enviar el mensaje*/
		Mensajero mensajero=getMensajero();
		/*llamamos el método enviar */
		mensajero.enviar("Hola","Iniciar envio de mensaje");
		mensajero=getMensajero();
		mensajero.enviar("Hola","Patrón interface");
		mensajero=getMensajero();
		mensajero.enviar("Hola","Cerrar envio de mensaje");
	}

	public static Mensajero getMensajero(){
		/*dependiendo del 'contexto' retornará el mensajero necesario*/
		Mensajero mensajero=null;
		if(TIPO_MENSAJE=="CONSOLA"){
			mensajero=new Consola();
			TIPO_MENSAJE="POPUP";
		}else{
			mensajero=new Popup();
			TIPO_MENSAJE="CONSOLA";
		}
		return mensajero;
	}
}
07
May
13

Patrones Fundamentales

Son uno de los tipos de patrones de diseño. Se denominan fundamental, ya que contemplan funcionalidades básicas para los otros patrones, la mayoría de los las aplicaciones de los demás patrones se diseñan utilizando como base estos patrones de una manera u otra.

Algunos de los patrones fundamentales son trasladados a otras categorías: Proxy, Facade, Composite son ejemplo de ello. Mientras otros son incluidos dentro de las características propias de los lenguajes de programación por ejemplo la Collection en Java tiene varias implementaciones del patrón Container, a su vez el patrón Interface siempre ha estado vinculado a la Java desde su nacimiento. Se hace importante mantener la referencia de lo que en algún momento se reconoció como un patrón de diseño.

Interface: es un tipo especial de clase que le brinda al programador una manera más sencilla y específica de acceder a los atributos o funcionalidades de otras clases (entendiendo por interface como la cara accesible de una clase). En Java la implementación de este patrón es implícita en el uso del lenguaje, ya que sin “necesidad” de especificarlo el lenguaje se basa en sus interfaces para exponer la funcionalidad de una clase con el mundo exterior, y esto es una parte fundamental del lenguaje. A diferencia de C++, que tiene los archivos de cabecera para poder presentar la interfaz de una clase al exterior.

Container: es un objeto que nos permite agrupar múltiples elementos en una sola unidad, y al mismo tiempo brindando funcionalidades que nos permitan almacenar, recuperar, manipular, eliminar y comunicarnos con los datos agregados.  en Java contamos con la Java Collection Framework que es una arquitectura unificada para representar y manipular colecciones. Todos los frameworks de colecciones  contienen interfaces, implementaciones y algoritmos.

Delegation: este patrón permite la extensión de la funcionalidad de una clase a través de el uso de una clase contenedora que almacena a la clase original,así proporcionar las funcionalidades de la clase contenida a través del contenedor. Algunos autores lo describen como “Herencia realizada manualmente”   permitiendo a lenguajes como Java (que solo permiten herencia simple) simular la figura de herencia múltiple.

07
May
13

Patrones de diseño

En la ingeniería de software frecuentemente nos encontramos con problemas a nivel de desarrollo, que tal vez son escalado de una de las etapas anteriores. Muchos de estos problemas ya han sido solucionados en estrategias que gracias a su capacidad de implementarse en diferentes sistemas se convierten en patrones. Estos patrones los podemos definir como: “Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.” (¿Qué es un Patrón de Diseño?);     de igual manera los podemos definir como: modelo de objeto re-utilizable que ha sido útil en más de un contexto practico, brindando una solución a un problema en común.

En otras palabras los patrones son modelos que ha solucionado un problema en diferentes sistemas entonces se estandariza y brinda la posibilidad de replicar el mismo modelo para solucionar dicho problema en otro sistema independiente al contexto de este; se utiliza la palabra modelo ya que no todos los patrones son fácilmente adaptables a código. En los patrones se describe una plantilla (esqueleto) para resolver el problema, la destreza del programador tiene un papel fundamental para determinar el cuando y el como utilizarlos, ademas que ningún patrón es la piedra angular (no debes siempre utilizar el mismo) al momento de solucionar un problema, ya que en la practica un solo sistema puede utilizar varios patrones.

Para poder entender e implementar patrones en su plena concepción se debe tener claro que es programación orientada a objetos y cuales son sus principales propiedades: clase, objeto, método, paso de mensajes, herencia, encapsulamiento, polimorfismo y abstracción (aquí algunas).

Los patrones de diseño se clasifican en cinco categorías:

  1. Fundamentales: estos son utilizados en otros patrones para cumplir con el propósito establecido.
      1. Interface
      2. Container
      3. Delegation

     

  2. Arquitectónicos: estos patrones expresan una organización fundamental de la estructura del sistema, de igual manera proporcionan un conjunto de subsistemas especificando sus responsabilidades, reglas, directrices y relaciones entre ellos.
    1. Modelo Vista Controlador (MVC)
    2. Inyección de Dependencias

     

  3. Estructurales: describen como las clases y objetos se relacionan entre sí para trabajar entre ellos.
    1. Facade
    2. Decorator
    3. Proxy
    4. Data Access Object
    5. Transfer Object
    6. Composite
    7. Adapter

     

  4. de Creación: Ellos ayudan a hacer un sistema independiente de cómo se crean los objetos, que clases puedo instancias o sobre que objetos delego dicha responsabilidad.
    1. Factory Method
    2. Abstract Factory
    3. Object Pool
    4. Singleton
    5. Builder

     

  5. de Comportamiento: Se relacionan con los algoritmos y la asignación de responsabilidades entre los objetos, organización, nos permiten definir la comunicación entre los objetos y la manera en la que fluye la información entre ellos..
    1. Iterator
    2. Observer
    3. Event Listener
    4. Strategy
    5. Chain of Responsability
    6. Command
    7. Interpreter
    8. Mediator
    9. Memento
    10. State
    11. Visitor
    12. Template Method

Los patrones no son reglas estrictas son guías aplicables a nuestros desarrollos, incluso no siempre han sido bien recibidos por las comunidades académicas  recibiendo fuertes criticas, Estos nacen como el esfuerzo pos estandarizar lo que ya conocemos como mejores practicas, y muchas veces la implementación de patrones se desencadena en una duplicación innecesaria de código, para brindar una solución a un problema que en realidad pudo ser resulto por una restructuración del código y “Peter Norvig ofrece un argumento similar. Él demuestra que 16 de los 23 patrones en el libro Patrones de diseño (que se centra principalmente en C++) se han simplificado o eliminado (a través de apoyo lenguaje directo) en Lisp o Dylan”.

Referencias




I+Ds

Dudas consultas
Facebook
Twiter
Google +

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevas publicaciones por correo.

Únete a otros 348 seguidores

Redes Sociales y Archivos

Entradas

junio 2017
L M X J V S D
« Abr    
 1234
567891011
12131415161718
19202122232425
2627282930  

IngenioDS en twiter


A %d blogueros les gusta esto: