SOLUCIONES EMPRESARIALES

ERP: funciona como un sistema integrado. Toda la empresa, sus sistemas y procesos pueden reunirse bajo un mismo esquema para beneficiar a toda la organización. Los ERP funcionan ampliamente en todo tipo de empresas y su selección depende de factores como el tamaño de la empresa, el tipo de empresa, procesos, recursos,etc.

CARACTERÍSTICAS DE UN ERP: Las empresas que lo implanten suelen tener que modificar alguno de sus procesos para alinearlos con los del sistema ERP. Este proceso se conoce como Re ingeniería de Procesos, aunque no siempre es necesario. Aunque el ERP pueda tener menús modulares configurables según los roles de cada usuario, es un todo. Esto significa: es un único programa con acceso a una base de datos centralizada.

PROPÓSITO DE UN ERP:  El propósito fundamental de un ERP es otorgar apoyo a los clientes del negocio, tiempos rápidos de respuesta a sus problemas, así como un eficiente manejo de información que permita la toma oportuna de decisiones y disminución de los costos totales de operación.

EJEMPLOS DE ERP: 

SAP R/3

SAP Business One

JD Edwards

Microsoft Dynamics GP (antes Great Plains)

Microsoft Dynamics SL (antes Solomon)

Microsoft Dynamics AX (antes Axapta)

CRM: es una estrategia de negocios dirigida a entender, anticipar y responder a las necesidades de los clientes actuales y potenciales de una empresa para poder hacer crecer el valor de la relación.

El CRM consiste en una estrategia de la organización en la cual centra sus esfuerzos en el conocimiento de sus clientes, detectando sus necesidades, aumentando su grado de satisfacción, incrementando su fidelidad a la empresa e incrementando la rentabilidad o beneficios del cliente a la empresa, mediante el análisis de las informaciones extraidas por los clientes desde los diferentes canales o medios de comunicación.

El CRM se refiere a aquellas aplicaciones que las empresas pueden utilizar para administrar todos los aspectos de sus encuentros con los clientes. Un sistema CRM puede incluir todo, desde tecnología para la recolección de datos en las llamadas telefónicas del área de ventas, hasta sitos web de autoservicio donde los clientes pueden aprender acerca de los productos y de su compra, o el análisis de los clientes y los sistemas de administración de campaña.

Existen cuatro aspectos en el CRM, cada uno puede ser implementado por separado:

CRM Activo: una base de datos centralizada para el almacenamiento de datos, que puede ser usada para automatizar procesos de negocios y tareas comunes.

 

CRM Operacional: provee apoyo en los procesos de negocios en los departamentos de Ventas y Marketing, incluyendo ventas, marketing y servicios. Cada interacción con un cliente es generalmente añadida al historial de contactos del cliente, y el personal puede recibir información sobre los clientes de la base de datos cuando es necesario. Enfocarse en sus clientes es fundamental para una estrategia CRM. Los diferentes clientes deben ser tratados de forma diferente.

CRM Colaborativo: Comunicación directa con los clientes que no incluye representantes de ventas o servicios. Esta comunicación puede ser por internet, email, IVR, etc. CRM Colaborativo permite reducir costos y mejoras de servicios.

CRM Analítico: El análisis de los datos de un cliente para múltiples propósitos, especialmente el análisis predictivo. Los propósitos pueden ser: diseño y ejecución de campañas de marketing a determinados nichos, diseño y ejecución de campañas para clientes específicos, análisis del comportamiento de clientes para ayudar en las decisiones sobre productos y servicios, detección de fraudes, etc.

POS:    http://www.webadicto.net/blogs/webadicto/post/2011/01/25/Software-para-Punto-de-Venta-(POS-Point-of-Sale)-Definicion-Conceptos.aspx

RMI:  es un mecanismo ofrecido por Java para invocar un método de manera remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.

RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por CORBA).

A través de RMI, un programa Java puede exportar un objeto, con lo que dicho objeto estará accesible a través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de ese momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto.

La invocación se compone de los siguientes pasos:

• Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java).
• Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta.
• Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.
• El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.

ARQUITECTURA:

La arquitectura RMI puede verse como un modelo de cuatro capas.

Primera capa: La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados, el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al método exportObject() del mismo paquete.

Segunda capa: La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos tienen lugar en esta capa.

Tercera capa:La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de tareas específicas de la implementación con los objetos remotos, como el establecimiento de las persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.

Cuarta Capa: La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP (Java Remote Method Protocol), que solamente es "comprendido" por programas Java.

ELEMENTOS:

Toda aplicación RMI normalmente se descompone en 2 partes:

• Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera a que el cliente los invoque.
• Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.

CORBA: En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.

CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++,Smalltalk, Java, Python, Perl y Tcl.

BPM: Gestión de procesos empresariales (BPM) es una gestión holística enfoque se centró en la alineación de todos los aspectos de una organización con los deseos y necesidades de los clientes.Promueve el negocio de la eficacia y la eficiencia mientras se esfuerza por la innovación , la flexibilidad y la integración con la tecnología. BPM intenta mejorar los procesos de forma continua. Por lo tanto, puede ser descrito como un " proceso de optimización del proceso. "Se argumenta que el BPM permite a las organizaciones a ser mas eficiente, mas eficaz y mas capaz".

BPML: Business Process Modeling Language (BPML) es un lenguaje para el modelado de procesos de negocio . BPML fue una propuesta de lenguaje, pero ahora el BPMI ha abandonado el soporte para esto en favor de BPEL4WS (Business Process Execution Language para Web Services). A partir de 2008, BPML También se ha informado que ha sido descartado en favor de BPDM (Business Process metamodelo Definición ). BPMI tomó esta decisión cuando fue adquirida por la OMG con el fin de tener acceso a su especificación popular, BPMN ( Business Proceso de Modelo y notación ). Esta notación ha sido útil a OMG a fin de enriquecer con la notación UML proceso.

CALIDAD

• Es un conjunto de propiedades asociadas a un objeto que le confieren capacidad para satisfacer necesidades implícitas o explícitas.  
• La calidad de un producto o servicio es la percepción que el cliente tiene del mismo, es una fijación mental  del consumidor que asume conformidad con dicho  producto o servicio y la capacidad del mismo para  satisfacer sus necesidades.
• La calidad significa aportar valor al cliente, esto es, ofrecer unas condiciones de uso del producto o servicio superiores a las que el cliente espera recibir y a un precio accesible.

LA CRISIS DEL SOFTWARE !

• Bajos niveles de productividad

• Demasiados reprocesos

• Sobrecostos

• Tiempo de entrega inoportunos

• Complejidad en el proceso de mejora continua

EL ESTADO DEL DESARROLLO DE SOFTWARE

La mayoría de los proyectos de desarrollo de software fallan.

Qué significa fallar? 

• No cumplir los cronogramas 
• No cumplir el presupuesto 
• No satisfacer la funcionalidad requerida 
• Demasiados defectos una vez en producción
• Demasiado frágil a los cambios 

ASEGURAMIENTO

Son las medidas preventivas que se toman paso a paso durante un proceso para evitar que el resultado final no sea defectuoso.

DOS ENFOQUES DE GESTION EN LOS PROCESOS

• Orquestado

          Bien Diseñado

               Monitoreado 

• Improvisado

          Fruto de la Inspiración 

            Centrado en Héroes 

Sistema de Calidad de Software

• Estándares
• Revisiones 
• Pruebas
• Análisis de defectos
• Administración de la configuración 
• Seguridad 
• Educación
• Administración de contrataciones

DIFERENTES ARQUITECTURAS

La Arquitectura SOA establece un marco de diseño para la integración de aplicaciones independientes de manera que desde la red pueda accederse a sus funcionalidades, las cuales se ofrecen como servicios. La forma más habitual de implementarla es mediante Servicios Web, una tecnología basada en estándares e independiente de la plataforma, con la que SOA puede descomponer aplicaciones monolíticas en un conjunto de servicios e implementar esta funcionalidad en forma modular.

Arquitectura SOA para aplicaciones empresariales

Cuando queremos diseñar una aplicación empresarial podemos adoptar dos estrategias  de desarrollo claramente diferenciadas: diseño orientado a objetos o un diseño orientado a servicios.  Aunque estos paradigmas son en cierto sentido antagónicos, ambos son perfectamente válidos para construir aplicaciones, cada uno con sus ventajas e inconvenientes.

La programación orientada a objetos (POO), consiste en intentar modelar el sistema mediante objetos que representan cosas del mundo real mediante el encapsulamiento de unos datos y un comportamiento relacionados con el dominio del problema que queremos resolver. Estos objetos se conocen como objetos de dominio de la aplicación, que tendrán más o menos complejidad en función de las características del proyecto que estemos desarrollando. Este patrón de diseño es conocido como Domain-Driven Design (DDD).

Una alternativa a DDD es la Arquitectura Orientada a Servicios (SOA). Podríamos decir que la mayoría de las aplicaciones JavaEE que se construyen hoy en día tienen este tipo de arquitectura, que pone el foco en la definición y abstracción de funcionalidades en componentes más sencillos, con interfaces bien definidos, y promueven la separación (desacoplamiento) de las capas específicas de la aplicación.

Beneficios del Software Saas y Cloud Computing

El usuario se despreocupa del mantenimiento:

El usuario, una vez contratado el servicio, no debe preocuparse de actualizaciones ni del mantenimiento de la aplicación. El proveedor se encargará de que se apliquen las mejoras en el servicio. Además, al estar alojado en el servidor del proveedor, él se responsabiliza de la seguridad y de las copias de seguridad de los datos.

Accesible desde cualquier lugar en cualquier momento:

Mientras haya acceso a Internet, ya sea desde el ordenador o móvil, el usuario podrá acceder a su cuenta. Ya que estos servicios online están siempre disponibles, 24 horas al día y 7 días a la semana. No hace falta estar en la oficina para acceder.

No necesita instalación:

No hace falta instalar nada, al contrario de los programas de escritorio, pues el Software SaaS y el Cloud Computing están en la nube. Indistintamente del Sistema Operativo que tenga, solo se necesita un navegador web para conectarse a la aplicación.

Sin inversiones iniciales:

Ahorro en Hardware y Licencias. El sistema de pago se hace mediante alquiler, solo se paga por el uso dado a la aplicación, se comparte el gasto con los demás usuarios. El Software Saas y el Cloud Computing ponen a la disposición del cliente potentes aplicaciones con un gasto mínimo.

Mayor disponibilidad y seguridad de los datos:

Es necesario para una empresa gestionar la seguridad de su red, procedimientos de backup, restore y en general de planes de contigencia en caso de perdida de información o de fallo del hardware, pero es algo que para las empresas puede resultar una tarea pesada y molesta, ya que las amenazas se renuevan continuamente, y es algo que debe de ser constantemente actualizado. La mayoría de la empresas que ofrecen software como servicio ofrece un SLA ( acuerdo nivel del servicio) a medida para cada tipo de empresa.

La empresa centra sus esfuerzos en su negocio

Consiste en externalizar todos los trabajos necesarios para garantizar el correcto funcionamiento diario de su red. Este servicio posibilita optimizar sus proyectos por medio de la gestión externa por parte de personal especializado, hasta el punto de no dedicar esfuerzos en la elección y mantenimiento de los sistemas.

Mantenimiento vía conexión remota ágil y rápida

Los bugs de la aplicación, errores causados por conflictos del software cuando las aplicaciones intentan funcionar en tándem, tienen un tratamiento directo y el cliente cuenta con un servicio rápido y profesional que se dedica a realizar tareas proactivas, administrativas, reactivas, de ajustes y soporte, logrando así obtener el máximo provecho de las soluciones implementadas.

Reducción de costes de mantenimiento

Como antes hemos mencionado, solo se paga por el uso dado a la aplicación, además de pagar por solo aquello que necesites, obtienes un ahorro de costes de mantenimiento de la plataforma de maquinas y del software necesario ( BBDD, Servidor de Aplicaciones) para que tu aplicacion funcione.

ASP

La tecnología ASP está estrechamente relacionada con el modelo tecnológico y de negocio de su fabricante. Intenta ser solución para un modelo de programación rápida ya que "programar en ASP es como programar en Visual Basic y C#", por supuesto con muchas limitaciones y algunas ventajas específicas en entornos web.

Lo interesante de este modelo tecnológico es poder utilizar diversos componentes ya desarrollados como algunos controles ActiveX así como componentes del lado del servidor, tales como CDONTS, por ejemplo, que permite la interacción de los scripts con el servidor SMTP que integra IIS.

Se facilita la programación de sitios web mediante varios objetos integrados, como por ejemplo un objeto de sesión basada en cookies, que mantiene las variables mientras se pasa de página a página.

Es limitado a solo funcionar con IIS, por lo que su uso es cuestionado por la mayoría de los programadores web quienes prefieren otros lenguajes de programación del lado del servidor como por ejemplo PHP, Perl, Java Etc.

ARQUITECTURA CLIENTE - SERVIDOR

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

PSP y TSP

PSP y TSP

PATRON MVC

Modelo Vista Controlador

Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de negocio en tres componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. 

Descripción 

• Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.
• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.
• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente:

1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.)
2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.
3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. Este uso del patrón Observador no es posible en las aplicaciones Web puesto que las clases de la vista están desconectadas del modelo y del controlador. En general el controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. Por ejemplo en el MVC usado por Apple en su framework Cocoa. Suele citarse como Modelo-Interface-Control, una variación del MVC más puro
5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.

 

Patrones

Patrones 




Patrón: Es aquel que describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a ese problema, de forma tal que esa solución puede ser usada un millón de veces, sin hacerlo de la misma manera dos veces.

       Patrones de  Diseño: Son aquellos que representan soluciones a problemas que surgen cuando se desarrolla software en un contexto particular.  Estos, facilitan la reutilización de arquitecturas y diseños de software exitoso. 

         

        Patrones Gof: 

• Creacionales: tratan con las formas de crear instancias de objetos. El objetivo de estos patrones es de abstraer el proceso de instanciación y ocultar los detalles de cómo los objetos son creados o inicializados.
  • Object Pool (Conjunto de Objetos): 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 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.
• Estructurales: Los patrones estructurales describen como las clases y objetos pueden ser combinados para formar grandes estructuras y proporcionar nuevas funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u objetos compuestos.
  • 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.
• Comportamiento: Los patrones de comportamiento ayudan a definir la comunicación e iteración entre los objetos de un sistema. El propósito de este patrón es reducir el acoplamiento entre los objetos.
• 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 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.

Experto en Información: El GRASP de experto en información es el principio básico de asignación de responsabilidades. Nos indica, por ejemplo, que la responsabilidad de la creación de un objeto o la implementación de un método, debe recaer sobre la clase que conoce toda la información necesaria para crearlo. De este modo obtendremos un diseño con mayor cohesión y así la información se mantiene encapsulada (disminución del acoplamiento)

Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?

Solución: Asignar una responsabilidad al experto en información.

Beneficios: Se mantiene el encapsulamiento, los objetos utilizan su propia información para llevar a cabo sus tareas. Se distribuye el comportamiento entre las clases que contienen la información requerida. Son más fáciles de entender y mantener.

Creador: El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación (o instanciación) de nuevos objetos o clases.

La nueva instancia deberá ser creada por la clase que:

• Tiene la información necesaria para realizar la creación del objeto, o
• Usa directamente las instancias creadas del objeto, o
• Almacena o maneja varias instancias de la clase
• Contiene o agrega la clase.

Una de las consecuencias de usar este patron es la visibilidad entre la clase creada y la clase creador. Una ventaja es el bajo acoplamiento, lo cual supone facilidad de mantenimiento y reutilizacion La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos. En consecuencia es útil contar con un principio general para la asignación de las responsabilidades de creación. Si se asignan bien el diseño puede soportar un bajo acoplamiento, mayor claridad, encapsulación y reutilización.

Controlador: El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, de tal forma que es la que recibe los datos del usuario y la que los envía a las distintas clases según el método llamado.

Este patrón sugiere que la lógica de negocios debe estar separada de la capa de presentación, esto para aumentar la reutilización de código y a la vez tener un mayor control.

Se recomienda dividir los eventos del sistema en el mayor número de controladores para poder aumentar la cohesión y disminuir el acoplamiento.

Alta Cohesion y Bajo Acoplamiento: Los conceptos de cohesión y acoplamiento no están íntimamente relacionados, sin embargo se recomienda tener un mayor grado de cohesión con un menor grado de acoplamiento. De esta forma se tiene menor dependencia y se especifican los propósitos de cada objeto en el sistema.

Alta 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 el deber 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”.

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.

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.

cc