Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Asignatura: Metodologia del software, Profesor: Tona Mozota, Carrera: Enginyeria tècnica en informàtica de sistemes, Universidad: URL
Tipo: Apuntes
1 / 48
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
Capítulo: 5. UML
El contenido de este documento es sólo una tabla de contenidos con la relación de imágenes y direcciones de internet vistas o recomendadas en el curso. Se recomienda estudiar los temas directamente de las fuentes citadas en la bibliografía.
Unified Modeling Language (UML)
Capítulo: 5. UML
5. UML
¿Qué es? [Fowler]
El UML o Unified Modeling Language es una familia de notaciones gráficas apoyadas en una meta modelo que ayuda a describir y diseñar sistemas de software y en particular aquellos sistemas construidos siguiendo un estilo orientado a objetos.
La OMG (Object Management Group) lo define como un lenguaje para especificar, visualizar, construir y documentar los artefactos de los sistemas software así como para el modelado del negocio y otros sistemas no software.
Historia [Fowler]
Hacia principios de los años 80 aparecieron los primeros lenguajes orientados a objetos (Smalltalk, C++, ...). A finales de los 80 y principios de los 90 aparecieron una serie de libros clave que ofrecían lenguajes de modelado gráfico orientado a objetos, cada uno con muchos adeptos. Eran libros de Booch (metodología BOOCH ), Coad, Jacobson (metodología Objectory ), Odell, Rumbaugh (metodología OMT ) y otros. Aunque no había excesivas diferencias conceptuales entre ellos, las notaciones eran diferentes y ello confundía a los clientes y a los desarrolladores cuando trabajaban entre sí.
Jim Rumbaugh se unió con Grady Booch en Rational y el 1995 tuvieron la versión 0.8 de UML. Fue el primer gran paso hacia el UML. Más tarde contrataron a Ivar Jacobson, que se unió a Rational (“ Los tres Amigos ”).
El OMG (Object Management Group) presionó para conseguir la interoperabilidad del resultado, que las herramientas CASE pudieran compartir modelos.
El 1997 se liberó la versión 1.0 de UML, desde entonces se han ido desarrollando las versiones 1.1, 1.2 ... 1.5 , pero el mayor cambio ha sido el cambio a la versión 2.0 el año 2003.
Hay que aclarar que aunque el Rational Unified Process procede también de Rational y el RUP soporta UML, UML no es una parte de RUP.
Diferentes usos del UML [Hamilton y Miles]
[Fowler]
Según Martin Fowler y Steve Mellor son 3 las formas en las que principalmente se utiliza el UML:
Capítulo: 5. UML
Boceto El más utilizado. Es informal y dinámico. Se trata de un uso muy selectivo en cuanto al contenido, sólo aborda una parte de aquello que luego se implementará en código (partes importantes). Se usa, por ejemplo, para discutir en un grupo de trabajo, para comunicar ideas y alternativas. No se trata de hacer una especificación exhaustiva de aquello que se va a codificar sino las partes que en ese momento se consideran más importantes y sin abrumar con detalles. Se puede utilizar tanto en ingeniería directa (generar el diagrama y luego generar el código a partir del diagrama) como en ingeniería inversa (extraer el diagrama a partir del código). Se usa en pizarras o quizás en documentos, pero documentos cuyo objetivo es la comunicación selectiva (no exhaustiva) con el equipo y no la total completitud de la información.
Blueprint La principal diferencia entre el boceto y el blueprint es la completitud. Se usa por diseñadores cuyo objetivo es generar una documentación detallada para que un programador pueda traducirla a código. Los blueprints deben de ser documentos que permitan que la codificación sea una actividad sencilla, sin la necesidad de que el programador que los reciba deba realizar ningún diseño extra. “ Esto es exactamente lo que debes programar ”. Se pueden usar los blueprints , por ejemplo, para dar una explicación exhaustiva y detallada sobre las interfaces entre los subsistemas pero luego dejar la implementación de esos subsistemas a los programadores. Quizás esa implementación se pueda sugerir con bocetos UML. Así se usa al menos en los puntos críticos.
Los bocetos permiten e xplorar y los blueprints permiten definir.
Lenguaje de programación
A medida que analistas y diseñadores usan más y más el UML el paso a código fuente se hace más mecánico. Se debe automatizar esa generación de código. El siguiente paso es utilizar realmente el UML como un lenguaje de programación, trivializando la generación de código. Este uso de UML como un lenguaje de programación requiere unas herramientas CASE avanzadas. Desaparece el concepto de ingeniería directa e inversa pues el UML es el código fuente.
Capítulo: 5. UML
Capítulo: 5. UML
Los diagramas marcados son aquellos que estudiaremos durante el curso.
fuente: [Fowler]
UML legal Simplemente llamaremos UML legal o bien formado o normativo a aquellos modelos definidos utilizando una notación UML bien formada siguiendo la especificación.
A no ser que uses UML como lenguaje de programación, lo más importante es hacerse entender. En el uso práctico de UML (no en esta asignatura!) como boceto o como blueprints no es estrictamente necesario ajustarse a la norma, los diagramas no tienen porqué ser estrictamente normativos.
[Fowler]
Antes de simplemente presentar el diagrama de casos de uso hay que conocer qué son los casos de uso. El UML sólo habla de cómo hacer los diagramas pero no sobre cómo identificarlos ni sobre su forma textual. Esta forma textual a menudo es más útil que los diagramas.
Técnica para capturar los requerimientos funcionales de un sistema. Funcionan describiendo las interacciones típicas entre los usuarios del sistema y el sistema en sí.
Se usa durante la recogida y análisis de los requerimientos. También durante la validación.
5.2.1.1 Escenario y caso de uso Un escenario es una secuencia de pasos que describen una interacción entre un usuario y un sistema. Éste es un ejemplo:
“ El usuario visualiza el catálogo y añade los elementos deseados a una cesta de la compra. Cuando el cliente quiere pagar, describe la información de envío y de pago y confirma la compra. El sistema verifica la autorización de la tarjeta de crédito y confirma la compra tanto inmediatamente como con un e-mail. ”
Se trata de algo que puede ocurrir en el sistema. Quizás haya posibilidades de variaciones en ese escenario o quizás errores en algún paso pero sea como sea en todos ellos el objetivo era el mismo : “ Comprar un producto ”.
Un caso de uso es un conjunto de escenarios unidos por el mismo objetivo.
5.2.1.2 Actores (roles) En la terminología de Casos de Uso los usuarios son llamados “ actores ”. Un actor es en general una entidad que utiliza un caso de uso. El sistema puede ser un actor.
Un actor puede intervenir en diversos casos de uso. Y una misma persona puede ser diferentes
Capítulo: 5. UML
1
Ejemplo:
Fuente: [Fowler]
Los pasos que recomienda Martin Fowler:
● De entre todos los escenarios que componen un caso de uso se elige uno de ellos el de escenario de éxito principal ( main success scenario ). ● A continuación se escribe este e.de e. principal como una secuencia de pasos numerados ● Se escribe el resto de los escenarios como extensiones. Tanto pueden ser variaciones (con condiciones) como errores. ● Cada caso de uso tiene un actor principal. Que es quien pide un servicio al sistema. ● Puede haber más actores, con los que comunique el sistema, por ejemplo. Son los actores secundarios. ● Los pasos deben mostrar las intenciones del actor , NO los mecanismos que usa para ello. Ni se habla sobre interfaces. ● Una extensión dentro de un c.u. tiene una condición que lleva a diferentes interacciones de aquéllas del escenario de éxito principal. Se debe decir el paso en el que la condición se detecta y una descripción corta de esa condición. Se numeran los pasos, igual que en el escenario principal.
Capítulo: 5. UML
1
Se puede añadir más información:
● precondiciones : aquello que el sistema debe asegurar que es cierto antes (no hace falta verificarlo dentro del c.de u.) ● postcondiciones ( guarantees ) : aquello que el sistema debe asegurar que es cierto después ● activadores ( triggers ) : eventos que inician los casos de uso
Hay que recordar que el diagrama no debería ser más que un apoyo a la representación textual de los c.de u., que es lo realmente importante. Suelen ser fáciles de entender para los clientes y usuarios.
5.2.2.1 Elementos Actor :
Caso de uso :
Capítulo: 5. UML
1
Fuente: [Hamilton]
5.2.2.3 Relaciones entre casos de uso [Larman]
Es mucho más importante escribir bien los casos de uso que dedicar tiempo a buscar relaciones entre casos de uso.
Estas relaciones se marcan con líneas discontinuas y con estereotipos (“ <
a) Relación de inclusión (“ <
Es habitual que haya comportamientos parciales comunes en varios casos de uso. Por ejemplo, en un sistema en el que se pueden comprar productos y también se pueden alquilar, si tanto en un caso como en el otro se hará el pago con tarjeta de crédito, aunque se trate de casos de uso diferentes ambos compartirán esa funcionalidad. Se dice que tanto la compra del producto como el alquiler del producto incluyen el pago con tarjeta de crédito.
En el texto de casos de uso esto se puede representar nombrando el sub-caso de uso incluido dentro de un paso y subrayándolo (por ejemplo).
Ejemplo de [Fowler]:
y ese texto en subrayado, si fuera una versión electrónica del texto de casos de uso sería un enlace a la descripción de ese caso de uso.
En el diagrama:
Capítulo: 5. UML
1
Se especifica con una flecha intermitente marcada con “ <
En programación orientada a componentes los includes permiten identificar los subsistemas que luego podrán ser implementados con componentes.
b) Relación de extensión (“ <
Si constantemente aparecen nuevas extensiones a un caso de uso puede ser difícil su mantenimiento. Para añadirle nuevas funcionalidades sin modificar su texto se puede extender el caso de uso original.
Ejemplo: Disponemos de un caso de uso “Procesar venta”, el caso de uso base, completo y preferimos no modificarlo. La venta con vale-regalo es una extensión de este caso de uso base:
Ejemplo de [Larman]: UC1: el base y UC24: el que extiende
Capítulo: 5. UML
1
Un caso de uso que es incluido no será llamado directamente por un actor. En cambio, un caso de uso que extiende a otro sí puede ser llamado por un actor.
5.2.2.4 Ejemplos
Capítulo: 5. UML
1
Fuente: http://www.agilemodeling.com/artifacts/useCaseDiagram.htm
Capítulo: 5. UML
1
[Fowler], [Hamilton]
Técnica para describir lógica procedural ( procedural logic ), procesos de negocio y workflow. Soportan comportamientos paralelos. Uno de los diagramas que más ha cambiado con UML 2.
Capítulo: 5. UML
2
