El UML (Lenguaje Unificado de Modelado) es una de las herramientas ms emocionantes en el mundo actual de desarrollo de sistemas.

Permite a los creadores de sistemas crear diseos que capturen sus ideas en una forma convencional y fcil de comprender para comunicarlas a otras personas. El UML ayuda a capturar la idea de un sistema para comunicarla a quin est involucrado en su proceso de desarrollo; esto se lleva a cabo mediante un conjunto de smbolos y diagramas

Es necesario contar con un plan bien analizado. Un cliente tiene que comprender qu es lo que har un equipo de desarrolladores.

Adems tiene que ser capaz de sealar cambios si no se han captado claramente sus necesidades o cambia de opinin. Cada uno de los miembros del equipo de desarrollo tiene que saber qu lugar toma su trabajo en la solucin final.

Conforme aumenta la complejidad del mundo, tambin aumenta la complejidad de los sistemas. Diversas piezas de software y hardware que se comunican a grandes distancias mediante una red, vinculada a bases de datos. Si desea crear sistemas que lo involucren con este nuevo milenio, Cmo manejar tanta complejidad?

La clave est en organizar el proceso de diseo de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan y estn de acuerdo con l. El UML proporciona tal organizacin.

As como el arquitecto muestra un anteproyecto a la persona que lo contrat, los desarrolladores debemos mostrar el plan de diseo al cliente. Tal plan de diseo es el resultado de un cuidadoso anlisis de las necesidades del cliente. Con la finalidad de reducir el perodo de desarrollo, es necesario contar con un plan de diseo slido.

El UML es la creacin de Grady Booch, James Rumbaugh e Ivar Jacobson. A mediados de los aos noventa empezaron a intercambiar ideas entre s y decidieron desarrollar su trabajo en conjunto. Conforme diversdos corporativos vieron que el UML era til a sus propsitos, se conformo un consorcio del UML, entre sus miembros se encuentra DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments y Rational El UML ha llegado a ser el estndar de facto en la industria del software, y su evolucin contina

El UML est compuesto por diversos elementos grficos que se combinan para conformar diagramas. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. El modelo UML de un sistema es similar a un modelo a escala de un edificio junto con la interpretacin del artista del edificio.

Un modelo UML describe lo que supuestamente har un sistema, pero no dice como implementar dicho sistema.

Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama Diagrama

de de de de de de de de de

clases objetos casos de uso Estados secuencias actividades colaboraciones componentes distribucin

Es una descripcin de las acciones de un sistema desde el punto de vista del usuario. Esto es importante si queremos que el sistema sea utilizado por la gente en general (no solo por expertos en computacin) Con una coleccin de casos de uso se puede hacer un bosquejo del sistema en trminos de lo que los usuarios intenten hacer con l. Es una coleccin de escenarios iniciados por una entidad llamada actor (una persona, un componente de hardware u otro sistema). Un caso de uso debera dar por resultado algo de valor ya sea para el actor que lo inici o para otro.

Un caso de uso es una descripcin de los pasos o las actividades que debern realizarse para llevar a cabo algn proceso. Los personajes o entidades que participarn en un caso de uso se denominan actores. Wikipedia

La entrevista directa con el usuario es la mejor tcnica para derivar casos de uso. Es una buena idea entrevistar a los usuarios en grupo. Les pedir a los usuarios que indiquen todo lo que ellos haran con el sistema que usted disear.

El objetivo es derivar un conjunto candidato de casos de uso y todos los posibles actores.

Cada caso de uso es una coleccin de escenarios y cada escenario es una secuencia de pasos. Tales pasos no aparecen en el diagrama, ya que la claridad es clave en todo diagrama y adjuntar notas a cada caso de uso podra volverlo confuso. Dicha secuencia de pasos, ser parte de un documento de diseo que el cliente y el equipo de diseo tomarn como referencia.

Cada diagrama tendr su propia pgina, cada escenario de caso de uso tendr su propia pgina, donde se listar a modo de texto:
El actor que inicia el caso de uso Condiciones previas para el caso de uso Pasos en el escenario Condiciones posteriores cuando se finaliza el escenario. El actor que se beneficia del caso de uso.

Existen varias formas en que los casos de uso se pueden relacionar entre s. Inclusin Extensin Generalizacin Agrupacin

Una de ellas, la inclusin, permite volver a utilizar los pasos de un caso de uso dentro de otro. Esto es cuando siempre se tiene que incluir un caso dentro de otro. No es opcional.

La otra, la extensin, permite crear un caso de uso mediante la adicin de pasos a uno existente. Esto no siempre tiene que ocurrir habr ocasiones en que no ser necesario usar otro caso de uso dentro de uno que ya existe. Es opcional o condicional

Las clases pueden heredarse entre s y esto tambin aplica a los casos de uso. En la herencia de los casos de uso, el caso de uso secundario hereda las acciones y significado del primario, y adems agrega sus propias acciones. Puede aplicar el caso de uso secundario en cualquier lugar donde aplique el primario.

En ciertos diagramas de casos de uso, podra tener varios casos de uso que querr organizar. Esto puede ocurrir cuando un sistema consta de varios subsistemas. Otra posibilidad sera cuando entrevista a usuarios para obtener los requerimientos de un sistema. Cada requerimiento podra ser representado como un caso de uso por separado. Necesitar alguna forma de ordenar los requerimientos por categoras.