Imagen de www.uml.org Este
artículo trata sobre UML y sus usos actuales. Un poco de información histórica, muy poco, solo los puntos principales:
- UML nació en los años 90 como resultado del trabajo en la creación de un lenguaje de modelado orientado a objetos.
- La especificación 1.0 salió en 1997.
- La especificación 2.0 salió en 2005.
- Hasta la fecha, UML 2.5, varios perfiles han evolucionado, como SysML y SoaML .
Si observa cómo se usó UML en ese momento y lo piensa detenidamente, puede sacar la siguiente conclusión: deje que la versión de UML sea 2.5 ahora, pero los principios del uso del lenguaje no han cambiado desde la primera versión.
Y como consecuencia: los analistas utilizan el concepto de describir sistemas de software, que se estableció hace más de 20 años. El concepto en sí es bueno, pero debe relacionarlo con el lugar y el contexto de uso.
Si continuamos este análisis del uso de UML, y lo correlacionamos con los requisitos del momento actual, las conclusiones son las siguientes:
- Todas las técnicas para utilizar UML "ir alrededor" Desarrollo de casos de uso.
- Los modelos UML carecen de integridad. El enfoque elegido de una descripción separada de los aspectos de estructura y comportamiento, niveles de negocio y aplicaciones complica la percepción de los modelos en su conjunto.
- UML es un lenguaje orientado a objetos, lo que hace que sea difícil expresar otros conceptos con él.
No diré nada sobre el enfoque de desarrollo impulsado por casos de uso, una de sus encarnaciones es el proceso unificado racional. A continuación, hablaré sobre los últimos dos puntos.
Aspectos de presentación
UML consta de muchos diagramas. Cada uno de los cuales obedece sus propias reglas, utiliza elementos y flechas en su propio entendimiento. Y desde el exterior no parece un lenguaje unificado, sino un conjunto de representaciones diferentes, que a menudo se presenta como una oportunidad para mirar el área temática desde diferentes puntos de vista. Con el mismo éxito, puede llamar al cuchillo suizo una herramienta unificada, que en esencia es un conjunto que consta de cuchillas, destornilladores, abrelatas, cucharas, tenedores y todo en un solo mango.
¿Qué hace un analista cuando intenta ajustar todos los diagramas en un modelo? Comienza a construir cuadros híbridos y tablas de enlaces. El resultado no es un modelo único, sino muchos gráficos, a los que se han agregado gráficos y tablas.
Niveles de presentación
Digamos que un analista de negocios ha descrito un área temática utilizando diagramas UML. Y ahora un analista de sistemas o el mismo analista necesita formar un modelo de un sistema de software. Si el analista está enfocado en UML, entonces comenzará a crear representaciones correspondientes a las realizadas anteriormente, pero ya dentro del marco del sistema. Se verá como diagramas similares de nuevo.
¿Qué hará el analista cuando quiera comparar la descripción del área temática y el modelo del sistema?
Nuevamente comienza a construir diagramas híbridos, tablas de enlaces y trazas.
El resultado es nuevamente una gran cantidad de gráficos y tablas.
Todavía hay que señalar que UML es un lenguaje antiguo y hay una gran cantidad de libros y ejemplos antiguos para ello.Que describe principalmente casos de transición de un negocio no automatizado a uno automatizado. Y los analistas aprenden de estos ejemplos. Pero hoy, la tecnología de la información ha penetrado en todas partes. Un enfoque de negocio por negocio, separado de TI no es aceptable .
Enfoque orientado al servicio
UML es un lenguaje orientado a objetos, lo que hace que sea difícil expresar otros conceptos con él. Por ejemplo, orientado al servicio. El Perfil estándar UML no tiene el concepto de "Servicio", pero hay un perfil SoaML que se promociona como un lenguaje de modelado de arquitectura orientado a servicios.
Hablaré brevemente sobre el enfoque orientado a servicios, para que luego quede claro por qué SoaML no es adecuado para modelarlo. Basado en la interpretación de las definiciones de TOGAF .
Para una formalización simple de un enfoque orientado al servicio, necesitamos 2 abstracciones:
- Un proceso es un flujo de control entre / sobre servicios. También debe decirse que un proceso es una secuencia de acciones que juntas logran cierto resultado.
- El servicio es un elemento de comportamiento que proporciona cierta funcionalidad en respuesta a solicitudes de sujetos u otros servicios. Un servicio proporciona o admite capacidades , tiene una interfaz explícitamente definida y se controla explícitamente.
Veamos cómo se modela esto en SoaML. Al mismo tiempo, compararemos la diferencia entre el modelado orientado a objetos en UML y el modelado orientado a servicios en SoaML.
Hombre y tienda
Tarea: Describa el modelo de compra de bienes en la tienda.
El enfoque orientado a objetos, creo, es claro y simple para todos. Para no perder el tiempo, no consideraremos la capa empresarial. Creo que todos pueden imaginar en su cabeza el caso de uso de asesoramiento y sus detalles en forma de diagrama de actividad o diagrama de secuencia.
Una persona no actúa como usuario, sino como uno de los lados de la interacción.
Ahora solucionemos este problema usando SoaML, estrictamente de acuerdo con la especificación .
En este diagrama, definimos la comunidad de personas que interactúan, esta es la Tienda y la Persona.
Definimos el proceso comercial de "Venta de bienes" que opera entre ellos, en el cual la Tienda actúa como el "vendedor" y la Persona como el "comprador".
En función del proceso comercial, ahora podemos identificar el siguiente servicio comercial; en SoaML, se utiliza el clasificador ServiceContract para esto.
En el marco de este servicio: el vendedor actúa como proveedor y el comprador como consumidor.
El vendedor, como proveedor, proporciona una operación de "venta". El análisis de negocios ha terminado, pasamos al nivel del sistema.
Necesitamos modelar a nivel de sistema una versión actualizada de nuestro proceso comercial para vender un producto. Para esto, elegí un diagrama de secuencia, puede usar cualquier otro diagrama de comportamiento.
A partir del proceso comercial actualizado, podemos seleccionar una operación "vender", la organizaremos en la interfaz básica "Quién sabe cómo vender".
A continuación, debemos describir las interfaces de servicio que se usarán para implementar el servicio.
Obtenemos las siguientes interfaces de servicio:
- "Deseo de vender", que se hereda de la interfaz "Venta";
- "Necesito comprar", que depende de la interfaz "capaz de vender".
Ahora puede representar el modelo de servicio de destino como un diagrama de estructura compuesta.
Compare los resultados del modelado orientado a objetos en UML y el modelado orientado a servicios en SoaML.
Visualmente, toda la diferencia está en estos pequeños cuadrados en el borde de los componentes. Los marqué en rojo. ¿Esa es toda la diferencia?
La diferencia entre el modelado orientado a objetos y el orientado a servicios está realmente allí, solo SoaML ha reducido todo a objetos. Pero más sobre eso más tarde.
Y ahora terminaremos la consideración de SoaML en un caso más complejo, luego obtendremos aproximadamente los siguientes esquemas.
Lo que está mal, en mi opinión, con SoaML.
en primer lugar: Una vez más, los problemas con la integridad del lenguaje y la relación entre el nivel comercial y el nivel de aplicación, usted mismo vio lo difícil que todo está relacionado entre sí.
En segundo lugar : el servicio se describe como un objeto de estructura, esto no es bueno. En ruso, la frase "El proveedor representa el servicio" es común, este es un enfoque orientado a componentes que se implementa en SoaML. Pero en el caso del paradigma orientado al servicio, es más correcto decir "El proveedor proporciona un servicio". Y si traduce "Servicio" al ruso de otra manera, entonces todo encaja de inmediato: "El proveedor proporciona el servicio ". Desde este punto de vista, "Servicio" no es un "Objeto", es un "Comportamiento".
En tercer lugar: En la diapositiva sobre arquitectura orientada al servicio, hablé sobre dos abstracciones: Proceso y Servicio. Verlos y describirlos a través de la lente de un enfoque orientado a objetos es, por decirlo suavemente, una tarea estresante.
Paradigmas
Volvamos al UML. El UML intenta describir otros paradigmas a través de su paradigma.
Y si todo resulta con un paradigma orientado a componentes, puede representarse como una continuación lógica de un paradigma orientado a objetos. El orientado al servicio no funcionó bien.
En este caso, expresar un paradigma a través de otro es una mala idea.
Demostré el uso de tal concepto con SoaML usando el ejemplo de la tarea "Hombre y Tienda".
Se aplica mejor a los paradigmas como se indica a continuación.
Demostraré cómo el modelado orientado a servicios difiere del modelado orientado a objetos.
Hombre y perro
Tarea: Describa un modelo de interacción: una persona camina con un perro.
Sin pensarlo dos veces, esta tarea probablemente será resuelta por cualquier estudiante de la facultad técnica. La programación orientada a objetos es imprescindible en las escuelas y universidades en las especialidades relevantes. El enfoque orientado a objetos se presenta a continuación.
¿Y cómo será un modelo con un enfoque orientado al servicio? No sé si un estudiante responderá a esa pregunta.
Esto es lo que me gustaría recibir. (Piensa un minuto tú mismo, luego mira)
, . - . () () «».
, . - . () () «».
Puede recordar la historia de la programación orientada a objetos. Cómo incluso personas muy autoritarias, como Edsger Dijkstra y Niklaus Wirth, se mostraron escépticas al comienzo de su aparición. Y aún así, algunas personas consideran que la POO no merece atención.
Bueno, este modelo también puede causar sonrisas. El hecho es que un paradigma orientado a servicios no tiene suficiente soporte en el nivel inicial de programación y diseño. Para los programadores, el soporte solo lo proporcionan los marcos, por ejemplo, Java Enterprise Edition o Spring. Creo que los programadores llegan a ellos con una cabeza ya formateada para un enfoque orientado a objetos.
Los analistas basan su comprensión de la arquitectura y el diseño orientados a servicios en artículos en Internet que entienden de manera diferente lo que es, y algunos artículos sin profundizar en los detalles técnicos y específicos son generalmente oscuros. Como resultado, los analistas vuelven a los casos de uso generalmente aceptados entre el sistema y los usuarios. También es común que la arquitectura del sistema y la composición de sus componentes ya estén fijados por el arquitecto o debido a la plataforma elegida. Y luego, los analistas nuevamente describen simplemente el caso de uso entre el sistema y los usuarios.
Compare el enfoque orientado a objetos y este aparentemente ridículo, donde el hombre presta al perro un servicio de "paseo". Cuando deja de ser divertido para ti, pero el enfoque orientado a objetos, donde el Humano implementa el método de "caminar", parecerá divertido,en la entrada a la que se alimenta el perro !!! Fue entonces cuando llegaste a comprender el paradigma orientado al servicio.
Cabe señalar que estos paradigmas son bastante compatibles. Una persona aún puede realizar sus acciones habituales: dormir y bailar, y el Perro puede ladrar.
Otro punto: en este ejemplo, introduje un nuevo concepto de "Servicio". Al mismo tiempo, todavía no he definido claramente las reglas para su uso, pero difiere de eso en SoaML. Aquí debe tener cuidado, no se deje llevar por esto, ya que este tipo de extensión se refiere al metamodelado. Puede suceder que los modelos creados resulten ser contradictorios y oscuros.
En lugar de una conclusión
- UML . , . .
- . , . .
- UML . , . , UML, .