jueves, 4 de diciembre de 2014

Características de los casos de uso CRUD y sus desventajas para ser diagramados


Foro temático semana cuatro

Identifica y explica 3 características primordiales de los casos de uso CRUD y sus desventajas para ser diagramados. Justifica tu respuesta.

R:
Existen en el mundo de la ingeniería de requerimientos una amplia gama de patrones de Casos de Uso que pueden ser utilizados, pero la pregunta que salta a la vista es: ¿Cuál es más conveniente? ¿Cuál se adecua mejor a las características del producto que se desea construir y a las peculiaridades de todos los involucrados, cliente incluido?
Un ejemplo bastante común, en el ámbito del desarrollo de aplicaciones de gestión, es la disyuntiva entre utilizar el patrón CRUD (Create, Read, Update and Delete, por sus siglas en inglés) o no. Es decir, la elección entre concebir Casos de Uso que reúnan todas las acciones básicas sobre una entidad de dominio en uno solo, o concebir un Caso de Uso para cada una de estas acciones básicas para cada entidad de dominio.
Cualquiera de las variantes es válida, siempre y cuando exista una métrica que vaya más allá del Caso de Uso como unidad de tamaño, y nos permita estimar la complejidad del mismo.
De otra forma, la planificación, evaluación y comparación de proyectos tratada con anterioridad, carece de sentido práctico: un Caso de Uso concebido bajo el patrón CRUD es equivalente a 4 Casos de Uso concebidos sin usar el patrón, y no pueden ser considerados como equivalentes de ninguna forma.

Un caso de uso esencial se caracteriza porque:
   ·         la funcionalidad CRUD es una porción del caso de uso,
   ·         el actor que lo inicia está bien generalizado,
   ·         su secuencia básica completa una interacción mayor con el sistema,
   ·         no está asociado con componentes arquitectónicos o del sistema,
   ·         es completamente independiente de la implementación de la Interfaz de Usuario,
   ·         contiene un número mayor de secuencias alternas (esto podría representar algún tipo de inconveniente a la hora de cualificar la legibilidad del caso de uso),
   ·         representa muchos ejemplos concretos de interacción, es decir, deriva en muchos escenarios,
  ·         es bastante útil para pruebas del sistema y de funcionalidad.
Finalmente, un caso de uso esencial forma parte de un modelo de casos de uso cuyo número de extensiones e inclusiones es menor al 20% de todo el modelo.

Características del caso de uso CRUD

Ventajas de la utilización del patrón de Casos de Uso CRUD
Entre las ventajas de la utilización del patrón CRUD pueden mencionarse:
   ·         Se reúnen en un solo elemento de configuración del software todas las acciones básicas que se realizan sobre una entidad de dominio.
  ·         Se facilita la comprensión por parte del cliente de la funcionalidad del sistema.
  ·         Se facilita la especificación de los casos de uso, logrando un alto nivel de detalle sin tener que invertir esfuerzo en describir aspectos generales de funcionalidad más de una vez.
   ·         Se facilita la reusabilidad del código, a partir de identificar relaciones entre los Casos de Uso, con un mínimo de esfuerzo.

Desventajas de la utilización del patrón de Casos de Uso CRUD
La desventaja principal radica en que, si no existe una métrica completa que permita estimar la complejidad de los Casos de Uso, y la estimación y planificación de los proyectos permanece al nivel del Caso de Uso como unidad, casi seguramente el proyecto incurrirá en atrasos y sobrepasará su presupuesto, en comparación con otros que no usen dicho patrón. Escribir casos de uso CRUD y similares aumenta innecesariamente el número de casos de uso, el tiempo de especificación, el tiempo de revisión, el tiempo de aprobación. Sí, quizás disminuya el tiempo de programación, pero este es cada vez más reducido a la luz de las poderosas herramientas con las que contamos hoy para escribir código fuente.
Una mirada desde el ángulo comercial
Una de las ventajas de tener una estimación adecuada del proyecto es el impacto positivo que se tiene en la administración de contratos. Es imposible garantizar productividad en la esfera de la producción de software sin una herramienta que asegure la misma desde la etapa más temprana de un proyecto: la negociación, especialmente en el caso de las soluciones “llave en mano” que incluyen generalmente el desarrollo de aplicaciones informáticas “a la medida”.
El estudio inicial de procesos de negocio y la determinación, a través de métricas, del tamaño, complejidad y esfuerzo de desarrollo, pasan a convertirse en esta herramienta.

Volviendo al tema de los Casos de Uso que aplican el patrón CRUD, es evidente que no puede ser igual el costo de un Caso de Uso CRUD al de un Caso de Uso que solo contenga la funcionalidad referida a una sola acción básica sobre una entidad de dominio. Pero esto es parte de la negociación y de los aspectos que se deben pactar en el marco de un contrato, para evitar que posteriormente el proyecto se vuelva inmanejable dentro del tiempo y presupuesto estimado en sus inicios.

Redacción de casos de uso


Actividad semana cuatro

Nombre de la actividad: Redacción de casos de uso

  1. Entreviste a un usuario de sistemas en alguna empresa pequeña. Obtenga información respecto a sus estrategias de recopilación de requerimientos para el desarrollo de las aplicaciones de software de la empresa, pregunte si utilizan la metodología de casos de uso. En caso de que sí utilicen esta técnica, pregunte sobre los principales beneficios que han logrado con su uso y pida que le muestren algún ejemplo con fines de aprendizaje.

  1. Desarrolle dos Casos de Uso de requerimientos funcionales para un determinado sistema de software de esta empresa (con procesos sencillos), esto permitirá desarrollar las habilidades de análisis funcional e identificar los puntos importantes para poder desarrollar los casos de uso.


Introducción
Estamos en un mundo globalizado, de salvaje competencia y adelantos tecnológicos; los negocios surgen con las ideas de la gente creativa, pero no pueden competir contra los grandes sin sumarse a la renovación tecnológica y los constantes adelantos, que en todos los campos se están dando. Así que con las nuevas Tecnologías de la Informática y las Comunicaciones los inversionistas y gerentes se disponen a la lucha, en que solo sobreviven los que mantengan al día en los sistemas de información, con que han de manejar e innovar continuamente sus negocios. ¿Cómo lograr esta permanencia sin los procesos mediante los cuales sus sistemas se mueven?; y para que estos procesos no queden obsoletos de un día para otro se hace necesario la creación y desarrollo del software con que pueden ser competitivos y exitosos.
La sociedad moderna está requiriendo software más complejo, con mayor rapidez y de manera económica. Se pueden ver sistemas de software en la mayoría de las organizaciones, como las que se dedican al comercio, y también encontramos software en aparatos electrónicos como teléfonos celulares y hornos de microondas. El tamaño de los productos de software, su complejidad así como la necesidad de generarlos de tal manera que satisfagan los distintos requerimientos de diversos usuarios requiere de técnicas y herramientas que faciliten la comunicación entre usuarios y grupos de desarrolladores de software.
Desarrollo
    1)   Para cualquier empresa se dan situaciones muy parecidas, ya sean grandes o pequeñas, las necesidades y retos son los mismos: el diseño de sus sistemas, su documentación y búsqueda de requerimientos, la implementación, prueba y mantenimiento. Por eso, dado el caso que tengamos un usuario de una empresa pequeña, por ejemplo don Jorge Martínez, administrador general de ABC, y lo interroguemos, sobre la creación y desarrollo del software con que trabajan y enfrentan los retos que se les presentan en su actividad diaria, tendríamos resultados parecidos a si fuera cualquier otra en el mundo real, con algunas variaciones entre empresas por supuesto, y podemos estar seguros que las situaciones son dinámicas más que rutinarias, creativas más que establecidas y muy enriquecedoras académica e intelectualmente.
Don Jorge Martínez trabaja en ABC para la cual se encarga de la administración general; teniendo en cuenta el interés en conocer sobre el desarrollo del software en la empresa, he ideado unas cuantas preguntas elementales y básicas, las cuales me he encargado de dejar respondidas por él, en este documento para su estudio.

Carlos Augusto Muriel: Don Jorge, quisiera que me cuente qué tipo de software tienen en su empresa, enlatado o desarrollo propio; según tengo entendido últimamente están muy interesados en los adelantos tecnológicos y han invertido fuertes sumas en ello.
Jorge Martínez: La verdad es que los desarrollos propios son más efectivos, llevan tiempo, que es dinero, pero son los adecuados a nuestras necesidades; a la larga el resultado será el mejor.
CAM: Sabemos que al diseñar un sistema tenemos que capturar sus requerimientos,  tener el registro completo de lo que se supone haremos con él, cómo lo usaremos, y así elaborar el modelo de lo que será el software de la empresa, en este caso de ABC; ¿podría decirme, para el estudio, cuál es la metodología que emplean para capturar los requerimientos de su sistema?
JM: Actualmente, el desarrollo de software orientado a objetos y el uso de UML se han incrementado. Es por ese motivo que el empleo de casos de uso se está imponiendo frente a otras técnicas de especificación de requisitos.
Para determinar la funcionalidad de un sistema a desarrollar, UML señala el uso de dos elementos: el actor y el caso de uso. Los casos de uso son muy útiles para explicar el funcionamiento del sistema, priorizar requerimientos cuando el sistema se desarrolla de forma incremental, elaborar manuales de usuario y especificar pruebas de aceptación. Mejoran la trazabilidad de los requerimientos durante el proceso de desarrollo de software. Se pueden desarrollar en paralelo con los requerimientos del sistema de forma iterativa. Supongo que con lo que le acabo de decir respondo su pregunta.
CAM: Quisiera que me haga el favor, don Jorge, y me cuente ¿cuáles son los beneficios obtenidos por su empresa, al emplear la técnica de los casos de uso para la captura de los requerimientos de su sistema informático?
JM: Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso de uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema.
No se trata de analizar y desmenuzar algo que ya existe, sino de crear (junto con los clientes) una concepción común del sistema software a desarrollar. La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema. Como técnica de extracción de requerimientos permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción, el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con los informáticos.

CAM: Ya para terminar, ¿qué podría añadirnos sobre los casos de uso?
JM: El proceso es el conocimiento incorporado, y puesto que el conocimiento está inicialmente disperso, el desarrollo de software implícito, latente e incompleto en gran medida es un proceso social de aprendizaje. El proceso es un diálogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software. El proceso proporciona una iteración entre los usuarios y los diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas de desarrollo (tecnología). Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento.

     2)    
A continuación se muestran los siguientes ejercicios representados en diagramas de caso de uso de la empresa ABC:

·         Contabilización del proceso de facturación.

 ·         Control sobre la facturación de pedidos.

                    






Los Casos de Uso y UML


Continuación foro semana 3

Los Casos de Uso y UML

A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma, la notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML –Unified Modelling Language– propuesto por Ivar Jacobson, James Rumbaugh y Grady Booch, tres de los precursores de las metodologías de Análisis y Diseño Orientado a Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de convertirse en un estándar para modelado de sistemas de software de amplia difusión.
A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante destacar que los casos de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a objetos “clásico”. En este sentido, el éxito de los casos de uso no hace más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que interactúan dentro del sistema para proveerlos.
Como era de esperar, es probable que en el futuro los métodos de análisis y diseño que prevalezcan hayan adoptado las principales ventajas de todos los métodos disponibles en la actualidad –estructurados, métodos formales, métodos orientados a objetos, etc.–
De lo dicho anteriormente podemos concluir que los casos de uso son independientes del método de diseño que se utilice, y por lo tanto del método de programación. Luego de documentar los requerimientos de un sistema con casos de uso, se puede diseñar un sistema “estructurado” (manteniendo una separación entre datos y funciones), o un sistema Orientado a Objetos, sin que la técnica sea de mayor o menor utilidad en alguno de los dos casos. Esto da más flexibilidad al método, y probablemente contribuya a su éxito.

Casos de Uso
Un Caso de Uso especifica una manera de usar un sistema sin revelar la estructura interna del mismo. Los Casos de Uso han sido adoptados casi universalmente para capturar los requerimientos de los sistemas de software; sin embargo, los Casos de Uso son más que una herramienta de especificación ya que tienen una gran influencia sobre todas las fases del proceso de desarrollo tales como el diseño, la implementación y las pruebas del sistema. En general, los procesos de desarrollo de software son iterativos e incrementales, repitiendo una serie de iteraciones sobre el ciclo de vida de un sistema. Cada iteración consiste de un paso a través de las etapas de requerimientos, análisis, diseño, implementación y prueba. El resultado de cada iteración representa un incremento sobre cada uno de los modelos construidos en las etapas anteriores. Los distintos Casos de Uso que se definen a lo largo del proceso de desarrollo no son independientes sino que es posible establecer relaciones de dependencia entre ellos. Las principales relaciones consideradas por UML son:

·         Generalización
·         Inclusión
·         Extensión

El conjunto completo de Casos de Uso especifica todas las posibles maneras en las que el sistema puede ser usado, sin revelar cómo esto es implementado por el sistema. Esto hace a los Casos de Uso apropiados para definir requerimientos funcionales en etapas tempranas del desarrollo del sistema, donde la estructura interna de éste aún no fue definida. Debido a que los Casos de Uso no se manejan con elementos dentro del sistema sino que se centran en cómo el sistema es percibido desde el exterior, son útiles en discusiones con usuarios finales para asegurar que hay concordancia con los requerimientos realizados sobre el sistema, sobre sus limitaciones, etc. Más precisamente, un Caso de Uso especifica un conjunto de secuencias completas de acciones que el sistema puede realizar. Cada secuencia es iniciada por un usuario del sistema. Esto incluye la interacción entre el sistema y su entorno como también la respuesta del sistema a estas interacciones.


Referencias:

Relaciones entre Casos de Uso en el Unified Modeling Language
Roxana S. Giandin Claudia F. Pons
REVISTA COLOMBIANA DE COMPUTACIÓN
Volumen 1, número 1 Págs. 73-90


UML como base para realizar los diagramas de representación de un sistema


Foro temático semana tres

Descripción: Comparta con sus compañeros las ventajas más relevantes de usar UML como base para realizar los diagramas de representación de un sistema.


Introducción

En general al producirse un requerimiento de software, surge una idea. Por ejemplo un administrador general de un negocio que compra y vende productos, observa que utilizando la informática puede mejorar sustancialmente su administración; entonces, teniendo una idea bastante clara de su necesidad, acude a especialistas en desarrollo de software.
Después de varias entrevistas, los especialistas determinan que deben cumplir con las siguientes etapas de trabajo para generar el software adecuado a los requerimientos de su cliente:
     a)    Relevamiento
     b)    Análisis
     c)    Diseño
     d)    Desarrollo   
     e)    Capacitación
     f)     Mantenimiento
El relevamiento consiste en un dialogo permanente de los especialistas y el cliente (puede incluir al personal de diferentes sectores del negocio) con el fin que los primeros identifiquen todos y cada uno de los componentes de dicho negocio y cómo interactúan. En definitiva, los especialistas deben comprender aquella idea detalladamente y mantenerla mientras se produce el software.
Para esto, los especialistas pueden hacer uso del Lenguaje Unificado de Modelado, ya que les ayudará a capturar la idea del sistema requerido, para luego comunicarla a los involucrados en el proyecto. Esta tarea se lleva a cabo en las etapas de análisis y diseño, utilizando simbología y diagramas UML con el objeto de modelar el sistema.
Modelar el sistema utilizando los diagramas de UML, significara en definitiva contar con documentos que plasman el trabajo de capturar la idea para la posterior evolución del proyecto. El cliente podrá entender el plan de trabajo de los especialistas y señalar cambios si no se captó correctamente alguna necesidad; o bien, indicar cambios sobre la marcha del proyecto. A su vez, los especialistas encargados del desarrollo generalmente trabajaran en equipo, por lo que cada uno de ellos podrá identificar su trabajo particular y el general a partir de los diagramas UML.
UML proporciona las herramientas para organizar un diseño sólido y claro, que comprendan los especialistas involucrados en las distintas etapas de la evolución del proyecto, y por qué no para documentar un anteproyecto que será entregado al cliente.
El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos.
La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Recordemos que un modelo es una representación simplificada de la realidad; el modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo implementar dicho sistema.

UML

El éxito de un proyecto depende en gran medida de un buen plan y de una buena organización. En vista de ello, se hace necesario contar con herramientas eficientes para desarrollar sistemas.
La utilización del UML como herramienta de diseño de sistemas no se trata de una aventura sin precedentes, sino por el contrario, UML es actualmente un estándar que ha llegado a hacerse popular por la aceptación que ha tenido y la efectividad que ha representado para muchos analistas y diseñadores de sistemas.
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real.
UML es una consolidación de muchas de las notaciones y conceptos más usados orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.
UML preescribe una notación estándar y semánticas esenciales para el modelado de un sistema orientado a objetos. Previamente, un diseño orientado a objetos podría haber sido modelado con cualquiera de la docena de metodologías populares, causando a los revisores tener que aprender las semánticas y notaciones de la metodología empleada antes que intentar entender el diseño en sí. Ahora con UML, diseñadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseños de los otros.
UML es, probablemente una de las innovaciones conceptuales en el mundo tecnológico del desarrollo de software que más expectativas y entusiasmos haya generado en muchos años, comparable a la aparición e implantación de los lenguajes COBOL, BASIC, PASCAL, C++, y más recientemente Java o XML. Además todas las expectativas se han cumplido y han generado a su vez nuevas expectativas. UML es ya un estándar de la industria, pero no solo de la industria del software sino, en general, de cualquier industria que requiera la construcción de modelos como condición previa para el diseño y posterior construcción de prototipos.
UML ha nacido como un lenguaje, pero es mucho más que un lenguaje de programación. Aunque en su génesis se parece a C++ o a Java, en realidad se ha diseñado o construido un lenguaje que ha nacido con una madurez muy acentuada si se le compara, incluso, con los últimos desarrollos de HTML, Java y XML, los lenguajes por excelencia del mundo Internet.

Ventajas

UML se ha diseñado realizando combinaciones de una gran cantidad de estándares, si bien se rige a través de tres metodologías procedentes de la colaboración de los tres creadores de UML, J. Rumbaugh, G. Booch e I. Jacobson, así como del análisis y estudio de alrededor de 20 métodos estándares que a su vez se han integrado en otro estándar, en este caso, UML; esta fue una gran iniciativa de los tres creadores que pusieron las especificaciones de UML a la consideración de la comunidad informática mundial, antes de su publicación. El diseño de UML ha sido completo desde el principio, al contrario que HTML que ha cambiado gradualmente, de forma que XML ha tratado de resolver los problemas de HTML y Java, que sigue todavía en el proceso de estandarización con la nueva versión 2.0. Al contrario que HTML/XML que son lenguajes de marcación (markup), UML es un lenguaje para modelar, que es el proceso que emplean los ingenieros de software antes de pasar a su construcción, al igual que sucede con cualquier producto manufacturado o fabricado en serie.
UML ayuda al usuario a entender la realidad de la tecnología y la posibilidad de que reflexione antes de invertir y gastar grandes cantidades en proyectos que no estén seguros en su desarrollo, reduciendo el coste y el tiempo empleado en la construcción de las piezas que constituirán el modelo.
Sin embargo desde el punto de vista puramente tecnológico, UML tiene una gran cantidad de propiedades que han sido las que, realmente han contribuido a hacer de UML el estándar de facto de la industria que es en realidad. Algunas de las propiedades de UML como lenguaje de modelado estándar son:

   ·         Concurrencia: es un lenguaje distribuido y adecuado a las necesidades de conectividad, actuales y futuras.
   ·         Ampliamente utilizado por la industria desde su adopción por OMG.
   ·         Reemplaza a decenas de notaciones empleadas con otros lenguajes.
   ·         Modela estructuras complejas.
   ·         Las estructuras más importantes que soportan tienen su fundamento en las tecnologías orientadas a objetos, tales como objetos, clase, componentes y nodos.
   ·         Emplea operaciones abstractas como guía para variaciones futuras añadiendo variables si es necesario.
  ·         Comportamiento del sistema: casos de uso, diagramas de secuencia y de colaboraciones, que sirven para evaluar el estado de las máquinas.

Algunos beneficios: Dos grandes empresas, Rational Software (empresa creadora de UML y de Rational Case) y Commerce One (líder mundial en soluciones globales de comercio electrónico) acordaron colaboración mutua para crear la especificación de la primera versión UML para la industria, que siga las especificaciones XML para el desarrollo del comercio electrónico; es decir, se han unido dos grandes empresas con el objeto de construir un método estándar que reduzca drásticamente el tiempo de desarrollo e incremente la calidad de las aplicaciones de comercio electrónico basadas en XML.
Se trata de alcanzar la máxima de que el cambio rápido de Internet ha creado una paradoja para el desarrollo del conocido como e-software para las organizaciones que requieren la entrega de software de un modo mucho más rápido pero conservando una calidad alta. La versión de UML para especificaciones XML está disponible en el sitio web de Commerce One (www.commerceone.com/xml/sox/index.html) y en el sitio web de Rational (www.rational.com/uml/index.itmpl).
Otra gran ventaja que está ofreciendo UML se refiere al desarrollo de aplicaciones globales para la web, no solo para comercio electrónico. UML está siendo utilizado por los gerentes de proyectos, desarrolladores y arquitectos de la web que aplican técnicas orientadas a objetos para construir aplicaciones web robustas, escalables y eficientes. UML permite a los desarrolladores modelar sus aplicaciones web como parte de un sistema completo y la lógica de negocios que se debe reflejar en las aplicaciones.
UML permite modelar sistemas de información, y su objetivo es lograr modelos que, además de describir con cierto grado de formalismo tales sistemas, puedan ser entendidos por los clientes o usuarios de aquello que se modela. Para ello es muy importante que el idioma en el que estén las palabras y textos que aparezcan en tales modelos sea el propio de estas personas.
En cualquier comunidad hispanohablante, leer “Pedido” aclara más que ver “Order”, y leer “Hereda de” más que “inherits”, porque los términos en español evocan directamente al lector una semántica cercana a la que se pretende con su uso en el modelo, y esa evocación es precisamente la razón por la cual fueron elegidos los términos ingleses de ese modelo. Como lenguaje de modelado y descripción, UML permite que todo el modelo se cree en español o en cualquier otro lenguaje. Sin embargo, el inglés ha sido el idioma nativo en la creación de UML, por lo que las palabras clave incorporadas en el propio UML están en inglés. Para el cliente y el equipo de desarrollo, esto no es un problema, pueden usar los términos traducidos que entenderán mejor; pero cuando se quiere usar una herramienta de ingeniería de software que entiende semántica UML, ésta esperará encontrar términos ingleses para entender lo que quiere decir, por ejemplo, esa línea o figura.

Características generales

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se usa para especificar, visualizar y documentar artefactos de un sistema de software. Captura decisiones y conocimiento sobre los sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener y controlar la información sobre los sistemas que se deben construir. Está pensado para usarse con todos los métodos de desarrollo, etapas del ciclo de vida, dominios de aplicación y medios. El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar. UML incluye conceptos semánticos, notación y principios generales. Tiene partes estáticas, dinámicas, de entorno y organizativas. Está pensado para ser utilizado en herramientas interactivas de modelado visual que tengan grandes generadores de código así como generadores de informes. La especificación de UML no define un proceso estándar pero está pensado para ser útil en un proceso de desarrollo iterativo. Pretende dar apoyo a la mayoría de procesos orientados a objetos.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo. La estructura estática define los tipos de objetos importantes para un sistema y para su implementación, así como las relaciones entre los objetos. El comportamiento dinámico define la historia de los objetos en el tiempo y la comunicación entre objetos para cumplir sus objetivos. El modelar un sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo para diferentes propósitos.
UML también contiene construcciones organizativas para agrupar los modelos en paquetes, lo que permite a los equipos de software dividir grandes sistemas en piezas de trabajo, para entender y controlar las dependencias entre paquetes, y para gestionar las versiones de las unidades del modelo, en un entorno de desarrollo complejo. Contiene construcciones para representar decisiones de implementación y para elementos de tiempo de ejecución en componentes.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguajes de programación, así como construir modelos por ingeniería inversa a partir de programas existentes. UML es un lenguaje altamente formal pensado para probar teoremas. Hay varios lenguajes de ese tipo, pero no son fáciles de entender ni de usar para la mayoría de los propósitos. UML es un lenguaje de modelado de propósito general; para dominios especializados, tales como la composición de IGU, diseño de circuitos VLSI, o inteligencia artificial basada en reglas, podría ser más apropiada una herramienta especializada con un lenguaje especial. UML es un lenguaje de modelado discreto. No se creó para modelar sistemas continuos como los basados en ingeniería y física. UML quiere ser un lenguaje de modelado universal, de propósito general, para sistemas discretos, tales como los compuestos por software, firmware o lógica digital.
El UML soporta un conjunto rico en elementos de notación gráficos. Describe la notación para clases, componentes, nodos, actividades, flujos de trabajo, casos de uso, objetos, estados y cómo modelar la relación entre esos elementos. El UML también soporta la idea de extensiones personalizadas a través elementos estereotipados.
El UML provee beneficios significativos para los ingenieros de software y las organizaciones al ayudarles a construir modelos rigurosos, trazables y mantenibles, que soporten el ciclo de vida de desarrollo de software completo.
El UML unido a una gestión de calidad, evita malos entendidos  y  entrega ciertas precauciones en la evolución y mantención de programas. Especialmente en lo referente a los requerimientos asociados al levantamiento y diseño funcional de un sistema. En efecto, por ejemplo con los Clientes Dilema, quienes nos podrán hacer pensar que el cambio que están solicitando es pequeño, cuando detrás de la petición existe una enorme cantidad de tareas relacionadas al requerimiento.

Referencias:

El lenguaje unificado de modelado. Manual de referencia.
J. Rumbaugh, I. Jacobson, G. Booch
Pearson Educación S.A., Madrid 2000

Monografías.com
Ejemplos de diagramas UML, interfaces gráficas de usuario, y usos del UML en la ingeniería inversa
Jaime Oswaldo Montoya Guzmán - webmaster@jaimemontoya.com

Modelado de Sistemas com UML
por Popkin Software and Systems

El Lenguaje de Modelado Unificado

Proyectos UML
Diagramas de clases y aplicaciones
JAVA en NetBeans 6.9.1
Ubaldo José Bonaparte
Editorial de la Universidad Tecnológica Nacional
Argentina