jueves, 17 de octubre de 2013

Introducción al UML - Parte 1 de 3





El UML (Lenguaje Unificado de Modelado) es una de las herramientas más emocionantes en el mundo actual del desarrollo de sistemas. Esto se debe a que permite a los creadores de sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender para comunicarlas a otras personas.

En esta hora se tratarán los siguientes temas:

  • Por qué es necesario el UML
  • La concepción del UML
  • Diagramas del UML
  • Para qué tantos diagramas

Termino Nuevo: En el contexto de esta publicación considere a un sistema como una combinación de software y hardware que da una solución a un problema de negocios. El desarrollo de sistemas es la creación de un programa para un cliente, este último es quien tiene el problema que debe ser resuelto. Un analista es el que documenta el problema del cliente y lo comunica a los desarrolladores, que son los programadores que generarán el programa que resolverá el problema y lo distribuirán en equipos de computación.

La comunicación de la idea es de suma importancia. Antes del advenimiento del UML, el desarrollo de sistemas era, con frecuencia, una propuesta al azar. Los analistas de sistemas intentaban evaluar los requerimientos de sus clientes generar un análisis de requerimientos en algún tipo de notación que ellos mismos comprendieran (aunque el cliente no lo comprendiera), dar tal análisis a uno o varios programadores y esperar que el producto final cumpliese con lo que el cliente deseaba.

Dado que el desarrollo de sistemas es una actividad humana, hay muchas posibilidades de cometer errores en cualquier etapa del proceso, por ejemplo, el analista pudo haber malentendido al cliente, es decir, probablemente produjo un documento que el cliente no pudo comprender. Tal vez ese documento tampoco fue comprendido por los programadores quienes, por ende, pudieron generar un programa difícil de utilizar y no generar una solución al problema original del cliente.

Alguien se preguntará por qué muchos de los sistemas en uso son ineficientes, engorrosos y dificiles de utilizar?


Por que es necesario el UML

En los principios de la computación, los programadores no realizaban análisis muy profundos sobre el problema por resolver. Si acaso, garabateaban algo en una servilleta. Con frecuencia comenzaban a escribir el programa desde el principio, y el código necesario se escribía conforme se requería. Aunque anteriormente esto agregaba un aura de aventura y atrevimiento al proceso, en la actualidad es inapropiado en los negocios de alto riesgo.

Hoy en día, es necesario contar con un plan bien analizado. Un cliente tiene que comprender que es lo que hará un equipo de desarrolladores; además tiene que ser capaz de señalar cambios si no se han captado claramente sus necesidades (o si cambia de opinión durante el proceso). A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que cada uno de sus miembros tiene que saber qué lugar toma su trabajo en la solución fina.

Confonne aumenta la complejidad del mundo, los sistemas infonnáticos también deberán crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que se comunican a grandes distancias mediante una red, misma que está vinculada a bases de datos que, a su vez, contienen enormes cantidades de información. Si desea crear sistemas que lo involucren con este nuevo milenio ¿cómo manejará tanta complejidad? 

La clave está en organizar el proceso de diseño de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y convengan con el. El UML proporciona tal organización. 

Un arquitecto no podría crear una compleja estructura como lo es un edificio de oficinas sin crear primero un anteproyecto detallado; asimismo usted tampoco podría generar un complejo sistema en un edificio de oficinas sin crear un plan de diseño detallado. La idea es que así como un arquitecto le muestra un anteproyecto a la persona que lo contrató, usted deberá mostrarle su plan de diseño al cliente. Tal plan de diseño debe ser el resultado de un cuidadoso análisis de las necesidades del cliente.

Otra característica del desarrollo de sistemas contemporáneo es reducir el periodo de desarrollo. Cuando los plazos se encuentran muy cerca uno del otro es absolutamente necesario contar con un diseño sólido.

Hay otro aspecto de la vida moderna que demanda un diseño sólido: las adquisiciones corporativas. Cuando una empresa adquiere a otra. la nueva organización debe tener la posibilidad de modificar aspectos importantes de un proyecto de desarrollo que esté en progreso (la herramienta de desarrollo, el lenguaje de codificación, y otras cosas). Un anteproyecto bien diseñado facilitará la conversión. Si el diseño es sólido, un cambio en la implementación procederá sin problemas.

La necesidad de diseños sólidos ha traído consigo la creación de una notación de diseño que los analistas, desarrolladores y clientes acepten como pauta (tal como la notación en los diagramas esquemáticos sirve como pauta para los trabajadores especializados en electrónica). El UML es esa misma notación.


La concepción del UML

El UML es la creación de Grady Booch, James Rumbaugh e lvar Jacobson. Estos caballeros, apodados recientemente “Los tres amigos”, trabajaban en empresas distintas durante la década de los años ochenta y principios de los noventa y cada uno diseñó su propia metodología para el análisis y diseño orientado a objetos. Sus metodologías predominaron sobre las de sus competidores. A mediados de los años noventa empezaron a intercambiar ideas entre sí y decidieron desarrollar su trabajo en conjunto.

Las horas 2, "Orientación a objetos", y 4, "Uso de relaciones", tratan de la orientación a objetos. Los conceptos de orientación a objetos tienen un papel fundamental en el desarrollo de esta publicación.

En 1994 Rumbaugh ingresó a Rational Software Corporation, donde ya trabajaba Booch.
Jacobson ingresó a Rational un año después; el resto, como dicen, es historia.

Los anteproyectos del UML empezaron a circular en la industria del software y las reacciones resultantes trajeron consigo considerables modificaciones. Confonne diversos corporativos vieron que el UML era útil a sus propósitos, se conformó un consorcio del UML. Entre los miembros se encuentran DEC, Hewlett-Packard. lntellicorp, Microsoft, Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la versión 1.0 del UML y lo puso a consideración del OMG (Grupo de administración de objetos) como respuesta a su propuesta para un lenguaje de modelado estándar.

El consorcio aumentó y generó la versión 1.1, misma que se puso nuevamente a consideración del OMG. El grupo adoptó esta versión a finales de 1997. El OMG se encargó de la conservación del UML y produjo otras dos revisiones en 1998. El UML ha llegado a ser el estándar de facto en la industria del software, y su evolución continúa.



Espero haber ayudado en algo. Hasta la próxima oportunidad! 




6 comentarios:

  1. Respuestas
    1. Hola Rene Zapata, gracias por tu visita y el aporte de tu comentario!!
      Los mejores deseos!! Hasta cualquier momento...

      Eliminar
  2. La información es buena, pero debo aclarar, que desde que empece a programar por el año 1983, ya se usaban diagramas de diversos tipos: procesos, flujos... se forjaba un documento con la definición del problema, se hacían narrativas de los requerimientos, en fin...

    ResponderEliminar
    Respuestas
    1. Hola Anónimo, gracias por la visita y el aporte de tus conocimientos!!
      Éxitos! Hasta cualquier instante!!

      Eliminar
  3. muy buena informaciòn, una buena documentacion es la base de todo sistema complejo

    ResponderEliminar
    Respuestas
    1. Hola Anónimo, gracias por la visita y el aporte de tus conocimientos.
      Los mejores deseos!! Hasta cualquier momento!

      Eliminar