Tutorial desarrollado por
Creador y propietario de AdictosAlTrabajo.com, Director General de Autentia S.L., Ingeniero Técnico de Telecomunicaciones y Executive MBA por el Instituto de Empresa 2007. Perfíl Technorati
Experto en formación en: Dirección de proyectos informáticos, análisis y diseño UML, arquitectura Web, patrones de diseño y JEE a todos los niveles.
Puedes consultar mi CV y alguna de mis primeras aplicaciones (de los 90) aquí
Catálogo de servicios de Autentia
Descargar en versión comic (17 MB)
AdictosAlTrabajo.com es el Web de difusión de conocimiento de Autentia.
Descargar este documento en formato PDF: grasp.pdf
Fecha de creación del tutorial: 2003-12-22
Patrones de GRASP
Un proceso de desarrollo sirve para normalizar quien hace que cosa en cada momento y como debe realizarse esta cosa.
En el mundo de las nuevas tecnologías todo avanza muy deprisa por lo que es probable que todavía no hallamos alcanzado un grado de madurez lo suficientemente elevado como para poder normalizar actividades, fundamentalmente porque éstas cambian de semana en semana.
Normalizando un proceso de desarrollo de software, lo que queremos ganar (porque cuando hacemos algo normalmente es por ganar algo) pueden ser distintas cosas:
- Capacidad de predecir el coste futuro de la ejecución del siguiente proyecto
- Evitar riesgos con tareas no planificadas.
- Eliminar dependencias a personas por producir piezas de un modo estandarizado y documentado.
- Aumentar la confianza en los sistemas desarrollados y reducir sus errores.
- Favorecer la reutilización de piezas (con la consiguiente reducción de costes)
- y muchas cosas más ....
Uno de los procesos más reconocidos, es el denominado Proceso Unificado de Jacobson, Booch y Rumbaugh.
Este proceso se dice que es "dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental". Si recurrimos al libro (ISBN 0-201-57169-2, El proceso unificado de desarrollo de software), me parece francamente bueno pero ..... siempre hay un pero ..... para realizar correctamente la ejecución de un proyecto, es necesario complementarlo con otras fuentes. Si esta centrado en la arquitectura, esta debe ser lo más robusta posible por lo que debemos profundizar en este punto.
Existe otro libro, llamado UML y Patrones (Craig Larman, ISBN-84-205-3438-2) que nos puede ayudar en la primera fase del diseño, la identificación de las clases en base a su responsabilidad). Es una obra muy buena pero puede ser un poco densa para usuarios principiantes ..... aunque la primera mitad no tiene desperdicio.
Para comprender bien el libro anterior y que nuestros diseños sean completos, nos hacen falta unos cuantos libros más sobre patrones de diseño (Coad, GoF, etc.) que, por suerte, podemos hasta encontrar, de algunos de ellos, su versión electrónica en Internet (Thinking in Patterns, Design Patterns, Core J2EE patterns) y, aunque profundizaremos en otros tutoriales en el uso de estos patrones, comprobareis que no pueden vivir unos sin los otros .... e incluso, en algunos casos se pueden decir que son los mismos ...... descritos en otro ámbito.
Un patrón es una descripción de un problema bien conocido que suele incluir:
- Descripción
- Escenario de Uso
- Solución concreta
- La consecuencias de utilizar este patrón
- Ejemplos de implementación
- Lista de patrones relacionados
Patrones hay muchos (muchas familias) ... de momento vamos a ver como nos pueden ayudar los primeros (GRASP).
GRASP es el acrónimo de General Responsibility Assignment Software Patterns. Una de las cosas más complicadas en Orientación a Objeto consiste en elegir las clases adecuadas y decidir como estas clases deben interactuar. Incluso cuando utilizamos metodologías rápidas como programación extrema (extreme programming) y centramos el proceso en el desarrollo continuo, es inevitable elegir cuidadosamente las responsabilidades de cada clase en la primera codificación y, fundamentalmente, en la refactorización (continual) de nuestro programa.
En su obra, Larman intenta definir un enfoque sistemático a la creación de clases y métodos.
Para obtener más información sobre el primer autor que ha documentado los patrones de GRASP (y entrar en depresión por la cantidad de cosas que nos queda a todos por aprender) poder visitar su Web (Craig Larman).
Lo patrones de GRASP, no compiten con los patrones de diseño..... los patrones de GRASP, nos guían para ayudarnos a encontrar los patrones de diseño (que son más concretos).....
Vamos a ver el catálogo de patrones y algunas recomendaciones (como muchas son de mi cosecha, podéis escribirme para aportar críticas constructivas):
| Patrón | Descripción |
|---|---|
|
Bajo Acoplamiento |
Debe haber pocas dependencias entre las clases. Si todas las clases
dependen de todas ¿cuanto software podemos extraer de un modo
independiente y reutilizarlo en otro proyecto?.
Para determinar el nivel de acoplamiento de clases, son muy buenos los diagramas de colaboración de UML. -------------- Uno de los principales síntomas de un mal diseño y alto acoplamiento es una herencia muy profunda. Siempre hay que considerar las ventajas de la delegación respecto de la herencia. Como ejemplo (de mal diseño), en muchos diseños Web se puede ver como se crea un servlet base con capacidades de paginación y se hereda de él para construir los demás. La paginación es un servicio que se podría usar en aplicaciones no Web, por lo que es más adecuado mantener estas capacidades en clases externas. Otro ejemplo clásico se produce cuando se pasan los objetos relacionados con la capa de presentación a la capa de negocio (HttpRequest, HttpResponse). |
|
Alta Cohesión |
Cada elemento de nuestro diseño debe realizar una labor única dentro
del sistema, no desempeñada por el resto de los elementos y
auto-identificable. --------------- Ejemplos de una baja cohesión son clases que hacen demasiadas cosas. En todas las metodologías se considera la refactorización. Uno de los elemento a refactorizar son las clases saturadas de métodos. Ejemplos de buen diseño se producen cuando se crean los denominados "paquetes de servicio" o clases agrupadas por funcionalidades que son fácilmente reutilizables (bién por uso directo o por herencia). ---------------- En java, pensar en interfaces nos fuerza a que nuestros sistemas sigan los principios de alta cohesión. En algún sitio leí que una aplicación con menos de 8 interfaces no utiliza correctamente los conceptos de orientación a objeto ... y estoy de acuerdo .... |
|
Experto |
La responsabilidad de realizar una labor es de la clase que tiene o puede tener los datos involucrados (atributos) . Una clase, contiene toda la información necesaria para realizar la labor que tiene encomendada. ------------ Hay que tener en cuenta que esto es aplicable mientras estemos considerando los mismos aspectos del sistema:
No tiene sentido considerar que una clase se debe escribir a si misma en base de datos o formatearse para presentarse en una página HTML por el hecho de poseer los datos. Estos son elementos estructuralmente distintos y deben considerarse desde una perspectiva distinta. |
|
Creador |
Se asigna la responsabilidad de que una clase B cree un Objeto de la clase A solamente cuando
-------------- El hecho de crear objetos tiene casuísticas particulares:
Estos casos son candidatos para la utilización de otros patrones más concretos (de diseño). ------------ A la hora de crear objetos en distintos lenguajes hay que tener en cuenta sus peculiaridades. En Java por ejemplo:
|
|
Controlador |
Asignar la responsabilidad de
controlar el flujo de eventos del sistema, a clases específicas. Esto facilita la
centralización de actividades (validaciones, seguridad, etc.) . El
controlador no realiza estas actividades, las delega en otras clases con
las que mantiene un modelo de alta cohesión. Un error muy común es asignarle demasiada responsabilidad y alto nivel de acoplamiento con el resto de los componentes del sistema. --------------------- En UP (proceso unificado), al construir el modelo de análisis, existen estereotipos predefinidos que favorecen la separación de entidades, mecanismos de interfaz y mecanismos de control. --------------------- En aplicaciones Web, se tiende a separación de la lógica de presentación y de la lógica de negocio. Patrones bién conocidos como MVC o Fachada, son de amplia utilización.. Hay otros muchos patrones relacionados sobre todo en entornos multi-capa (Core J2EE patterns). -------------------- En el diseño de clases de negocio, cuando no tenemos claro a qué clase pertenece la responsabilidad de realizar una determinada tarea, crear una clase controlador que se llame igual a la tarea a desempeñar. |
|
Polimorfismo |
Cuando identificamos variaciones en un comportamiento, asignar la
clase (interfaz) al comportamiento y utilizar polimorfismo para
implementar los comportamientos alternativos. -------------------- El implementar comportamiento alternativos con sentencias IF-ELSE, no hace más que limitar la reutilización y crecimiento de la aplicación. Imagine que una aplicación muestra mensajes distintos en distintos idiomas.... con IF, al aumentar en uno el número de idiomas, nos obligaría a añadir un nuevo IF. Con polimorfismo nos limitaríamos a crear un objeto de una clase polimórfica nueva (bajo acoplamiento, alta cohesión y potencial reutilización). |
|
Fabricación Pura |
Cuando los problemas se complican, construir clases que se encarguen
de construir los objetos adecuados en cada momento (factorías) . --------------- Todo proyecto tiene numerosa factorías potenciales, para intercambiar fácilmente comportamientos:
|
|
Indirección |
Crear clases intermedias para desacoplar clientes de servicio y
servicios. ----------------- Pensar en sistemas middleware y se verá la utilidad de un modo inmediato. |
|
No hables con extraños |
Un método, solamente invocará a métodos de:
-------------------- Un fallo común en la construcción de sistemas Web en la utilización de variables globales (estáticas) o el acceso desde muchos puntos desordenadamente a variables de sesión o aplicación (contexto). |
Aunque pueden parecer muy evidentes los principios anteriormente enumerados, estaréis de acuerdo conmigo que es muy complicado llevarlo a cabo en proyectos reales. Hay varios factores que lo hace difícil:
- La presión del día a día por producir resultados (aunque sean de poca calidad).
- La planificación de proyectos a coste fijo (y a precios bajos) que quita las ganas de pararse a pensar (más con 50 horas semanales de trabajo)
- La poca inversión en formación de muchas empresas (modelo de servicios puro, propiciado los últimos años)
- Falta de personas de referencia (que nos enseñen y aprendamos juntos) en los equipos de desarrollo.
Aunque personalmente y siendo positivo, yo que me dedico ahora a la formación, estoy viendo claramente un interés creciente por los responsables de equipos en mejorar el conocimiento y la calidad del producto.... posiblemente motivado por demandas del cliente ( :-( ).
Por cierto (y aunque no tenga demasiado que ver )... visitando el Web de Peter Coad, he visto una cosa (simple y de gran utilidad) que nos puede ayudar a identificar visualmente la necesidad de aplicar algunos de los patrones anteriores ..... la justificación (a través de uno de sus libros) de por qué es conveniente la utilización de colores para la creación de modelos UML (a mi me ha convencido a la primera).
http://pcoad.com/download/bookpdfs/jmcuch01.pdf
A medida que se profundiza en el conocimiento .... crece la sensación de no tenerlo ......... pero no os preocupéis ........ creo que le pasa a toda la humanidad.
Anímate y coméntanos lo que pienses sobre este tutorial
Puedes opinar o comentar cualquier sugerencia que quieras comunicarnos sobre este tutorial; con tu ayuda, podemos ofrecerte un mejor servicio.
| Autor | Mensaje de usuario registrado |
|---|
| Autor | Mensaje de usuario anónimo |
|---|---|
| JJ |
Fecha de envío: 2006-04-05 - 11:37:20 AM Muy interesante vuestra web. Volveré... |
- Puedes inscribirte en nuestro servicio de notificaciones haciendo clic aquí.
- Puedes firmar en nuestro libro de visitas haciendo clic aquí.
- Puedes asociarte al grupo AdictosAlTrabajo en XING haciendo clic aquí.
- Añadir a favoritos Technorati.
Esta obra está licenciada bajo licencia Creative Commons de
Reconocimiento-No comercial-Sin obras derivadas 2.5
Recuerda
Autentia te regala la mayoría del conocimiento aquí compartido (Ver todos los tutoriales). Somos expertos en: J2EE, Struts, JSF, C++, OOP, UML, UP, Patrones de diseño ... y muchas otras cosas.
¿Nos vas a tener en cuenta cuando necesites consultoría o formación en tu empresa?, ¿Vas a ser tan generoso con nosotros como lo tratamos de ser con vosotros?
Somos pocos, somos buenos, estamos motivados y nos gusta lo que hacemos ...
Autentia = Soporte a Desarrollo & Formación.
Tutoriales recomendados
| Nombre | Resumen | Visitas | Valoración | Votos | ||
|---|---|---|---|---|---|---|
| Patrón Visitor con commons-collections y sus Closures | En este tutorial vamos a ver cómo podemos usar la librería de Apache commons-collections para implementar de forma sencilla un Visitor que se recorra todos los elementos de una colección. | 2010-01-14 | 439 | - | - |  |
| Instalar OpenESB 2.1 e Introducción | En este tutorial veremos como descargar e instalar OpenESB y explicaremos sus funcionalidades | 2009-12-03 | 1703 | - | - | |
| Cómo conseguir que Subversion avise a Hudson para lanzar una build | En este tutorial vamos a ver como configurar Subversion para que sea este el que avise a Hudson cada vez que hay un commit, y así se lance la build. | 2009-10-27 | 2265 | - | - | |
| Cómo instalar Hudson en Apache Tomcat | Instalar Hudson en Apache Tomcat | 2009-10-26 | 2610 | Muy bueno | 1 | |
| Introducción a los diagramas EPC (Event-Driven Process Chain) | En este tutorial veremos en que consisten los diagramas EPC, o Event-driven Process Chain. | 2009-08-13 | 3616 | - | - | |
| AgileDraw: una técnica rápida de modelado | AgileDraw, más que una herramienta, se trata de una técnica de modelado rápido | 2009-04-26 | 2986 | - | - | |
| Modelos de conocimiento con CmapTools | Roberto nos enseña en este tutorial el uso de la herramienta CmapTools | 2009-04-20 | 3760 | - | - | |
| Iniciación a OSWorkflow con Spring | En este tutorial vamos a presentar uno de los motores de workflow, "OSWorkflow" y su integración con Spring. | 2009-04-15 | 3272 | Bueno | 1 | |
| Persistencia con Spring | En el siquiente tutorial vamos a ver algunas de las aportaciones que nos ofrece Spring para mejorar la capa de persistencia de nuestras aplicaciones | 2009-03-04 | 4978 | Bueno | 1 | |
| Modelado BPMN con Bizagi Modeler | En ésta ocasión, nuestro compañero Roberto os enseña una herramienta muy útil de modelado BPMN, llamada Bizagi Modeler | 2008-12-10 | 8390 | - | - | |
Nota:
Los tutoriales mostrados en este Web tienen como objetivo la difusión del conocimiento.
Los contenidos y comentarios de los tutoriales son responsabilidad de sus respectivos autores.
En algún caso se puede hacer referencia a marcas o nombres cuya propiedad y derechos es de sus respectivos dueños. Si algún afectado desea que incorporemos alguna reseña específica, no tiene más que solicitarlo.
Si alguien encuentra algún problema con la información publicada en este Web, rogamos que informe al administrador rcanales@adictosaltrabajo.com para su resolución.
