UML por sus siglas en ingles ha sido ampliamente aceptado como el lenguaje de modelado orientado a objetos por excelencia. Este lengua no se limita unicamente al diseño de software su ambito de uso es mucho mas amplio, es aplicable desde el modelado de negocios hasta diseño de software y modelado de aplicaciones web. Es decir tiene un ambito muy amplio y abarca un conjunto de dominios de aplicacion sumamente diverso.Este lenguaje puede ser estructurado de forma modular con la posibilidad de utilizar solo aquellas partes del lenguaje que nos sean de utilidad. Aunque un exceso de esta flexibilidad incrementa la posibilidad de que herramientas UML diferentes soporten diferentes subconjuntos del lenguaje causando problemas de intercambio entre las mismos. Por tanto la para un a definicion de conformidad con UML es necesario establecer un balance entre modularidad y facilidad de intercambio.
Para entender mejor la utilidad de este lengueje sera mejor que hablemos en terminos prácticos. Hablemos primeramente del modelado de sistemas.
El modelado es un técnica utilizada en todas las ingenierías. Como tal la ingeniería software debe basarse en el modelado como una parte central de toda la actividades que conducen a la producción de software de calidad. La gestión del proceso software exige de forma general el disponer de un modelo. Construimos modelos para comunicar la arquitectura y el comportamiento deseado en nuestro sistema. Construimos modelos para visualizar y controlar la arquitectura del sistema y para comprender mejor el sistema que estamos construyendo, muchas veces descubriendo posibilidades de simplificación y reutilización.
Cuanto más grande y complejo sea un sistema mayor es la importancia de la utilización de buenas técnicas de modelado: existe un límite en la capacidad humana de comprender la complejidad. Por tanto, en un sistema software de magnitud industrial el desarrollar un modelo antes de su construcción o renovación es esencial para la comunicación entre equipos de trabajo y para asegurar la solidez de la arquitectura.
Dado que UML es un leguaje semanticamente ríco no podremos ahondar en todos sus conceptos. En entradas anteriores hemos abordado conceptos basicos de la orientaion a objetos que forman parte del lenguaje. en esta entrada nos ceentraremos en algo poco abordado dado que puede obtener información acerca de tales conceptos en internet, además de un sinnumero de tutoriales y libros acerca del tema.
El proposito aqui no es enseñar aquellas cosas en las cuales todos estamos de acuerdo que entendemos igual respecto al lenguaje unificado de modelado, tales como los diagrmas y contruccion de los mismos, aunque aun en ese tema podría discutirse mucho. El proposito fundamental sera el cómo, cuándo y porqué utilizar algunos conceptos del lenguaje, y errores cometidos frecuentemente en la implementacion del mismo para representar los sistemas que modelamos.
El primer error cometido y que se sostiene a lo largo de la enseñanza en la mente de los estudiantes es que confundir UML (un lenguaje) con un proceso de desarrollo. Un proceso de desarrollo de software es un método de organizar las actividades para creación, presentación y mantenimiento de los sistemas software. El lenguaje UML no define un proceso de desarrollo, en relidad UML se combina con un proceso de desarrollo para obtener un producto final. Uno de los procesos mas utilizado y recomendados y de los que hay abundante informacion es RUP(Rational Unified Process) tambien conocido como Proceso Unificado de Desarrollo.
Otro error se deriva de una interpretación incorrecta de los casos de uso, esto lo aprenden frecuentemente los estudiantes de sus maestros. El problema con los casos de uso es que el grado descomposicion del problema queda sujeto al criterio de analista, con lo cual cada quien entiende que los casos de uso llegen a un nivel de datalle diferente. Lo adescuado seria determinar la cantidad y grado adecuado de analisis requerido para el proyecto. Algunos docentes enseñan a los estudiantes que los casos de uso estan asociados a las interfaces graficas de usuario, algo erróneo dado que la interfaz gráfica es parte de las labores de implementación y los casos de uso deben ser utilizados enlas etapas de análisis.
En relaidad es bastante complejo determinar hasta donde debe ser de especifico un caso de uso, sobre todo en sistemas grandes o muy complejos. Lo importante para cada proyecto es determinar la cantidad necesaria de análisis requerida. Sin olvidar como ya mencionabamos que los casos deben ser utilizados para la captura de requerimientos del sistema, segun la la espeficación de superestructura de UML de la OMG.
Los errores en el uso de las relaciones en los diagramas uml son frecuentes especialmente si no se ha tenido alguna experiencia de trabajo ene equipo con los modelos. Utilizar no solo el tipo correcto de relación que expresa lo que acurre en el sistemas real y es a la vez conceptualmente claro para todo el que lea el diagrama, es difícil de conseguir. Les insto a buscar siempre la manera mas sencilla y clara de represnetar las relaciones, agregar los roles en los extremos de las relaciones, especificar el tipo adecuado de multiplicidad de una relación. No siempre el funcionamiento del sistemas real puede representarse o implementarse de tal y como ocurre en la vida real.
Recuerden los modelos son simplificaciones de la realidad que que nosotros y los demás involucrados en un proyecto de sistemas opera. Los modelos de sistemas constituyen al ugual que en arquitectura la base sobre la que se contruira un producto tangible, y es por tanto indispensable que sena correctos y sin ambiguedades. Utilizemos correctamente las herramientas con que contamos para obtener de ellas todo su potencial expresivo.
