Cómo representar los Genéricos en UML

Autor: Carlos M. Macías Medina
Alias: Charlie Macías (México)
Nivel: Intermedio

Los Genéricos o Generics es una construcción soportada por algunos lenguajes de programación orientados a objetos que nos permite escribir código en función de tipos que serán especificados más tarde, mismos que serán instanciados cuando se les necesite como tipos específicos ya sea provistos como parámetros o devueltos como tipos de retorno en una operación o método.

En el caso particular de Java y C#, el soporte a estas construcciones fueron incorporadas en las versiones 1.5 (5.0 comercialmente hablando) y 2.0 respectivamente.

Los siguientes fragmentos de código ejemplifica la definición y uso de los Genéricos.

public abstract class DAO<E> {
public List<E> recuperar(E entidad) {…}
public E persistir(E entidad) {…}

…
}

Fragmento 1: Definición de la clase genérica

public static void main(String[] args) {
Persistor<Autor> p = new AutorDAO();
List<Autor> autores = p.recuperar(new Autor());
}

Fragmento 2: Uso de la clase genérica

En la definición de la clase genérica podemos observar la declaración del tipo genérico “E”. El cual es sustituido por el tipo específico “Autor” en el fragmento 2.

A continuación se muestra a la representación, en UML, de la clase genérica “DAO”.

Figura 1: Representación de la clase genérica DAO en UML

Como podemos observar, en UML, una clase genérica se modela como una clase parametrizada, siendo el tipo genérico definido un parámetro de la clase.

Administración de Riesgos en los Requerimientos

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Categoría: Reflexión

En diciembre pasado tuve la fortuna de recibir una invitación por parte de nuestros amigos de Líder de Proyecto para participar en uno de sus famosos Video Boletines mismo que anexo en esta entrada. En esa ocasión abordé el tema de la administración de los riesgos asociados a la administración de los requerimientos con base en el Taxonomy Based Questionnaire.

Finalmente me gustaría invitarlos a que visiten el sitio de Líder de Proyecto ya que en el se abordan temas muy interesantes y valiosos y colaboran colegas muy capaces.

Saludos, feliz año nuevo y mucho éxito para todos.

Cerdos y gallinas

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Categoría: Reflexión

Desde hace algunos años ha llamado mi atención el conjunto de mejores prácticas conocido como SCRUM mismas que he aplicado satisfactoriamente en varios proyectos (las prácticas, no SCRUM). Nunca había revisado la documentación publicada en Wikipedia asociada a esta "metodología". Esta semana, al estar evaluando una herramienta para administrar requerimientos fui referido a esta fuente y me resultó muy interesante. Entre los datos interesantes que me gustaría compartir esta la fábula sobre la cual están basados los grupos en los que se organizan los roles de SCRUM, mismos que son el título que lleva esta entrada :), los cerdos y las gallinas.

Un día se encuentran un cerdo y una gallina:

Gallina: "Oye cerdo, ¿qué te parece si nos asociamos y abrimos un restaurante y repartimos las utilidades por la mitad?"

Cerdo: "Me parece buena idea. ¿Cuál propones que sea la especialidad de la casa?"

Gallina: "Se me ocurre que podrían ser los huevos con jamón".

Cerdo: "¿Huevos con jamón? No me parece justo".

Gallina: "¿Porqué? ¿Cuál es el problema?".

Cerdo: "Pues resulta que con tu propuesta tú sólo estarías involucrada mientras que yo estaría comprometido".

Esta fábula me parece genial para ilustrar la diferencia entre compromiso y participación (o estar involucrado).

Otro punto que me gustaría discutir, y que es el centro de la reflexión, es la primera primera descripción que se hace con referencia a los roles gallina, documentada en el párrafo que le sigue al de la fábula en el que se puede leer: "...mientras que todos los demás son gallinas: interesados en el proyecto pero realmente irrelevantes, porque si falla, ellos no son un cerdo, es decir, ellos no fueron los que se comprometieron a hacerlo. Las necesidades, deseos, ideas e influencia de los roles gallina se toman en cuenta pero no de una manera en la que se permita que afecten o distorsionen o se entrementan en el proyecto". Después, más adelante, nos podemos encontrar otra definición con respecto a los roles "Gallina", en donde se puede leer: "En realidad los roles gallina no son parte del proceso SCRUM, pero se les debe considerar. Una parte importante de la aproximación Ágil consiste en involucrar a los usuarios, a los expertos del negocio y a los stakeholders en alguna parte del proceso. Es importante que esta gente participe y proporcione retroalimentación para revisar y planear cada iteración (split)". La sección concluye identificando a los Usuarios, los Stakeholder (Clientes y Proveedores) y a los Administradores o Gerentes.

Si la diferencia entre estar comprometido o involucrado es que al comprometido se le va la vida en el proceso mientras que al involucrado no, entonces tenemos un problema. Pongámonos un momento en el lugar del usuario final. Supongan que la herramienta que necesitas es un artefacto que te permita mantener unidas dos piezas a través de medios mecánicos y se concluye con que lo que hay que construir es un martillo. Las características y atributos son definidas por las áreas normativas y técnicas (a esto se le conoce como "diseño interno") sin tomar en cuenta la necesidades cotidianas de los usuarios finales. Por supuesto existe el riesgo de construir un producto que no satisfaga a los usuarios. Recordemos que el mayor riesgo en el desarrollo de software consiste en construir el producto incorrecto, si esto ocurre "todos ponen". Quizá en el contexto de los productos de ingeniería de software los usuarios sean los que más la llevan de perder al ser obligados a usar una herramienta en lugar de ayudarlos les estorba ¿a quien se le fue la vida realmente?. Créanme, conozco más de un caso.

Me parece que el problema con tal afirmación es una cosmovisión limitada en donde se ve al producto de software existiendo únicamente en el contexto del desarrollo del mismo. Recordemos que, al final del día, los productos de software se construyen para los negocios, no únicamente para las personas, por consiguiente siempre deben estar ubicados en el contexto de una arquitectura empresarial.

En el glosario de CMMI-DEV 1.2 se definen los términos Stakeholder y Stakeholder Relevante mismo que incluyo a continuación:

Stakeholder. De acuerdo con CMMI Product Suite, es el grupo o individuo se ve afectado o es considerado de algún modo por la salida del proyecto. Los stakeholders pueden incluir a los miembros del proyecto, a los proveedores, a los clientes, a los usuarios finales y otros.

Stakeholder Relevante. Es un stakeholder que se identifica por su participación en actividades específicas y que está incluido en algún plan.

Por supuesto SCRUM es un proceso genial, lo que asumo que ocurrió fue el resultado de una interpretación con insuficiencia de datos, como muchas veces ocurre, no sólo en la ingeniería.

Diferencia entre operación y método

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Categoría: Certificación

Otro concepto que debemos dominar, al aplicar para la certificación, es el relacionado con la diferencia que existe entre operaciones y métodos ya que ambos son diferentes cuando se tiene polimorfismo.

Un método es la implementación de una operación, mientras que una operación es algo que podemos invocar sobre un objeto.

Por ejemplo, si tienes un supertipo con tres subtipos, y cada uno sobre-escribe la operación "operacion1()" del supertipo, entonces tienes una operación y cuatro métodos.

Por ejemplo, con base en este diagrama nos podrían preguntar: ¿Cuantas operaciones y cuantos métodos hay?

La respuesta entonces sería: dos operaciones, "operacionA()" y "operacionB()", con seis métodos.

Pueden existir variantes pero una en la que debemos poner especial atención es la relacionada con las operaciones abstractas ya que estas carecen de implementación. Las operaciones abstractas se modelan usando itálicas para el nombre del método.

Consistencia entre Diagramas de Secuencia y Diagramas de Clases

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Categoría: Certificación

El tema que voy a desarrollar en esta entrada discute un punto de evaluación típico en los exámenes de certificación de UML. Se trata de la consistencia que debe existir entre los diagramas de secuencia y los diagramas de clases.

Como sabemos, los diagramas de secuencia normalmente son empleados para visualizar, especificar o documentar la manera en la que una sociedad de objetos colabora para alcanzar los objetivos planteados en un escenario de un caso de uso. Nos ofrecen una perspectiva desde la cual podemos abordar el comportamiento de un sistema. Por supuesto, este comportamiento debe estar plenamente soportado por la estructura del sistema. Como en todos los sistemas, nada puede moverse si su estructura no lo soporta. Si la estructura de un sistema no soporta cierto aspecto dinámico normalmente suele colapsar.

Las tres reglitas son las que enumero a continuación:

1. Cualquier objeto que aparezca como participante en el diagrama de secuencia, debe ser instancia de un clasificador en un diagrama de clases (observe que los diagramas de casos de uso son un tipo de diagrama de clases).
2. Cualquier intercambio de mensajes que se dé entre dos participantes que sean instancia de distintas clases, implica que las clases de las cuales son instancia dichos participantes deben estar vinculados mediante algún tipo de relación (asociación, agregación, composición, dependencia o generalización).
3. Cualquier mensaje que se intercambie entre participantes, ya sea reflexivo o no, debe estar soportado por una operación de la clase.

De esta manera, con base en el diagrama que se muestra a continuación nos podrían preguntar ¿Qué métodos deben ser implementados por la clase "Secretaria"?:

Con base en la tres premisas anteriores, la respuesta sería:

1. Con base en el diagrama, debe implementar los métodos "aceptarAplicacion(...)", "almacenar()", "obtenerAplicacion()".

Además podríamos decir:

En el diagrama de clases deben existir las clases:

1. "Persona" la cual debe estar relacionada con la clase "Secretaria" como consecuencia de la llamada a operación "aceptarAplicacion(...)".
2. "Secretaria" que debe estar relacionada con las clases "Bandeja", por las invocaciones a las operaciones "colocar(...)" y "obtener()", y "Gerente", por la operación "notificar(...)" respectivamente.
3. "Bandeja" de la cual no se origina ninguna relación, salvo la antes mencionada con "Secretaria".
4. "Gerente" que origina una relación hacia la clase "Secretaria", derivada de la invocación a la operación "obtenerAplicacion()".

Existen muchas variantes para evaluar este aspecto pero siempre que se tengan presentes los tres principios expuestos la respuesta será simple.

La odiada palabrita "depende"

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Categoría: Reflexiones

A lo largo de los más de quince años de vuelo que tengo en estos rollos he notado que más de un "cliente" (alguien al que tenemos la oportunidad de servir, lo cual nos convierte en el "servidor") manifiesta mediante lenguaje corporal o verbal su... digamos incomodidad cuando los "servidores" usamos la palabra "depende" para responder a algún cuestionamiento que, desde su perspectiva, es sumamente concreto. En más de una ocasión, me han confrontado con una frase tan franca y sencilla como: "bueno, porque todos ustedes siempre dicen depende", refiriéndose a los que ostentamos el mote de consultores, por supuesto.

Debo confesar que hasta hace unos doce años, la razón de esto aún yacía en mi subconsciente y, después de traerla al consciente, esta razón ha sido depurada a lo largo de los años.

La respuesta corta es: "La respuesta siempre es 'depende' porque, a diferencia de la ciencias exactas, los problemas de ingeniería siempre son problemas de solución abierta". Tan, tan.

Que es eso de solución abierta, pues que un mismo problema puede tener más de una solución aceptable, que no existe una formula general (quien se vea embargado por la duda de: "y entonces los patrones", le que lea mi entrada anterior).

La palabra "depende" en realidad quiere decir: "en este momento, no poseo suficiente información para proponerte, de manera responsable, una solución".

En mi experiencia, después de explicar que es "depende", las cosas siempre marchan mejor. Supongo que derivado de la empatía del "cliente" hacia el "servidor".

Arquitectura vs. Tecnología

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Clasificación: Debate

Esta entrada lo motiva una discusión constructiva que se suscitó recientemente (hace unas horas) :).

Sucede que en el Curso de Patrones de Arquitectura de Software y Patrones de Diseño de Software, que acaricia los Patrones de Arquitectura Web, alguien comento que esta sección "está totalmente desactualizada y no refleja el panorama actual, de ninguna manera".

Después, indagando más sobre el comentario anterior, descubrí que tal aseveración tuvo como origen, lo que a mi juicio es, una mala interpretación de la palabras del consultor que lo impartió, a quien yo respeto mucho, dicho sea de paso.

Sucede que el consultor les comentó que en el curso se mencionan tecnologías como ActiveX y Applets cuando la tendencia actual apunta o favorece otras tecnologías tales como Flex o SilverLight para conseguir experiencias de usuario ricas (de ahí lo de Aplicaciones basadas en Internet Ricas o, más retro, Cliente Rico Web).

Punto número uno. Una arquitectura Web no se está limitada a ser distribuida por Internet, podría distribuirse en una Extranet o en una Intranet o podría ser una aplicación enteramente local. Los arquetipos de arquitectura Web tienen como común denominador dos bloques arquitetónicos predominantes: un browser capaz de soportar formas HTML y HTTP como protocolo de comunicación.

Punto número dos. La solución "depende del contexto" (ah, como odian mis clientes la palabrita "depende", pero prometo discutir en otro artículo todo lo que quiere decir). En este sentido, creo que nada debería ser catalogado como obsoleto o desactualizado porque eso casi siempre conlleva a cerrar el abanico de soluciones posibles y esa practica va en contra de los principios de la ingeniería. En todo caso deberíamos de hablar de tecnologías o practicas o estándares desfavorecidos bajo cierto contexto. Acaso no dicen por ahí, por ejemplo, que estamos regresando al Mainframe ;) y que esto en si constituye una tendencia (por favor, no se rasguen las vestiduras y pásenme por alto este comentario hecho a la ligera).

Punto número tres. La tecnología y la arquitectura, en cualquier ámbito y alcance, si bien están relacionadas, son dos animales completamente distintos. En todo caso la tecnología es un elemento que habilita a la arquitectura y, por consiguiente, un mismo estilo arquitectónico podría ser habilitado empleando tecnologías distintas.

En conclusión, el pecado radica en el siguiente sofisma: si la tecnología está desfavorecida u obsoleta, entonces el patrón de arquitectura que puede ser habilitado con esa tecnología también lo está.

Finalmente, recordemos que un patrón, según la Real Academia de la Lengua Española, "es un modelo que sirve de muestra para sacar otra cosa igual", bajo una aproximación inductiva, quisiera agregar.

Los patrones de arquitectura y/o de diseño documentados en un sinnúmero de fuentes surgen de un proceso deductivo. Al acomodar un conjunto de cosas y observar que funcionaban una y otra vez para un problema similar constituyeron un patrón que vale la pena repetir hasta que se encuentre una configuración mejor (observe que use la palabra "configuración" y no "tecnología").