The Geek Inside

De las partes más importantes cuándo diseñamos un sistema haciendo uso del paradigma de Orientación a Objetos es el descubrimiento de clases. El uso de técnica de descubrimiento de clases nos ayuda a mitigar riesgos como: tener clases que no representan nada relevante para el sistema, omisión de clases, tener clases con muchas responsabilidades, o clases irresponsables :D, etc.

Existen diferentes técnicas para esta actividad, en este artículo describiré dos de ellas, haciendo hincapié en que no son las únicas, pero si las más usadas. Es importante tratar de usar sólo una técnica durante el desarrollo del sistema para no incurrir en conflictos de clasificación.

Para llevar a cabo el descubrimiento se hace a partir de nuestros documentos de dominio tales como: user stories, use cases, feature list, glosarios, material publicitario, etc. Esta lista de documentos puede diferir dependiendo de la metodología que usemos para el desarrollo del sistema.

Manos a la obra…

Una de las mejores maneras de aprender algo es a través de ejemplos, por lo que para la demostración del uso de ambas técnicas tomaremos como base el siguiente fragmento de un caso de uso en el que resaltaremos los sustantivos en negritas y los verbos en itálicas:

1. El cliente llama por teléfono
2. El operador ofrece al cliente los productos del catálogo.
3. El cliente selecciona uno o varios productos
4. El operador genera la factura con los productos seleccionados
5. El operador le ofrece al cliente opciones de pago

1. Sustantivos, Verbos e inspección gramátical

   En esta técnica se listan los sustantivos descubiertos en los documentos antes mencionados, los verbos que los afectan a estos sustantivos y las relaciones de entre ellos.

   Como podemos observar tenemos las siguientes clases identificadas a partir de los sustantivos

   • Cliente
   • Telefono
   • Operador
   • Producto
   • Catalogo
   • Factura
   • OpcionesPago

   Las siguientes acciones, que son los verbos en infinitivo.

   • llamar
   • ofrecerProductos
   • seleccionarProductos
   • ofrecerOpcionesPago

   y por último las relaciones entre ellos

   • Por cada cliente hay un operador
   • El catálogo consta de varios productos
   • El cliente puede seleccionar uno o mas productos
   • La factura consta de uno a mas productos
   • Existen diferentes formas de pago

2. Clasificación por tipo

   En está técnica se utilizan tablas de tipos con los que clasificaremos los sustantivos, verbos e interacciones encontrados en los documentos de dominio.

   Las siguiente tabla de clasificación es de las más populares:

   Tipo	Clase o acción descubierta
   Cosas tangibles	Teléfono, Producto, Factura
   Roles	Cliente, Operador
   Eventos	Ofrecer productos, Ofrecer formas de pago, …
   Interacciones	Llamar, Seleccionar, …
   Lugares	Oficina matriz, sucursal, …
   Conceptos	Facturar, …
   Sistemas Externos	Sistema de pagos con TDC

Para el modelado de nuestra solución lo podemos hacer con un modelo UML o en su defecto con tarjetas CRC (Class-Responsibility-collaborator), con el apoyo en la información obtenida con cualquiera de las dos técnicas arriba mencionadas.

El modelo se irá refinando mientras se van descubriendo más clases, acciones o interacciones de los documentos de dominio.

Primera versión de la solución en notación UML.

En un árticulo publicado a mediados de Junio en el blog de TextMate, se anuncio un bundle que permite hacer publicaciones de artículos desde este gran editor a varios tipos de Blog engines tales como Wordpress y Typo entre otros.

No había tenido mucho tiempo para experimentar un poco con él, pero el fin de semana pasado por fin jugué un rato con dicho bundle y fué una experiencia muy grata el ver que puedo hacer uso de todas las facilidades de edición de HTML que tiene TextMate para hacer mis publicaciones.

Regularmente uso MarsEdit para publicar artículos en mi blog, sin embargo yo creo que en adelante estaré alternando el uso de este con TextMate ;).

Recientemente me puse el nick en mi cuenta de MSN Messenger “Enterprise Architect Pro”, por lo que algunos de mis colegas me preguntaban cosas como Ya te certificaste?…, a poco ya eres Enterprise Architect?…, y otras mas…

Esto no era más que una broma a un post del buen domix, que por cierto hoy encontré otro post de él mismo, en un sentido similar.

Esto me hace pensar que la muchas personas creen que un arquitecto debe de tener la certificación x, y o z para serlo, o nos convirtiéramos de la noche a la mañana, eso es mentira, sólo debe de cumplir con ciertas características, además se tiene la falsa creencia que los arquitectos deben de saberlo TODO :S, por lo que si tu rol en un proyecto es el de arquitecto, es imperdonable el cometer un error, como si fuesemos entes divinos puros e inmaculados… por supuesto que esto no es verdad, podemos y cometeremos errores como cualquier persona desempeñando cualquier rol.

Para aclarar un poco el asunto comenzaré definir que es un arquitecto… existen algunas definiciones en libros, revistas especializadas y en la web, sin embargo aún no se tiene una “oficialmente aceptada”.

Pero la mayoría coincide en que un arquitecto de software, es alguien que se dedica a definir a alto nivel los diferentes componentes de un software. Toma decisiones en base a los requerimientos funcionales, atributos de calidad y restricciones de dicho sistema, documenta dichas decisiones y se apoya en modelos para tener una mejor comprensión del problema visto generalmente.

El rol del arquitecto no sólo se refiere a temas técnicos, pues debe de tener capacidades de análisis, negociación, liderazgo, manejo de proyectos además de tener la suficiente experiencia para poder recomendar y tomar decisiones.

Cabe señalar que regularmente para llevar a cabo estas tareas nos apoyamos en técnicas y métodos recomendados por instituciones como el SEI ajustándolos a las necesidades del proyecto.

Hace un rato recordé que algunos días atrás en una reunión, algunos colegas y yo estuvimos comentando acerca de nuestros blogs, yo leí un artículo en el blog de Sergio, el cuál me gustó, quise leerlo nuevamente y me dí cuenta que no recordaba la dirección :S. Comencé a querer recordar el nombre del blog… SoftwareArchitect… ArchitectSoftware… no pues no… no lo recordé y empecé a buscarlo en Google… mi búsqueda fue infructífera :(, sin embargo me encontré con algo muy interesante… La definición de Arquitectura de Software en wikipedia en español, lo cual despertó mi curiosidad y entré a leer al artículo, que a decir verdad me decepcionó un poco pues creo que no era la mejor descripción del término. Pero esto me dió la oportunidad de hacer mi primera colaboración en Wikipedia… Aunque sólo fué un comentario, espero poder hacer una colaboración mayor como editar el artículo en un futuro.
Bueno… después de todo encontré una manera más sencilla para saber la dirección del blog… en los links del blog de Beto :D.