La perspectiva conceptual se utiliza rara vez, salvo para analizar el dominio, aunque muchas veces un glosario y un diagrama a mano alzada bastan para comunicarnos. Modelos de UML 2.
Por ejem- plo, una empresa tiene clientes, proveedores, empleados; los empleados, que tienen un legajo y un sueldo, se asignan a proyectos; los proyectos pueden ser internos o externos; los segundos tienen clientes, mientras que los primeros, no; los proyectos externos tienen costo y precio de venta, mientras que los internos solamente costo, etc. De tanto en tanto, los diagramas se combinan, como en el caso los de paquetes y de clases, o en los de secuencia y de actividades, entre otros.
Algo parecido pasa con el diagrama de tiempos. El diagrama de casos de uso, a pesar de su popularidad, brinda una utilidad escasa visto en forma aislada. Y hay situaciones intermedias. Por ejemplo, para indicar. No obstante, todo proyecto de mantenimiento suele involucrar las mismas actividades que un nuevo proyecto completo de desarrollo de software. Cada etapa corresponde a una actividad de desarrollo, y es efectuada por un grupo de personas especializadas en esa tarea, que generan un conjunto de documentos como cierre de la etapa.
Lo que ocurre es que el ciclo de vida en cascada impone una rigidez a los cam- bios de requisitos, tan habituales en los proyectos de desarrollo de software. Finalmente —y tal vez no menos importan- te— provoca proyectos largos por la imposibilidad de superponer actividades sobre partes diferentes del producto.
Como respuesta a la rigidez del modelo en cascada fueron surgiendo los ci- clos evolutivos o incrementales. Y coadyuvan a disminuir los riesgos de los proyectos. La primera respuesta al ciclo en cascada fue plantear cascadas parciales, que se realizaban en forma iterativa.
Esta modalidad se denomina desarrollo in- cremental o en espiral. Con lo que acabamos de ver ya hemos demostrado que los procesos de desarrollo son independientes del uso, o no, de UML. La idea de que se puede usar en el marco de cualquier proceso de desarrollo es indiscutible. El desacuerdo no pasa por la imposibilidad, sino por la conveniencia, o no, de estos enfoques.
Finalmente, UML no es un lenguaje que se utilice siempre de la misma ma- nera. Para organizar mejor el problema, partamos de unos requisitos de muy alto ni- vel, tal como suelen ser enunciados por un cliente en una charla informal. Una plantilla puede ser un documento en blanco. Scrum estructura el desarrollo del producto en ciclos o iteraciones que denomina Sprints. El Product Owner es quien, sobre la base de los requisitos planteados por clien- tes y usuarios, elabora la lista de requisitos, denominada Product Backlog, y les asigna prioridades.
Se parte de requisitos para generar tareas. Durante un Sprint, no se pueden cambiar los integrantes de un grupo de trabajo ni el Sprint Backlog. El Scrum Master hace de moderador de estas reuniones. Separamos el desarrollo en actividades sola- mente para poder analizar mejor los usos de UML en las distintas disciplinas. De todas maneras, no seamos excesivamente optimistas. No vamos a resolver el problema completo, ni mucho menos.
Los funcionales son descripciones de lo que el sistema hace o debe hacer. Es posible que sirva de contrato entre el equipo de desarrollo y los interesados en el mismo.
Los actores son los roles de los agentes externos que necesitan algo del sistema. Por ejemplo, el empleado de una empresa cliente de FollowScrum puede ser, a la vez, administrador y usuario de reportes, pero como actores se trata de dos roles diferentes.
En el cuadro 4. Queda una nueva empresa activa en el sistema. El usuario solicita dar de alta una nueva empresa S1. El sistema muestra los datos a ser ingresados S1 : a. Flujo Normal c.
El usuario completa los campos S1. El sistema valida los datos. E1 a E4. El sistema guarda los datos en la base de datos.
El sistema genera un usuario y una clave para el administrador del cliente. Finaliza el caso de uso. El sistema pregunta al usuario si desea abandonar. Flujos S1. No se cargaron todos los datos requeridos.
Ya hay cargada una empresa con el mismo nombre. La plantilla puede ser la que acabamos de usar o alguna parecida. En general, el nombre debiera consistir en el objetivo del actor principal o iniciador en el caso de uso. Escenarios Las instancias de casos de uso o de user stories se denominan escenarios. El sistema no cambia la base de datos ni genera un usuario y una clave para el administrador del cliente. En estas situaciones, el analista puede sintetizar distintos esce- narios surgidos de conversaciones con los usuarios y formalizar un caso de uso.
Y, por sobre todas las cosas, para validar los requisitos con el cliente. Como ya dijimos, un actor puede representar una persona o un sistema externo. Sin embargo, esto no es muy usual y puede llevar a confusiones sobre lo que es un actor y lo que no lo es.
Y tal vez sea una de sus grandes fuer- zas. Sin embargo, si el sistema se construye en forma realmente incremental, y no se pretende conocer todo el alcance al comenzar, esto deja de ser cierto.
No es que no sirva para nada, sino que se generan expectativas superiores a sus posibilidades. Notemos que eso mismo se puede lograr con user stories. De todas maneras, no hay que exagerar su utilidad. Para ello, son de gran utilidad los diagramas de actividades. Se puede mostrar en el diagrama el paso del objeto m por diversos estados.
Tal vez el anterior no sea un buen ejemplo. Destaca en ellos la simplicidad de modelado de concurrencia conceptual.
No obstante, recordemos que los casos de uso deben ser bien comprendidos por todos los interesados, incluyendo especialistas de negocio y clientes. Casi todos los cambios han sido mejoras reales, aunque el cambio permanente ha hecho que muy pocos profesionales utilicen todos los aspectos de este diagrama. Hay ocasiones en las que puede ser conveniente abrir una actividad en varias sub-actividades, o reunir algunas actividades en una actividad compuesta.
Muestra datos para ingresar. Y cada usuario debe estar asociado a una y solo una empresa. No es que Catalina deje de existir si deja Software del Sur: lo que ocurre es que, desde el punto de vista del sistema analizado, no tiene sentido seguir considerando un usuario si deja una de las empresas clientes del sistema.
Por ejemplo, en FollowScrum tenemos usuarios administradores y usuarios de clientes. Contiene una serie de conceptos que requieren ser entendidos para avanzar en el desarrollo. Como todo modelo, tiene elementos estructurales y otros de comportamiento. Para los aspectos de comportamiento, puede usarse el diagrama de actividades, que hemos visto anteriormente. En cuanto a los elementos estructurales, es de gran ayuda el diagrama de clases.
El diagrama que acabamos de realizar es bastante rico, aunque sus elementos no son tantos. M, o mediante el uso del asterisco, que implica varios. Por ejemplo, si una cardinalidad se expresa como Por eso se suele asumir 1 cuando la cardinalidad no se indica, aunque esto no es normativo.
Por ejemplo, en nuestro diagrama, estamos indicando que un Usuario puede ser un Administrador o un Usuario Cliente. Eso mismo pasa con varios de los conceptos representados en el diagrama anterior. Esto es: si deja de existir el todo, dejan de existir las partes, pues no tienen existencia independiente. Notemos que los nombres de roles se tornan fundamentales para poder leer el diagrama.
De todas maneras, hay que tener cierto cuidado en estos casos. Por ejemplo, una persona en particular puede ser Scrum Master en un proyecto y Team Member en otro. Por eso, en muchos casos, no hay mejor herramienta que un comentario en forma de texto agregado al diagrama.
UML nos provee comentarios mediante un elemento que llama nota. Por eso mismo es que no hemos demostrado mucha resistencia a denominarlas sim- plemente clases. Pero es importante destacar que son clases conceptuales, no clases software. Hay cuestiones adicionales que se pueden modelar en los diagramas de casos de uso. Por todo esto, si se desea usar diagramas de casos de uso, hay que tener es- pecial cuidado en no utilizar relaciones complejas si no van a ser entendidas por los interlocutores.
Y por sobre todas las cosas, recordemos siempre el valor de la simplicidad, evitando los diagramas excesivamente complejos. Los prototipos terminan siendo fundamentales para todos aquellos usuarios que no saben lo que desean en detalle hasta que no lo ven funcionando. Por eso, orientar a todos los interesados es parte de nuestro trabajo. Si bien todo esto no siempre es demasiado consciente, es lo que subyace a todo el paradigma. Todo objeto pertenece a una clase o, como decimos habitualmente, es instancia de una clase.
En ese sentido, una clase es un conjunto de objetos. Cada objeto particular es una instancia de la clase. Hay ocasiones en las que necesitamos modelar un objeto sin que nos interese conocer exactamente su clase. Otras en las que nos interesa representar una instancia. Los objetos, en un sistema, pueden relacionarse con otros objetos. Pero hay muchas variantes adicionales, que veremos a lo largo del libro. Las responsabilidades que tiene un objeto son aquellas cosas que espera- mos de ellos.
Tal vez sea la mejor. El comportamiento es un ingrediente fundamental de los objetos y las clases. En ese caso, ni siquiera es necesario que los participantes sean objetos. Si no lo fueran, lo que se suele hacer es no subrayar los nombres.
Se puede modelar toda la vida del objeto o su existencia dentro de un escenario particular. Como vemos, se parece al diagrama de actividades. De hecho, en UML 1 se con- sideraba al diagrama de actividades como un caso particular de diagrama de estados.
Sin embargo, esto ha cambiado en UML 2. De todas maneras, las tres partes de la leyenda son opcionales, y puede no co- locarse ninguna.
Como vemos en el diagrama, un estado puede agrupar varios estados internos, como ocurre entre Proyecto y los estados Inicio, Fase iterativa y Cierre. Como vemos, el diagrama de estados es un modelo sencillo. Por eso mismo, hay que tratar de que permanezca simple, cuidando el nivel de detalle, sin hacer diagra- mas muy complejos.
Otro miembro de la familia es el diagrama de secuencia. Nosotros usamos este recurso con el retorno del mensaje terminar. En UML 1 el subrayado era obligatorio. El cuadro que rodea las acciones respectivas es un marco.
UML permite que cualquier diagrama se enmarque con un marco con nombre. En este libro, no lo hemos hecho, porque casi siempre empeora la legibilidad. Figura 5. Pero, a la vez, dice que es una variante de diagrama de actividades. Los valores inter- nos se guardan en variables que habitualmente se denominan atributos o —menos habitual— campos. Hay atributos que no representan el estado de los objetos, sino de la clase como un todo.
Los llamamos atributos de clase. Todo puede ser. Ahora bien, en cuanto al modelado, es importante separarlas, ya que los requisitos se modelan con el lenguaje del cliente, a modo de contrato entre cliente y desarrollador,. Respecto del usuario, lo hemos representado con el mismo esquema de persona que se usa para los actores en los diagramas de casos de uso. La diferencia entre biblioteca y framework es muy sutil para muchos profesiona- les.
Por el momento, vamos a quedarnos con la belleza de lo simple. Los componentes se suponen partes reemplazables del sistema, que se pueden adquirir y versionar. Los diagramas de componentes de UML muestran componentes y sus comuni- caciones mediante interfaces.
De todas maneras, es dudosa la utilidad real de representar puertos, sobre todo si no se necesita darles un nombre, como en nuestro caso. NET, programas ejecutables, etc. En el cuadro 6. Cualquier archivo no ejecutable. Diagramas de despliegue No existen sistemas de software que no necesiten hardware para ejecutarse.
UML nos permite representar nodos de hardware en los cuales podemos desplegar artefactos en los diagramas de despliegue. Figura 6. Los distintos tipos de nodos pueden denotarse con estereotipos. Hay algunas confusiones bastante generalizadas en el uso de diagramas de despliegue.
Muchas herramientas —y, por lo tanto, los profesionales que las usan— permiten usar artefactos en el marco de diagramas de componentes y no en los de despliegue.
El diagrama de despliegue es una herramienta interesante y relativamente sim- ple. Es un diagrama interesante cuando el despliegue no es trivial. Sin embargo, es de utilidad si se quieren mostrar componentes intercambiables y sus interfaces. Sin embargo, no hay construc- ciones nuevas que nos interesen sobre las que ya vimos, salvo el concepto de pseudo- estado de historia.
Hay muchos otros pseudo-estados que se pueden representar. Por ejemplo, en UML 2, se pueden modelar pseudo-estados de entrada para indicar inicios repetiti- vos del ciclo de estados. Ambos son estados internos. Como se ve, no hay muchas novedades respecto de los diagramas de secuencia que ya conocemos. Cada uno de los lectores es libre de sacar sus propias conclusiones. Ya hemos visto bastante de diagramas de clases.
Otras no tanto, como los nombres de asociaciones. Por ejemplo, el atributo legajo es de tipo int, mientras que sueldoBruto es de tipo double. Esto es: el elemento es visible para cualquier otro elemento para el que la clase sea visible. Desde ya, esto no tiene sentido en Java o Smalltalk. Entonces, decimos que la clase Administrador hereda de la clase Usuario.
A la inversa, decimos que la clase Usuario es ancestro o base de la clase Administrador. UML, como muchos otros lenguajes, las llama clases abstractas, y se indican en letra cursiva en el diagrama.
Hay lenguajes que admiten el concepto de genericidad o plantillas de tipos. Am- bos conceptos no son exactamente lo mismo, pero tienen un uso parecido. Esto pasa, por ejemplo, con la clase Math de las plataformas Java y. De hecho, tampoco tiene mucho sentido colocar la visibilidad de los mismos, aunque lo hicimos para mayor claridad. Tipos de dependencias en diagramas de clases Hay muchos tipos de dependencias entre las clases de un diagrama.
Sin embargo, por resultar algo obvio, no lo hemos representado. En este libro, lo hemos omitido. Si deseas probar esta herramienta UML de forma gratuita, puedes crear una cuenta sin compromiso o usar la fase de prueba, igualmente gratuita, de las cuentas premium. Con la cuenta gratuita tienes acceso a las siguientes plantillas de diagramas UML :. Lucidchart es compatible con los formatos de diagramas nativos de Microsoft Visio, Omnigraffle, Gliffy y Draw.
Jaguar Land Rover, por ejemplo, utiliza Rational Rhapsody para adaptar el software de su oferta de infoentretenimiento en sus diferentes mercados. Esta herramienta UML es compatible con las siguientes notaciones:. Estos lenguajes de modelado basados en UML son adecuados para el desarrollo de software, lo que ahorra mucho trabajo a los programadores. El programa ofrece cuatro versiones diferentes de licencia. Los programas difieren principalmente en las funcionalidades y el precio.
Si se libera un diagrama, los miembros del equipo aprobados pueden trabajar en el documento al mismo tiempo. De esta manera, esta herramienta UML cumple con su tarea principal, que consiste en mostrar claramente los procesos y sistemas.
Te lo contamos todo acerca de los Los diagramas de secuencia contribuyen a visualizar en detalle y con claridad el flujo de mensajes dentro de un sistema. Descubre y aprende a hacer un diagrama de secuencia con UML. Herramientas UML: comparativa final Ya sea gratuita, online o como entorno de desarrollo integrado, existen diferentes propuestas adaptadas a cada necesidad. Herramientas de diagramas UML: aspectos a tener en cuenta El lenguaje unificado de modelado especifica 14 tipos de diagramas que representan la estructura, el comportamiento y las interacciones de un sistema.
Un debugger que informe inmediatamente si se producen errores en el modelo. GitMind se puede utilizar con drag and drop. Basta con arrastrar y soltar formas y flechas de la barra lateral al escritorio. Haz doble clic para cambiar los colores y las fuentes. Lucidchart: la herramienta UML online para el trabajo en equipo Lucidchart es una herramienta UML a la que se puede acceder en el navegador.
Productos asociados. Ver planes.
0コメント