UML - Guía rápida
UML es un lenguaje estándar para especificar, visualizar, construir y documentar los artefactos de los sistemas de software.
UML fue creado por Object Management Group (OMG) y el borrador de la especificación UML 1.0 se propuso a OMG en enero de 1997.
OMG se esfuerza continuamente por crear un verdadero estándar industrial.
UML significa Unified Modeling Language.
UML es diferente de otros lenguajes de programación comunes como C ++, Java, COBOL, etc.
UML es un lenguaje pictórico que se utiliza para hacer planos de software.
UML se puede describir como un lenguaje de modelado visual de propósito general para visualizar, especificar, construir y documentar un sistema de software.
Aunque UML se usa generalmente para modelar sistemas de software, no está limitado dentro de este límite. También se utiliza para modelar sistemas que no son de software. Por ejemplo, el flujo del proceso en una unidad de fabricación, etc.
UML no es un lenguaje de programación, pero se pueden utilizar herramientas para generar código en varios lenguajes utilizando diagramas UML. UML tiene una relación directa con el análisis y diseño orientado a objetos. Después de cierta estandarización, UML se ha convertido en un estándar OMG.
Objetivos de UML
Una imagen vale más que mil palabras , este idioma encaja perfectamente con la descripción de UML. Los conceptos orientados a objetos se introdujeron mucho antes que UML. En ese momento, no existían metodologías estándar para organizar y consolidar el desarrollo orientado a objetos. Fue entonces cuando UML entró en escena.
Hay una serie de objetivos para el desarrollo de UML, pero el más importante es definir algún lenguaje de modelado de propósito general, que todos los modeladores pueden usar y también debe ser fácil de entender y usar.
Los diagramas UML no solo están hechos para desarrolladores, sino también para usuarios comerciales, gente común y cualquier persona interesada en comprender el sistema. El sistema puede ser un sistema de software o no software. Por lo tanto, debe quedar claro que UML no es un método de desarrollo sino que acompaña a procesos para convertirlo en un sistema exitoso.
En conclusión, el objetivo de UML se puede definir como un mecanismo de modelado simple para modelar todos los sistemas prácticos posibles en el complejo entorno actual.
Un modelo conceptual de UML
Para comprender el modelo conceptual de UML, primero debemos aclarar qué es un modelo conceptual. y ¿por qué se requiere un modelo conceptual?
Un modelo conceptual se puede definir como un modelo que se compone de conceptos y sus relaciones.
Un modelo conceptual es el primer paso antes de dibujar un diagrama UML. Ayuda a comprender las entidades en el mundo real y cómo interactúan entre sí.
Como UML describe los sistemas en tiempo real, es muy importante hacer un modelo conceptual y luego proceder gradualmente. El modelo conceptual de UML se puede dominar aprendiendo los siguientes tres elementos principales:
- Bloques de construcción UML
- Reglas para conectar los bloques de construcción.
- Mecanismos comunes de UML
Conceptos orientados a objetos
UML puede describirse como el sucesor del análisis y diseño orientado a objetos (OO).
Un objeto contiene tanto datos como métodos que controlan los datos. Los datos representan el estado del objeto. Una clase describe un objeto y también forman una jerarquía para modelar el sistema del mundo real. La jerarquía se representa como herencia y las clases también se pueden asociar de diferentes formas según el requisito.
Los objetos son las entidades del mundo real que existen a nuestro alrededor y los conceptos básicos como abstracción, encapsulación, herencia y polimorfismo se pueden representar mediante UML.
UML es lo suficientemente poderoso como para representar todos los conceptos que existen en el análisis y diseño orientado a objetos. Los diagramas UML son representaciones de conceptos orientados a objetos únicamente. Por lo tanto, antes de aprender UML, es importante comprender el concepto de OO en detalle.
A continuación se presentan algunos conceptos fundamentales del mundo orientado a objetos:
Objects - Los objetos representan una entidad y el bloque de construcción básico.
Class - La clase es el plano de un objeto.
Abstraction - La abstracción representa el comportamiento de una entidad del mundo real.
Encapsulation - La encapsulación es el mecanismo de unir los datos y ocultarlos del mundo exterior.
Inheritance - La herencia es el mecanismo de creación de nuevas clases a partir de las existentes.
Polymorphism - Define el mecanismo para existir en diferentes formas.
Análisis y diseño de OO
OO se puede definir como una investigación y, para ser más específicos, es la investigación de objetos. Diseño significa colaboración de objetos identificados.
Por lo tanto, es importante comprender los conceptos de diseño y análisis de OO. El propósito más importante del análisis OO es identificar los objetos de un sistema a diseñar. Este análisis también se realiza para un sistema existente. Ahora, un análisis eficiente solo es posible cuando somos capaces de comenzar a pensar de una manera en la que se puedan identificar los objetos. Después de identificar los objetos, se identifican sus relaciones y finalmente se produce el diseño.
El propósito del análisis y diseño de OO se puede describir como:
Identificar los objetos de un sistema.
Identificar sus relaciones.
Realización de un diseño, que se puede convertir en ejecutables utilizando lenguajes OO.
Hay tres pasos básicos donde se aplican e implementan los conceptos de OO. Los pasos se pueden definir como
OO Analysis → OO Design → OO implementation using OO languagesLos tres puntos anteriores se pueden describir en detalle como:
Durante el análisis OO, el propósito más importante es identificar objetos y describirlos de manera adecuada. Si estos objetos se identifican de manera eficiente, entonces el siguiente trabajo de diseño es fácil. Los objetos deben identificarse con responsabilidades. Las responsabilidades son las funciones realizadas por el objeto. Todos y cada uno de los objetos tienen algún tipo de responsabilidades a realizar. Cuando se colaboran estas responsabilidades, se cumple el propósito del sistema.
La segunda fase es el diseño OO. Durante esta fase, se hace hincapié en los requisitos y su cumplimiento. En esta etapa, los objetos se colaboran de acuerdo con su asociación prevista. Una vez que se completa la asociación, el diseño también está completo.
La tercera fase es la implementación de OO. En esta fase, el diseño se implementa utilizando lenguajes OO como Java, C ++, etc.
Papel de UML en el diseño de OO
UML es un lenguaje de modelado que se utiliza para modelar sistemas de software y no software. Aunque UML se utiliza para sistemas que no son de software, el énfasis está en el modelado de aplicaciones de software OO. La mayoría de los diagramas UML discutidos hasta ahora se utilizan para modelar diferentes aspectos como estático, dinámico, etc. Ahora, cualquiera que sea el aspecto, los artefactos no son más que objetos.
Si miramos el diagrama de clases, el diagrama de objetos, el diagrama de colaboración, los diagramas de interacción, todo básicamente se diseñaría en función de los objetos.
Por tanto, es muy importante comprender la relación entre el diseño OO y UML. El diseño OO se transforma en diagramas UML según el requisito. Antes de comprender el UML en detalle, se debe aprender correctamente el concepto de OO. Una vez que se realiza el análisis y el diseño de OO, el siguiente paso es muy fácil. La entrada del análisis y el diseño OO es la entrada a los diagramas UML.
Como UML describe los sistemas en tiempo real, es muy importante hacer un modelo conceptual y luego proceder gradualmente. El modelo conceptual de UML se puede dominar aprendiendo los siguientes tres elementos principales:
- Bloques de construcción UML
- Reglas para conectar los bloques de construcción.
- Mecanismos comunes de UML
Este capítulo describe todos los componentes básicos de UML. Los bloques de construcción de UML se pueden definir como:
- Things
- Relationships
- Diagrams
Cosas
Thingsson los bloques de construcción más importantes de UML. Las cosas pueden ser ...
- Structural
- Behavioral
- Grouping
- Annotational
Cosas estructurales
Structural thingsdefinir la parte estática del modelo. Representan los elementos físicos y conceptuales. A continuación se presentan breves descripciones de las cosas estructurales.
Class − La clase representa un conjunto de objetos que tienen responsabilidades similares.
Interface − La interfaz define un conjunto de operaciones, que especifican la responsabilidad de una clase.
Collaboration −La colaboración define una interacción entre elementos.
Use case −El caso de uso representa un conjunto de acciones realizadas por un sistema para un objetivo específico.
Component −Componente describe la parte física de un sistema.
Node − Un nodo se puede definir como un elemento físico que existe en tiempo de ejecución.
Cosas de comportamiento
A behavioral thingconsta de las partes dinámicas de los modelos UML. Las siguientes son las cosas de comportamiento:
Interaction − La interacción se define como un comportamiento que consiste en un grupo de mensajes intercambiados entre elementos para realizar una tarea específica.
State machine −La máquina de estados es útil cuando el estado de un objeto en su ciclo de vida es importante. Define la secuencia de estados por los que pasa un objeto en respuesta a eventos. Los eventos son factores externos responsables del cambio de estado
Agrupar cosas
Grouping thingsse puede definir como un mecanismo para agrupar elementos de un modelo UML. Solo hay una cosa de agrupación disponible:
Package − El paquete es el único elemento de agrupación disponible para recopilar elementos estructurales y de comportamiento.
Cosas de anotación
Annotational things se puede definir como un mecanismo para capturar comentarios, descripciones y comentarios de los elementos del modelo UML. Note- Es la única anotación disponible. Una nota se utiliza para presentar comentarios, restricciones, etc. de un elemento UML.
Relación
Relationshipes otro bloque de construcción más importante de UML. Muestra cómo los elementos están asociados entre sí y esta asociación describe la funcionalidad de una aplicación.
Hay cuatro tipos de relaciones disponibles.
Dependencia
La dependencia es una relación entre dos cosas en las que el cambio en un elemento también afecta al otro.
Asociación
La asociación es básicamente un conjunto de enlaces que conecta los elementos de un modelo UML. También describe cuántos objetos participan en esa relación.
Generalización
La generalización se puede definir como una relación que conecta un elemento especializado con un elemento generalizado. Básicamente describe la relación de herencia en el mundo de los objetos.
Realización
La realización se puede definir como una relación en la que dos elementos están conectados. Un elemento describe alguna responsabilidad, que no se implementa y el otro las implementa. Esta relación existe en el caso de interfaces.
Diagramas UML
Los diagramas UML son el resultado final de toda la discusión. Todos los elementos, relaciones se utilizan para hacer un diagrama UML completo y el diagrama representa un sistema.
El efecto visual del diagrama UML es la parte más importante de todo el proceso. Todos los demás elementos se utilizan para completarlo.
UML incluye los siguientes nueve diagramas, cuyos detalles se describen en los capítulos siguientes.
- Diagrama de clase
- Diagrama de objetos
- Use el diagrama del caso
- Diagrama de secuencia
- Diagrama de colaboración
- Diagrama de actividad
- Diagrama de estado
- Diagrama de implementación
- Diagrama de componentes
Cualquier sistema del mundo real es utilizado por diferentes usuarios. Los usuarios pueden ser desarrolladores, probadores, empresarios, analistas y muchos más. Por lo tanto, antes de diseñar un sistema, la arquitectura se realiza con diferentes perspectivas en mente. La parte más importante es visualizar el sistema desde la perspectiva de diferentes espectadores. Cuanto mejor comprendamos, mejor podremos construir el sistema.
UML juega un papel importante en la definición de diferentes perspectivas de un sistema. Estas perspectivas son:
- Design
- Implementation
- Process
- Deployment
El centro es el Use Casevista que conecta los cuatro. UNUse Caserepresenta la funcionalidad del sistema. Por lo tanto, otras perspectivas están conectadas con el caso de uso.
Designde un sistema consta de clases, interfaces y colaboración. UML proporciona un diagrama de clases y un diagrama de objetos para respaldar esto.
Implementationdefine los componentes ensamblados para formar un sistema físico completo. El diagrama de componentes UML se utiliza para respaldar la perspectiva de implementación.
Processdefine el flujo del sistema. Por lo tanto, los mismos elementos que se utilizan en Diseño también se utilizan para respaldar esta perspectiva.
Deploymentrepresenta los nodos físicos del sistema que forma el hardware. El diagrama de implementación de UML se utiliza para respaldar esta perspectiva.
Es muy importante distinguir entre el modelo UML. Se utilizan diferentes diagramas para diferentes tipos de modelado UML. Hay tres tipos importantes de modelado UML.
Modelado estructural
El modelado estructural captura las características estáticas de un sistema. Consisten en lo siguiente:
- Diagramas de clases
- Diagramas de objetos
- Diagramas de implementación
- Diagramas de paquetes
- Diagrama de estructura compuesta
- Diagrama de componentes
El modelo estructural representa el marco para el sistema y este marco es el lugar donde existen todos los demás componentes. Por lo tanto, el diagrama de clases, el diagrama de componentes y los diagramas de implementación son parte del modelado estructural. Todos representan los elementos y el mecanismo para ensamblarlos.
El modelo estructural nunca describe el comportamiento dinámico del sistema. El diagrama de clases es el diagrama estructural más utilizado.
Modelado de comportamiento
El modelo de comportamiento describe la interacción en el sistema. Representa la interacción entre los diagramas estructurales. El modelado de comportamiento muestra la naturaleza dinámica del sistema. Consisten en lo siguiente:
- Diagramas de actividad
- Diagramas de interacción
- Diagramas de casos de uso
Todo lo anterior muestra la secuencia dinámica de flujo en un sistema.
Modelado arquitectónico
El modelo arquitectónico representa el marco general del sistema. Contiene elementos estructurales y de comportamiento del sistema. El modelo arquitectónico se puede definir como el plano de todo el sistema. El diagrama del paquete se incluye en el modelado arquitectónico.
UML es popular por sus notaciones esquemáticas. Todos sabemos que UML sirve para visualizar, especificar, construir y documentar los componentes de los sistemas de software y no software. Por lo tanto, la visualización es la parte más importante que debe entenderse y recordarse.
Las notaciones UML son los elementos más importantes en el modelado. El uso eficiente y apropiado de las notaciones es muy importante para hacer un modelo completo y significativo. El modelo es inútil, a menos que su propósito se describa correctamente.
Por lo tanto, se debe enfatizar el aprendizaje de notaciones desde el principio. Hay diferentes notaciones disponibles para cosas y relaciones. Los diagramas UML se hacen usando notaciones de cosas y relaciones. La extensibilidad es otra característica importante que hace que UML sea más potente y flexible.
El capítulo describe en detalle las notaciones básicas de UML. Esta es solo una extensión de la sección de bloques de construcción de UML discutida en el Capítulo Dos.
Cosas estructurales
Las notaciones gráficas utilizadas en elementos estructurales son las más utilizadas en UML. Estos se consideran los sustantivos de los modelos UML. A continuación se muestra la lista de elementos estructurales.
- Classes
- Object
- Interface
- Collaboration
- Caso de uso
- Clases activas
- Components
- Nodes
Notación de clase
La clase UML está representada por la siguiente figura. El diagrama se divide en cuatro partes.
- La sección superior se usa para nombrar la clase.
- El segundo se usa para mostrar los atributos de la clase.
- La tercera sección se utiliza para describir las operaciones realizadas por la clase.
- La cuarta sección es opcional para mostrar cualquier componente adicional.
Las clases se utilizan para representar objetos. Los objetos pueden ser cualquier cosa que tenga propiedades y responsabilidad.
Notación de objetos
El objeto se representa de la misma forma que la clase. La única diferencia es el nombre que está subrayado como se muestra en la siguiente figura.
Como el objeto es una implementación real de una clase, lo que se conoce como instancia de una clase. Por tanto, tiene el mismo uso que la clase.
Notación de interfaz
La interfaz está representada por un círculo como se muestra en la siguiente figura. Tiene un nombre que generalmente se escribe debajo del círculo.
La interfaz se utiliza para describir la funcionalidad sin implementación. La interfaz es como una plantilla en la que define diferentes funciones, no la implementación. Cuando una clase implementa la interfaz, también implementa la funcionalidad según los requisitos.
Notación de colaboración
La colaboración está representada por un eclipse punteado como se muestra en la siguiente figura. Tiene un nombre escrito dentro del eclipse.
La colaboración representa responsabilidades. Generalmente, las responsabilidades están en un grupo.
Notación de caso de uso
El caso de uso se representa como un eclipse con un nombre dentro. Puede contener responsabilidades adicionales.
El caso de uso se utiliza para capturar funcionalidades de alto nivel de un sistema.
Notación de actor
Un actor puede definirse como una entidad interna o externa que interactúa con el sistema.
Un actor se utiliza en un diagrama de casos de uso para describir las entidades internas o externas.
Notación de estado inicial
El estado inicial se define para mostrar el inicio de un proceso. Esta notación se usa en casi todos los diagramas.
El uso de la notación de estado inicial es mostrar el punto de partida de un proceso.
Notación de estado final
El estado final se usa para mostrar el final de un proceso. Esta notación también se usa en casi todos los diagramas para describir el final.
El uso de la notación de estado final es mostrar el punto de terminación de un proceso.
Notación de clase activa
La clase activa se parece a una clase con un borde sólido. La clase activa se usa generalmente para describir el comportamiento concurrente de un sistema.
La clase activa se utiliza para representar la simultaneidad en un sistema.
Notación de componentes
Un componente en UML se muestra en la siguiente figura con un nombre adentro. Se pueden agregar elementos adicionales donde sea necesario.
El componente se utiliza para representar cualquier parte de un sistema para el que se crean diagramas UML.
Notación de nodo
Un nodo en UML está representado por un cuadro cuadrado como se muestra en la siguiente figura con un nombre. Un nodo representa el componente físico del sistema.
El nodo se utiliza para representar la parte física de un sistema, como el servidor, la red, etc.
Cosas de comportamiento
Las partes dinámicas son uno de los elementos más importantes de UML. UML tiene un conjunto de características poderosas para representar la parte dinámica de los sistemas de software y no software. Estas características incluyen interacciones y máquinas de estado .
Las interacciones pueden ser de dos tipos:
- Secuencial (representado por diagrama de secuencia)
- Colaborativo (representado por diagrama de colaboración)
Notación de interacción
La interacción es básicamente un intercambio de mensajes entre dos componentes UML. El siguiente diagrama representa diferentes notaciones utilizadas en una interacción.
La interacción se utiliza para representar la comunicación entre los componentes de un sistema.
Notación de máquina de estado
La máquina de estados describe los diferentes estados de un componente en su ciclo de vida. Las notaciones se describen en el siguiente diagrama.
La máquina de estados se usa para describir diferentes estados de un componente del sistema. El estado puede estar activo, inactivo o cualquier otro dependiendo de la situación.
Agrupar cosas
La organización de los modelos UML es uno de los aspectos más importantes del diseño. En UML, solo hay un elemento disponible para agrupar y es el paquete.
Notación de paquete
La notación de paquete se muestra en la siguiente figura y se usa para envolver los componentes de un sistema.
Cosas de anotación
En cualquier diagrama, la explicación de los diferentes elementos y sus funcionalidades es muy importante. Por lo tanto, UML tiene notación de notas para respaldar este requisito.
Nota notación
Esta notación se muestra en la siguiente figura. Estas notaciones se utilizan para proporcionar la información necesaria de un sistema.
Relaciones
Un modelo no está completo a menos que las relaciones entre los elementos se describan correctamente. La relación le da un significado adecuado a un modelo UML. A continuación se muestran los diferentes tipos de relaciones disponibles en UML.
- Dependency
- Association
- Generalization
- Extensibility
Notación de dependencia
La dependencia es un aspecto importante en los elementos UML. Describe los elementos dependientes y la dirección de la dependencia.
La dependencia está representada por una flecha punteada como se muestra en la siguiente figura. La punta de la flecha representa el elemento independiente y el otro extremo representa el elemento dependiente.
La dependencia se utiliza para representar la dependencia entre dos elementos de un sistema.
Notación de asociación
Asociación describe cómo se asocian los elementos en un diagrama UML. En palabras simples, describe cuántos elementos participan en una interacción.
La asociación está representada por una línea de puntos con (sin) flechas en ambos lados. Los dos extremos representan dos elementos asociados como se muestra en la siguiente figura. La multiplicidad también se menciona en los extremos (1, *, etc.) para mostrar cuántos objetos están asociados.
La asociación se utiliza para representar la relación entre dos elementos de un sistema.
Notación de generalización
La generalización describe la relación de herencia del mundo orientado a objetos. Es una relación entre padres e hijos.
La generalización está representada por una flecha con una punta de flecha hueca como se muestra en la siguiente figura. Un extremo representa el elemento principal y el otro extremo representa el elemento secundario.
La generalización se utiliza para describir la relación padre-hijo de dos elementos de un sistema.
Notación de extensibilidad
Todos los lenguajes (programación o modelado) tienen algún mecanismo para extender sus capacidades como sintaxis, semántica, etc. UML también tiene los siguientes mecanismos para proporcionar características de extensibilidad.
- Estereotipos (representa elementos nuevos)
- Valores etiquetados (representa nuevos atributos)
- Restricciones (representa los límites)
Las notaciones de extensibilidad se utilizan para mejorar el poder del lenguaje. Se trata básicamente de elementos adicionales que se utilizan para representar algún comportamiento extra del sistema. Estos comportamientos adicionales no están cubiertos por las notaciones estándar disponibles.
En los capítulos anteriores, hemos discutido sobre los bloques de construcción y otros elementos necesarios de UML. Ahora necesitamos entender dónde usar esos elementos.
Los elementos son como componentes que se pueden asociar de diferentes formas para crear una imagen UML completa, lo que se conoce como diagrama. Por lo tanto, es muy importante comprender los diferentes diagramas para implementar el conocimiento en sistemas de la vida real.
Cualquier sistema complejo se comprende mejor haciendo algún tipo de diagramas o imágenes. Estos diagramas tienen un mejor impacto en nuestra comprensión. Si miramos a nuestro alrededor, nos daremos cuenta de que los diagramas no son un concepto nuevo, pero se utilizan ampliamente en diferentes formas en diferentes industrias.
Elaboramos diagramas UML para entender el sistema de una manera mejor y sencilla. Un solo diagrama no es suficiente para cubrir todos los aspectos del sistema. UML define varios tipos de diagramas para cubrir la mayoría de los aspectos de un sistema.
También puede crear su propio conjunto de diagramas para satisfacer sus necesidades. Los diagramas generalmente se hacen de forma incremental e iterativa.
Hay dos categorías amplias de diagramas y nuevamente se dividen en subcategorías:
Diagramas estructurales
Diagramas de comportamiento
Diagramas estructurales
Los diagramas estructurales representan el aspecto estático del sistema. Estos aspectos estáticos representan las partes de un diagrama que forman la estructura principal y, por lo tanto, son estables.
Estas partes estáticas están representadas por clases, interfaces, objetos, componentes y nodos. Los cuatro diagramas estructurales son:
- Diagrama de clase
- Diagrama de objetos
- Diagrama de componentes
- Diagrama de implementación
Diagrama de clase
Los diagramas de clases son los diagramas más comunes que se utilizan en UML. El diagrama de clases consta de clases, interfaces, asociaciones y colaboración. Los diagramas de clases representan básicamente la vista orientada a objetos de un sistema, que es de naturaleza estática.
La clase activa se usa en un diagrama de clases para representar la concurrencia del sistema.
El diagrama de clases representa la orientación a objetos de un sistema. Por lo tanto, generalmente se usa con fines de desarrollo. Este es el diagrama más utilizado en el momento de la construcción del sistema.
Diagrama de objeto
Los diagramas de objetos se pueden describir como una instancia de diagrama de clases. Por lo tanto, estos diagramas están más cerca de escenarios de la vida real donde implementamos un sistema.
Los diagramas de objetos son un conjunto de objetos y su relación es como los diagramas de clases. También representan la vista estática del sistema.
El uso de diagramas de objetos es similar a los diagramas de clases, pero se utilizan para construir prototipos de un sistema desde una perspectiva práctica.
Diagrama de componentes
Los diagramas de componentes representan un conjunto de componentes y sus relaciones. Estos componentes constan de clases, interfaces o colaboraciones. Los diagramas de componentes representan la vista de implementación de un sistema.
Durante la fase de diseño, los artefactos de software (clases, interfaces, etc.) de un sistema se organizan en diferentes grupos dependiendo de su relación. Ahora, estos grupos se conocen como componentes.
Finalmente, se puede decir que los diagramas de componentes se utilizan para visualizar la implementación.
Diagrama de implementación
Los diagramas de implementación son un conjunto de nodos y sus relaciones. Estos nodos son entidades físicas donde se implementan los componentes.
Los diagramas de implementación se utilizan para visualizar la vista de implementación de un sistema. Generalmente, esto lo usa el equipo de implementación.
Note- Si se observan cuidadosamente las descripciones y usos anteriores, es muy claro que todos los diagramas tienen alguna relación entre sí. Los diagramas de componentes dependen de las clases, interfaces, etc., que forman parte del diagrama de clase / objeto. Nuevamente, el diagrama de implementación depende de los componentes, que se utilizan para hacer diagramas de componentes.
Diagramas de comportamiento
Cualquier sistema puede tener dos aspectos, estático y dinámico. Entonces, un modelo se considera completo cuando ambos aspectos están completamente cubiertos.
Los diagramas de comportamiento capturan básicamente el aspecto dinámico de un sistema. El aspecto dinámico se puede describir además como las partes cambiantes / móviles de un sistema.
UML tiene los siguientes cinco tipos de diagramas de comportamiento:
- Use el diagrama del caso
- Diagrama de secuencia
- Diagrama de colaboración
- Diagrama de estado
- Diagrama de actividad
Use el diagrama del caso
Los diagramas de casos de uso son un conjunto de casos de uso, actores y sus relaciones. Representan la vista de caso de uso de un sistema.
Un caso de uso representa una funcionalidad particular de un sistema. Por lo tanto, el diagrama de casos de uso se utiliza para describir las relaciones entre las funcionalidades y sus controladores internos / externos. Estos controladores se conocen comoactors.
Diagrama de secuencia
Un diagrama de secuencia es un diagrama de interacción. Por el nombre, queda claro que el diagrama se ocupa de algunas secuencias, que son la secuencia de mensajes que fluyen de un objeto a otro.
La interacción entre los componentes de un sistema es muy importante desde la perspectiva de implementación y ejecución. El diagrama de secuencia se utiliza para visualizar la secuencia de llamadas en un sistema para realizar una funcionalidad específica.
Diagrama de colaboración
El diagrama de colaboración es otra forma de diagrama de interacción. Representa la organización estructural de un sistema y los mensajes enviados / recibidos. La organización estructural consta de objetos y vínculos.
El propósito del diagrama de colaboración es similar al diagrama de secuencia. Sin embargo, el propósito específico del diagrama de colaboración es visualizar la organización de los objetos y su interacción.
Diagrama de estado
Se espera que cualquier sistema en tiempo real sea reaccionado por algún tipo de eventos internos / externos. Estos eventos son responsables del cambio de estado del sistema.
El diagrama de estado se utiliza para representar el cambio de estado impulsado por eventos de un sistema. Básicamente describe el cambio de estado de una clase, interfaz, etc.
El diagrama de diagrama de estado se utiliza para visualizar la reacción de un sistema por factores internos / externos.
Diagrama de actividad
El diagrama de actividad describe el flujo de control en un sistema. Consta de actividades y enlaces. El flujo puede ser secuencial, concurrente o ramificado.
Las actividades no son más que funciones de un sistema. Se preparan varios diagramas de actividad para capturar todo el flujo en un sistema.
Los diagramas de actividad se utilizan para visualizar el flujo de controles en un sistema. Esto está preparado para tener una idea de cómo funcionará el sistema cuando se ejecute.
Note- La naturaleza dinámica de un sistema es muy difícil de capturar. UML ha proporcionado funciones para capturar la dinámica de un sistema desde diferentes ángulos. Los diagramas de secuencia y los diagramas de colaboración son isomórficos, por lo que se pueden convertir entre sí sin perder información. Esto también es válido para el diagrama de estado y el diagrama de actividad.
El diagrama de clases es un diagrama estático. Representa la vista estática de una aplicación. El diagrama de clases no solo se usa para visualizar, describir y documentar diferentes aspectos de un sistema, sino también para construir código ejecutable de la aplicación de software.
El diagrama de clases describe los atributos y operaciones de una clase y también las restricciones impuestas al sistema. Los diagramas de clases se utilizan ampliamente en el modelado de sistemas orientados a objetos porque son los únicos diagramas UML que pueden mapearse directamente con lenguajes orientados a objetos.
El diagrama de clases muestra una colección de clases, interfaces, asociaciones, colaboraciones y restricciones. También se conoce como diagrama estructural.
Propósito de los diagramas de clases
El propósito del diagrama de clases es modelar la vista estática de una aplicación. Los diagramas de clases son los únicos diagramas que pueden mapearse directamente con lenguajes orientados a objetos y, por lo tanto, se utilizan ampliamente en el momento de la construcción.
Los diagramas UML como el diagrama de actividad y el diagrama de secuencia solo pueden dar el flujo de secuencia de la aplicación, sin embargo, el diagrama de clases es un poco diferente. Es el diagrama UML más popular en la comunidad de codificadores.
El propósito del diagrama de clases se puede resumir como:
Análisis y diseño de la vista estática de una aplicación.
Describe las responsabilidades de un sistema.
Base para diagramas de componentes y despliegue.
Ingeniería de avance y retroceso.
¿Cómo dibujar un diagrama de clase?
Los diagramas de clases son los diagramas UML más populares que se utilizan para la construcción de aplicaciones de software. Es muy importante aprender el procedimiento de dibujo del diagrama de clases.
Los diagramas de clases tienen muchas propiedades que considerar al dibujar, pero aquí el diagrama se considerará desde una vista de nivel superior.
El diagrama de clases es básicamente una representación gráfica de la vista estática del sistema y representa diferentes aspectos de la aplicación. Una colección de diagramas de clases representa todo el sistema.
Los siguientes puntos deben recordarse al dibujar un diagrama de clases:
El nombre del diagrama de clases debe ser significativo para describir el aspecto del sistema.
Cada elemento y sus relaciones deben identificarse de antemano.
La responsabilidad (atributos y métodos) de cada clase debe estar claramente identificada
Para cada clase, se debe especificar un número mínimo de propiedades, ya que las propiedades innecesarias complicarán el diagrama.
Utilice notas cuando sea necesario para describir algún aspecto del diagrama. Al final del dibujo debe ser comprensible para el desarrollador / codificador.
Finalmente, antes de hacer la versión final, el diagrama debe dibujarse en papel normal y reelaborarse tantas veces como sea posible para corregirlo.
El siguiente diagrama es un ejemplo de un sistema de pedidos de una aplicación. Describe un aspecto particular de toda la aplicación.
En primer lugar, el pedido y el cliente se identifican como los dos elementos del sistema. Tienen una relación de uno a varios porque un cliente puede tener varios pedidos.
La clase Order es una clase abstracta y tiene dos clases concretas (relación de herencia) SpecialOrder y NormalOrder.
Las dos clases heredadas tienen todas las propiedades de la clase Order. Además, tienen funciones adicionales como dispatch () y receive ().
El siguiente diagrama de clases se ha elaborado considerando todos los puntos mencionados anteriormente.
¿Dónde usar los diagramas de clases?
El diagrama de clases es un diagrama estático y se utiliza para modelar la vista estática de un sistema. La vista estática describe el vocabulario del sistema.
El diagrama de clases también se considera la base de los diagramas de componentes y de implementación. Los diagramas de clases no solo se utilizan para visualizar la vista estática del sistema, sino que también se utilizan para construir el código ejecutable para la ingeniería directa e inversa de cualquier sistema.
Generalmente, los diagramas UML no se mapean directamente con ningún lenguaje de programación orientado a objetos, pero el diagrama de clases es una excepción.
El diagrama de clases muestra claramente el mapeo con lenguajes orientados a objetos como Java, C ++, etc. Según la experiencia práctica, el diagrama de clases se usa generalmente para fines de construcción.
En pocas palabras, se puede decir que los diagramas de clases se utilizan para:
Describiendo la vista estática del sistema.
Mostrando la colaboración entre los elementos de la vista estática.
Describir las funcionalidades que realiza el sistema.
Construcción de aplicaciones de software utilizando lenguajes orientados a objetos.
Los diagramas de objetos se derivan de los diagramas de clases, por lo que los diagramas de objetos dependen de los diagramas de clases.
Los diagramas de objetos representan una instancia de un diagrama de clases. Los conceptos básicos son similares para los diagramas de clases y los diagramas de objetos. Los diagramas de objetos también representan la vista estática de un sistema, pero esta vista estática es una instantánea del sistema en un momento particular.
Los diagramas de objetos se utilizan para representar un conjunto de objetos y sus relaciones como una instancia.
Propósito de los diagramas de objetos
El propósito de un diagrama debe entenderse claramente para implementarlo de manera práctica. Los propósitos de los diagramas de objetos son similares a los diagramas de clases.
La diferencia es que un diagrama de clases representa un modelo abstracto que consta de clases y sus relaciones. Sin embargo, un diagrama de objeto representa una instancia en un momento particular, que es de naturaleza concreta.
Significa que el diagrama de objetos está más cerca del comportamiento real del sistema. El propósito es capturar la vista estática de un sistema en un momento particular.
El propósito del diagrama de objetos se puede resumir como:
Ingeniería de avance y retroceso.
Relaciones de objeto de un sistema
Vista estática de una interacción.
Comprender el comportamiento de los objetos y su relación desde una perspectiva práctica.
¿Cómo dibujar un diagrama de objeto?
Ya hemos comentado que un diagrama de objetos es una instancia de un diagrama de clases. Implica que un diagrama de objetos consta de instancias de cosas utilizadas en un diagrama de clases.
Por tanto, ambos diagramas están hechos de los mismos elementos básicos pero de diferente forma. En el diagrama de clases, los elementos están en forma abstracta para representar el plano y en el diagrama de objetos los elementos están en forma concreta para representar el objeto del mundo real.
Para capturar un sistema en particular, el número de diagramas de clases es limitado. Sin embargo, si consideramos los diagramas de objetos, podemos tener un número ilimitado de instancias, que son únicas por naturaleza. Solo se consideran aquellas instancias que tienen un impacto en el sistema.
De la discusión anterior, está claro que un diagrama de objeto único no puede capturar todas las instancias necesarias o más bien no puede especificar todos los objetos de un sistema. Por lo tanto, la solución es:
Primero, analice el sistema y decida qué instancias tienen datos y asociaciones importantes.
En segundo lugar, considere solo esos casos, que cubrirán la funcionalidad.
En tercer lugar, realice algunas optimizaciones, ya que el número de instancias es ilimitado.
Antes de dibujar un diagrama de objeto, se deben recordar y comprender claramente las siguientes cosas:
Los diagramas de objetos constan de objetos.
El enlace en el diagrama de objetos se utiliza para conectar objetos.
Los objetos y los enlaces son los dos elementos que se utilizan para construir un diagrama de objetos.
Después de esto, se deben decidir las siguientes cosas antes de comenzar la construcción del diagrama:
El diagrama de objetos debe tener un nombre significativo para indicar su propósito.
Deben identificarse los elementos más importantes.
Debe aclararse la asociación entre objetos.
Es necesario capturar los valores de diferentes elementos para incluirlos en el diagrama de objetos.
Agregue notas adecuadas en los puntos donde se requiere más claridad.
El siguiente diagrama es un ejemplo de un diagrama de objeto. Representa el sistema de gestión de pedidos que hemos comentado en el capítulo Diagrama de clases. El siguiente diagrama es una instancia del sistema en un momento particular de compra. Tiene los siguientes objetos.
Customer
Order
SpecialOrder
NormalOrder
Ahora, el objeto de cliente (C) está asociado con tres objetos de pedido (O1, O2 y O3). Estos objetos de orden están asociados con objetos de orden especial y orden normal (S1, S2 y N1). El cliente tiene los siguientes tres pedidos con números diferentes (12, 32 y 40) para el tiempo particular considerado.
El cliente puede aumentar el número de pedidos en el futuro y, en ese escenario, el diagrama de objetos lo reflejará. Si se observan objetos de orden, orden especial y orden normal, encontrará que tienen algunos valores.
Para pedidos, los valores son 12, 32 y 40 lo que implica que los objetos tienen estos valores para un momento particular (aquí se considera el momento particular en que se realiza la compra como el momento) en que se captura la instancia
Lo mismo ocurre con los objetos de pedido especial y de pedido normal que tienen un número de pedidos de 20, 30 y 60. Si se considera un momento de compra diferente, estos valores cambiarán en consecuencia.
El siguiente diagrama de objetos se ha elaborado considerando todos los puntos mencionados anteriormente.
¿Dónde usar diagramas de objetos?
Los diagramas de objetos se pueden imaginar como la instantánea de un sistema en ejecución en un momento determinado. Consideremos un ejemplo de un tren en marcha.
Ahora, si tomas una foto del tren en marcha, encontrarás una imagen estática con lo siguiente:
Un estado particular que se está ejecutando.
Un número particular de pasajeros. que cambiará si el complemento se toma en un momento diferente
Aquí, podemos imaginar que el chasquido del tren en marcha es un objeto que tiene los valores anteriores. Y esto es cierto para cualquier sistema simple o complejo de la vida real.
En pocas palabras, se puede decir que los diagramas de objetos se utilizan para:
Realización del prototipo de un sistema.
Ingeniería inversa.
Modelado de estructuras de datos complejas.
Comprender el sistema desde una perspectiva práctica.
Los diagramas de componentes son diferentes en términos de naturaleza y comportamiento. Los diagramas de componentes se utilizan para modelar los aspectos físicos de un sistema. Ahora la pregunta es, ¿cuáles son estos aspectos físicos? Los aspectos físicos son los elementos como ejecutables, bibliotecas, archivos, documentos, etc. que residen en un nodo.
Los diagramas de componentes se utilizan para visualizar la organización y las relaciones entre los componentes de un sistema. Estos diagramas también se utilizan para hacer sistemas ejecutables.
Propósito de los diagramas de componentes
El diagrama de componentes es un tipo especial de diagrama en UML. El propósito también es diferente de todos los demás diagramas discutidos hasta ahora. No describe la funcionalidad del sistema, pero describe los componentes usados para hacer esas funcionalidades.
Por tanto, desde ese punto de vista, los diagramas de componentes se utilizan para visualizar los componentes físicos de un sistema. Estos componentes son bibliotecas, paquetes, archivos, etc.
Los diagramas de componentes también se pueden describir como una vista de implementación estática de un sistema. La implementación estática representa la organización de los componentes en un momento particular.
Un diagrama de un solo componente no puede representar todo el sistema, pero se utiliza una colección de diagramas para representar el todo.
El propósito del diagrama de componentes se puede resumir como:
Visualice los componentes de un sistema.
Construya ejecutables utilizando ingeniería directa e inversa.
Describe la organización y las relaciones de los componentes.
¿Cómo dibujar un diagrama de componentes?
Los diagramas de componentes se utilizan para describir los artefactos físicos de un sistema. Este artefacto incluye archivos, ejecutables, bibliotecas, etc.
El propósito de este diagrama es diferente. Los diagramas de componentes se utilizan durante la fase de implementación de una aplicación. Sin embargo, está preparado con mucha antelación para visualizar los detalles de implementación.
Inicialmente, el sistema se diseña usando diferentes diagramas UML y luego, cuando los artefactos están listos, los diagramas de componentes se usan para tener una idea de la implementación.
Este diagrama es muy importante ya que sin él la aplicación no se puede implementar de manera eficiente. Un diagrama de componentes bien elaborado también es importante para otros aspectos como el rendimiento de la aplicación, el mantenimiento, etc.
Antes de dibujar un diagrama de componentes, los siguientes artefactos deben identificarse claramente:
Archivos usados en el sistema.
Bibliotecas y otros artefactos relevantes para la aplicación.
Relaciones entre los artefactos.
Después de identificar los artefactos, se deben tener en cuenta los siguientes puntos.
Utilice un nombre significativo para identificar el componente para el que se dibujará el diagrama.
Prepare un diseño mental antes de producir las herramientas de uso.
Utilice notas para aclarar puntos importantes.
A continuación se muestra un diagrama de componentes para el sistema de gestión de pedidos. Aquí, los artefactos son archivos. El diagrama muestra los archivos de la aplicación y sus relaciones. En realidad, el diagrama de componentes también contiene dlls, bibliotecas, carpetas, etc.
En el siguiente diagrama, se identifican cuatro archivos y se producen sus relaciones. El diagrama de componentes no se puede emparejar directamente con otros diagramas UML discutidos hasta ahora, ya que se dibuja con un propósito completamente diferente.
El siguiente diagrama de componentes se ha elaborado considerando todos los puntos mencionados anteriormente.
¿Dónde utilizar los diagramas de componentes?
Ya hemos descrito que los diagramas de componentes se utilizan para visualizar la vista de implementación estática de un sistema. Los diagramas de componentes son un tipo especial de diagramas UML que se utilizan para diferentes propósitos.
Estos diagramas muestran los componentes físicos de un sistema. Para aclararlo, podemos decir que los diagramas de componentes describen la organización de los componentes en un sistema.
La organización se puede describir con más detalle como la ubicación de los componentes en un sistema. Estos componentes están organizados de una manera especial para cumplir con los requisitos del sistema.
Como ya hemos comentado, esos componentes son bibliotecas, archivos, ejecutables, etc. Antes de implementar la aplicación, estos componentes deben organizarse. Esta organización de componentes también está diseñada por separado como parte de la ejecución del proyecto.
Los diagramas de componentes son muy importantes desde la perspectiva de la implementación. Por lo tanto, el equipo de implementación de una aplicación debe tener un conocimiento adecuado de los detalles del componente.
Los diagramas de componentes se pueden utilizar para:
Modele los componentes de un sistema.
Modele el esquema de la base de datos.
Modele los ejecutables de una aplicación.
Modele el código fuente del sistema.
Los diagramas de implementación se utilizan para visualizar la topología de los componentes físicos de un sistema, donde se implementan los componentes de software.
Los diagramas de implementación se utilizan para describir la vista de implementación estática de un sistema. Los diagramas de implementación constan de nodos y sus relaciones.
Propósito de los diagramas de implementación
El término Implementación en sí mismo describe el propósito del diagrama. Los diagramas de implementación se utilizan para describir los componentes de hardware, donde se implementan los componentes de software. Los diagramas de componentes y los diagramas de implementación están estrechamente relacionados.
Los diagramas de componentes se utilizan para describir los componentes y los diagramas de implementación muestran cómo se implementan en el hardware.
UML está diseñado principalmente para centrarse en los artefactos de software de un sistema. Sin embargo, estos dos diagramas son diagramas especiales que se utilizan para centrarse en componentes de software y hardware.
La mayoría de los diagramas UML se utilizan para manejar componentes lógicos, pero los diagramas de implementación se hacen para centrarse en la topología de hardware de un sistema. Los ingenieros de sistemas utilizan los diagramas de implementación.
El propósito de los diagramas de implementación se puede describir como:
Visualice la topología de hardware de un sistema.
Describa los componentes de hardware utilizados para implementar componentes de software.
Describe los nodos de procesamiento en tiempo de ejecución.
¿Cómo dibujar un diagrama de implementación?
El diagrama de implementación representa la vista de implementación de un sistema. Está relacionado con el diagrama de componentes porque los componentes se implementan utilizando los diagramas de implementación. Un diagrama de implementación consta de nodos. Los nodos no son más que hardware físico que se utiliza para implementar la aplicación.
Los diagramas de implementación son útiles para los ingenieros de sistemas. Un diagrama de implementación eficiente es muy importante ya que controla los siguientes parámetros:
Performance
Scalability
Maintainability
Portability
Antes de dibujar un diagrama de implementación, se deben identificar los siguientes artefactos:
Nodes
Relaciones entre nodos
A continuación se muestra un diagrama de implementación de muestra para proporcionar una idea de la vista de implementación del sistema de gestión de pedidos. Aquí, hemos mostrado los nodos como:
Monitor
Modem
Servidor de caché
Server
Se supone que la aplicación es una aplicación basada en web, que se implementa en un entorno en clúster utilizando el servidor 1, el servidor 2 y el servidor 3. El usuario se conecta a la aplicación a través de Internet. El control fluye desde el servidor de almacenamiento en caché hasta el entorno en clúster.
El siguiente diagrama de despliegue se ha elaborado considerando todos los puntos mencionados anteriormente.
¿Dónde usar los diagramas de implementación?
Los ingenieros de sistemas utilizan principalmente los diagramas de implementación. Estos diagramas se utilizan para describir los componentes físicos (hardware), su distribución y asociación.
Los diagramas de implementación se pueden visualizar como los componentes / nodos de hardware en los que residen los componentes de software.
Las aplicaciones de software se desarrollan para modelar procesos comerciales complejos. Las aplicaciones de software eficientes no son suficientes para cumplir con los requisitos comerciales. Los requisitos comerciales se pueden describir como la necesidad de respaldar el número creciente de usuarios, el tiempo de respuesta rápido, etc.
Para cumplir con este tipo de requisitos, los componentes de hardware deben diseñarse de manera eficiente y rentable.
Las aplicaciones de software actuales son de naturaleza muy compleja. Las aplicaciones de software pueden ser independientes, basadas en web, distribuidas, basadas en mainframe y muchas más. Por lo tanto, es muy importante diseñar los componentes de hardware de manera eficiente.
Se pueden utilizar diagramas de implementación:
Modelar la topología de hardware de un sistema.
Modelar el sistema integrado.
Modelar los detalles del hardware para un sistema cliente / servidor.
Modelar los detalles de hardware de una aplicación distribuida.
Para ingeniería de avance y retroceso.
Para modelar un sistema, el aspecto más importante es capturar el comportamiento dinámico. El comportamiento dinámico significa el comportamiento del sistema cuando está en ejecución / en funcionamiento.
Solo el comportamiento estático no es suficiente para modelar un sistema, sino que el comportamiento dinámico es más importante que el comportamiento estático. En UML, hay cinco diagramas disponibles para modelar la naturaleza dinámica y el diagrama de casos de uso es uno de ellos. Ahora que tenemos que discutir que el diagrama de casos de uso es de naturaleza dinámica, debería haber algunos factores internos o externos para hacer la interacción.
Estos agentes internos y externos se conocen como actores. Los diagramas de casos de uso constan de actores, casos de uso y sus relaciones. El diagrama se utiliza para modelar el sistema / subsistema de una aplicación. Un diagrama de caso de uso único captura una funcionalidad particular de un sistema.
Por lo tanto, para modelar todo el sistema, se utilizan varios diagramas de casos de uso.
Propósito de los diagramas de casos de uso
El propósito del diagrama de casos de uso es capturar el aspecto dinámico de un sistema. Sin embargo, esta definición es demasiado genérica para describir el propósito, ya que otros cuatro diagramas (actividad, secuencia, colaboración y Statechart) también tienen el mismo propósito. Examinaremos algún propósito específico, que lo distinguirá de otros cuatro diagramas.
Los diagramas de casos de uso se utilizan para recopilar los requisitos de un sistema, incluidas las influencias internas y externas. Estos requisitos son principalmente requisitos de diseño. Por lo tanto, cuando se analiza un sistema para recopilar sus funcionalidades, se preparan casos de uso y se identifican los actores.
Cuando se completa la tarea inicial, los diagramas de casos de uso se modelan para presentar la vista exterior.
En resumen, se puede decir que los propósitos de los diagramas de casos de uso son los siguientes:
Se utiliza para recopilar los requisitos de un sistema.
Se utiliza para obtener una vista exterior de un sistema.
Identificar los factores externos e internos que influyen en el sistema.
Muestre la interacción entre los requisitos son actores.
¿Cómo dibujar un diagrama de casos de uso?
Los diagramas de casos de uso se consideran para el análisis de requisitos de alto nivel de un sistema. Cuando se analizan los requisitos de un sistema, las funcionalidades se capturan en casos de uso.
Podemos decir que los casos de uso no son más que las funcionalidades del sistema escritas de manera organizada. Lo segundo que es relevante para los casos de uso son los actores. Los actores pueden definirse como algo que interactúa con el sistema.
Los actores pueden ser un usuario humano, algunas aplicaciones internas o pueden ser algunas aplicaciones externas. Cuando planeamos dibujar un diagrama de casos de uso, debemos tener identificados los siguientes elementos.
Funcionalidades a representar como caso de uso
Actors
Relaciones entre los casos de uso y los actores.
Los diagramas de casos de uso se dibujan para capturar los requisitos funcionales de un sistema. Después de identificar los elementos anteriores, tenemos que usar las siguientes pautas para dibujar un diagrama de caso de uso eficiente
El nombre de un caso de uso es muy importante. El nombre debe elegirse de tal manera que pueda identificar las funcionalidades realizadas.
Dale un nombre adecuado a los actores.
Muestre relaciones y dependencias claramente en el diagrama.
No intente incluir todo tipo de relaciones, ya que el objetivo principal del diagrama es identificar los requisitos.
Utilice notas siempre que sea necesario para aclarar algunos puntos importantes.
A continuación se muestra un diagrama de casos de uso de muestra que representa el sistema de gestión de pedidos. Por lo tanto, si miramos en el diagrama, encontraremos tres casos de uso(Order, SpecialOrder, and NormalOrder) y un actor que es el cliente.
Los casos de uso de SpecialOrder y NormalOrder se extienden del caso de uso de Order . Por lo tanto, tienen una relación extendida. Otro punto importante es identificar el límite del sistema, que se muestra en la imagen. El actor Cliente se encuentra fuera del sistema, ya que es un usuario externo del sistema.
¿Dónde usar un diagrama de casos de uso?
Como ya hemos comentado, existen cinco diagramas en UML para modelar la vista dinámica de un sistema. Ahora todos y cada uno de los modelos tienen un propósito específico para usar. En realidad, estos propósitos específicos son diferentes ángulos de un sistema en funcionamiento.
Para comprender la dinámica de un sistema, necesitamos usar diferentes tipos de diagramas. El diagrama de casos de uso es uno de ellos y su propósito específico es recopilar los requisitos y actores del sistema.
Los diagramas de casos de uso especifican los eventos de un sistema y sus flujos. Pero el diagrama de casos de uso nunca describe cómo se implementan. El diagrama de casos de uso se puede imaginar como una caja negra donde solo se conocen la entrada, la salida y la función de la caja negra.
Estos diagramas se utilizan a un nivel muy alto de diseño. Este diseño de alto nivel se refina una y otra vez para obtener una imagen completa y práctica del sistema. Un caso de uso bien estructurado también describe la condición previa, la condición posterior y las excepciones. Estos elementos adicionales se utilizan para crear casos de prueba al realizar la prueba.
Aunque el caso de uso no es un buen candidato para la ingeniería directa e inversa, aún se utilizan de una manera ligeramente diferente para hacer ingeniería directa e inversa. Lo mismo ocurre con la ingeniería inversa. El diagrama de casos de uso se usa de manera diferente para que sea adecuado para la ingeniería inversa.
En la ingeniería avanzada, los diagramas de casos de uso se utilizan para crear casos de prueba y en los casos de uso de ingeniería inversa se utilizan para preparar los detalles de los requisitos de la aplicación existente.
Los diagramas de casos de uso se pueden utilizar para:
Análisis de requisitos y diseño de alto nivel.
Modele el contexto de un sistema.
Ingeniería inversa.
Ingeniería avanzada.
A partir del término Interacción, queda claro que el diagrama se usa para describir algún tipo de interacciones entre los diferentes elementos del modelo. Esta interacción es parte del comportamiento dinámico del sistema.
Este comportamiento interactivo está representado en UML mediante dos diagramas conocidos como Sequence diagram y Collaboration diagram. El propósito básico de ambos diagramas es similar.
El diagrama de secuencia enfatiza la secuencia de tiempo de los mensajes y el diagrama de colaboración enfatiza la organización estructural de los objetos que envían y reciben mensajes.
Propósito de los diagramas de interacción
El propósito de los diagramas de interacción es visualizar el comportamiento interactivo del sistema. Visualizar la interacción es una tarea difícil. Por lo tanto, la solución es utilizar diferentes tipos de modelos para capturar los diferentes aspectos de la interacción.
Los diagramas de secuencia y colaboración se utilizan para capturar la naturaleza dinámica pero desde un ángulo diferente.
El propósito del diagrama de interacción es:
Capturar el comportamiento dinámico de un sistema.
Describir el flujo de mensajes en el sistema.
Describir la organización estructural de los objetos.
Describir la interacción entre objetos.
¿Cómo dibujar un diagrama de interacción?
Como ya hemos comentado, el propósito de los diagramas de interacción es capturar el aspecto dinámico de un sistema. Entonces, para capturar el aspecto dinámico, necesitamos entender qué es un aspecto dinámico y cómo se visualiza. El aspecto dinámico se puede definir como la instantánea del sistema en ejecución en un momento particular
Tenemos dos tipos de diagramas de interacción en UML. Uno es el diagrama de secuencia y el otro es el diagrama de colaboración. El diagrama de secuencia captura la secuencia temporal del flujo de mensajes de un objeto a otro y el diagrama de colaboración describe la organización de los objetos en un sistema que participa en el flujo de mensajes.
Las siguientes cosas deben identificarse claramente antes de dibujar el diagrama de interacción
Objetos que participan en la interacción.
El mensaje fluye entre los objetos.
La secuencia en la que fluyen los mensajes.
Organización de objetos.
A continuación se muestran dos diagramas de interacción que modelan el sistema de gestión de pedidos. El primer diagrama es un diagrama de secuencia y el segundo es un diagrama de colaboración
El diagrama de secuencia
El diagrama de secuencia tiene cuatro objetos (Cliente, Pedido, Pedido especial y Pedido normal).
El siguiente diagrama muestra la secuencia de mensajes para el objeto SpecialOrder y la misma se puede utilizar en el caso del objeto NormalOrder . Es importante comprender la secuencia temporal de los flujos de mensajes. El flujo de mensajes no es más que una llamada al método de un objeto.
La primera llamada es sendOrder (), que es un método de objeto Order . La siguiente llamada es confirm () que es un método del objeto SpecialOrder y la última llamada es Dispatch () que es un método del objeto SpecialOrder . El siguiente diagrama describe principalmente las llamadas al método de un objeto a otro, y este es también el escenario real cuando el sistema está en ejecución.
El diagrama de colaboración
El segundo diagrama de interacción es el diagrama de colaboración. Muestra la organización del objeto como se ve en el siguiente diagrama. En el diagrama de colaboración, la secuencia de llamada al método se indica mediante alguna técnica de numeración. El número indica cómo se llaman los métodos uno tras otro. Hemos utilizado el mismo sistema de gestión de pedidos para describir el diagrama de colaboración.
Las llamadas a métodos son similares a las de un diagrama de secuencia. Sin embargo, la diferencia es que el diagrama de secuencia no describe la organización del objeto, mientras que el diagrama de colaboración muestra la organización del objeto.
Para elegir entre estos dos diagramas, se hace hincapié en el tipo de requisito. Si la secuencia de tiempo es importante, se utiliza el diagrama de secuencia. Si se requiere organización, se utiliza el diagrama de colaboración.
¿Dónde utilizar los diagramas de interacción?
Ya hemos comentado que los diagramas de interacción se utilizan para describir la naturaleza dinámica de un sistema. Ahora, veremos los escenarios prácticos donde se utilizan estos diagramas. Para comprender la aplicación práctica, debemos comprender la naturaleza básica del diagrama de secuencia y colaboración.
El propósito principal de ambos diagramas es similar, ya que se utilizan para capturar el comportamiento dinámico de un sistema. Sin embargo, es más importante aclarar y comprender el propósito específico.
Los diagramas de secuencia se utilizan para capturar el orden de los mensajes que fluyen de un objeto a otro. Los diagramas de colaboración se utilizan para describir la organización estructural de los objetos que participan en la interacción. Un solo diagrama no es suficiente para describir el aspecto dinámico de un sistema completo, por lo que se utiliza un conjunto de diagramas para capturarlo como un todo.
Los diagramas de interacción se utilizan cuando queremos comprender el flujo de mensajes y la organización estructural. El flujo de mensajes significa la secuencia del flujo de control de un objeto a otro. La organización estructural significa la organización visual de los elementos de un sistema.
Se pueden utilizar diagramas de interacción:
Modelar el flujo de control por secuencia de tiempo.
Modelar el flujo de control de las organizaciones estructurales.
Para ingeniería avanzada.
Para ingeniería inversa.
El nombre del diagrama en sí mismo aclara el propósito del diagrama y otros detalles. Describe diferentes estados de un componente en un sistema. Los estados son específicos de un componente / objeto de un sistema.
Un diagrama de Statechart describe una máquina de estados. La máquina de estados se puede definir como una máquina que define diferentes estados de un objeto y estos estados están controlados por eventos externos o internos.
El diagrama de actividad que se explica en el siguiente capítulo es un tipo especial de diagrama de estado. Como el diagrama Statechart define los estados, se utiliza para modelar la vida útil de un objeto.
Propósito de los diagramas de estado
El diagrama de estado es uno de los cinco diagramas UML utilizados para modelar la naturaleza dinámica de un sistema. Definen diferentes estados de un objeto durante su vida y estos estados son cambiados por eventos. Los diagramas de estados son útiles para modelar los sistemas reactivos. Los sistemas reactivos se pueden definir como un sistema que responde a eventos externos o internos.
El diagrama de diagrama de estado describe el flujo de control de un estado a otro. Los estados se definen como una condición en la que existe un objeto y cambia cuando se desencadena algún evento. El propósito más importante del diagrama Statechart es modelar la vida útil de un objeto desde su creación hasta su terminación.
Los diagramas de estados también se utilizan para la ingeniería directa e inversa de un sistema. Sin embargo, el objetivo principal es modelar el sistema reactivo.
Los siguientes son los propósitos principales de usar diagramas de Statechart:
Modelar el aspecto dinámico de un sistema.
Modelar la vida útil de un sistema reactivo.
Describir diferentes estados de un objeto durante su tiempo de vida.
Defina una máquina de estados para modelar los estados de un objeto.
¿Cómo dibujar un diagrama de estado?
El diagrama de estado se utiliza para describir los estados de diferentes objetos en su ciclo de vida. Se pone énfasis en los cambios de estado sobre algunos eventos internos o externos. Estos estados de los objetos son importantes para analizarlos e implementarlos con precisión.
Los diagramas de estados son muy importantes para describir los estados. Los estados pueden identificarse como la condición de los objetos cuando ocurre un evento en particular.
Antes de dibujar un diagrama de Statechart debemos aclarar los siguientes puntos:
Identificar los objetos importantes a analizar.
Identifica los estados.
Identifica los eventos.
A continuación se muestra un ejemplo de un diagrama Statechart donde se analiza el estado del objeto Order
El primer estado es un estado inactivo desde donde comienza el proceso. Los siguientes estados llegan para eventos como enviar solicitud, confirmar solicitud y enviar orden. Estos eventos son responsables de los cambios de estado del objeto de pedido.
Durante el ciclo de vida de un objeto (aquí, objeto de orden) pasa por los siguientes estados y puede haber algunas salidas anormales. Esta salida anormal puede ocurrir debido a algún problema en el sistema. Cuando se completa todo el ciclo de vida, se considera una transacción completa como se muestra en la siguiente figura. El estado inicial y final de un objeto también se muestra en la siguiente figura.
¿Dónde utilizar los diagramas de estado?
De la discusión anterior, podemos definir las aplicaciones prácticas de un diagrama Statechart. Los diagramas de diagrama de estado se utilizan para modelar el aspecto dinámico de un sistema, como los otros cuatro diagramas que se analizan en este tutorial. Sin embargo, tiene algunas características distintivas para modelar la naturaleza dinámica.
El diagrama de estado define los estados de un componente y estos cambios de estado son de naturaleza dinámica. Su propósito específico es definir los cambios de estado provocados por eventos. Los eventos son factores internos o externos que influyen en el sistema.
Los diagramas de estado se utilizan para modelar los estados y también los eventos que operan en el sistema. Al implementar un sistema, es muy importante aclarar los diferentes estados de un objeto durante su tiempo de vida y los diagramas de estado se utilizan para este propósito. Cuando se identifican estos estados y eventos, se utilizan para modelarlo y estos modelos se utilizan durante la implementación del sistema.
Si analizamos la implementación práctica del diagrama Statechart, entonces se utiliza principalmente para analizar los estados de los objetos influenciados por los eventos. Este análisis es útil para comprender el comportamiento del sistema durante su ejecución.
El uso principal se puede describir como:
Modelar los estados de los objetos de un sistema.
Modelar el sistema reactivo. El sistema reactivo consta de objetos reactivos.
Identificar los eventos responsables de cambios de estado.
Ingeniería de avance y retroceso.
El diagrama de actividad es otro diagrama importante en UML para describir los aspectos dinámicos del sistema.
El diagrama de actividad es básicamente un diagrama de flujo para representar el flujo de una actividad a otra. La actividad puede describirse como una operación del sistema.
El flujo de control se extrae de una operación a otra. Este flujo puede ser secuencial, ramificado o concurrente. Los diagramas de actividad se ocupan de todo tipo de control de flujo mediante el uso de diferentes elementos como fork, join, etc.
Propósito de los diagramas de actividades
Los propósitos básicos de los diagramas de actividades son similares a otros cuatro diagramas. Captura el comportamiento dinámico del sistema. Se utilizan otros cuatro diagramas para mostrar el flujo de mensajes de un objeto a otro, pero el diagrama de actividades se utiliza para mostrar el flujo de mensajes de una actividad a otra.
La actividad es una operación particular del sistema. Los diagramas de actividad no solo se utilizan para visualizar la naturaleza dinámica de un sistema, sino que también se utilizan para construir el sistema ejecutable mediante técnicas de ingeniería directa e inversa. Lo único que falta en el diagrama de actividades es la parte del mensaje.
No muestra ningún flujo de mensajes de una actividad a otra. A veces, el diagrama de actividad se considera un diagrama de flujo. Aunque los diagramas parecen un diagrama de flujo, no lo son. Muestra diferentes flujos como paralelo, ramificado, concurrente y único.
El propósito de un diagrama de actividad se puede describir como:
Dibuja el flujo de actividad de un sistema.
Describe la secuencia de una actividad a otra.
Describa el flujo paralelo, ramificado y concurrente del sistema.
¿Cómo dibujar un diagrama de actividad?
Los diagramas de actividad se utilizan principalmente como un diagrama de flujo que consta de actividades realizadas por el sistema. Los diagramas de actividad no son exactamente diagramas de flujo, ya que tienen algunas capacidades adicionales. Estas capacidades adicionales incluyen ramificación, flujo paralelo, carril, etc.
Antes de dibujar un diagrama de actividades, debemos tener una comprensión clara de los elementos utilizados en el diagrama de actividades. El elemento principal de un diagrama de actividad es la actividad en sí. Una actividad es una función realizada por el sistema. Después de identificar las actividades, debemos comprender cómo están asociadas con las restricciones y condiciones.
Antes de dibujar un diagrama de actividad, debemos identificar los siguientes elementos:
Activities
Association
Conditions
Constraints
Una vez que se identifican los parámetros mencionados anteriormente, necesitamos hacer un diseño mental de todo el flujo. Esta disposición mental se transforma luego en un diagrama de actividad.
A continuación se muestra un ejemplo de un diagrama de actividades para el sistema de gestión de pedidos. En el diagrama, se identifican cuatro actividades que están asociadas con condiciones. Debe entenderse claramente un punto importante: un diagrama de actividades no puede coincidir exactamente con el código. El diagrama de actividad está diseñado para comprender el flujo de actividades y lo utilizan principalmente los usuarios comerciales.
El siguiente diagrama se dibuja con las cuatro actividades principales:
Enviar pedido por parte del cliente
Recibo del pedido
Confirmar el pedido
Enviar el pedido
Después de recibir la solicitud de pedido, se realizan verificaciones de condición para verificar si es un pedido normal o especial. Una vez identificado el tipo de pedido, se realiza la actividad de despacho y se marca como la finalización del proceso.
¿Dónde usar los diagramas de actividades?
El uso básico del diagrama de actividades es similar a otros cuatro diagramas UML. El uso específico es modelar el flujo de control de una actividad a otra. Este flujo de control no incluye mensajes.
El diagrama de actividad es adecuado para modelar el flujo de actividad del sistema. Una aplicación puede tener varios sistemas. El diagrama de actividad también captura estos sistemas y describe el flujo de un sistema a otro. Este uso específico no está disponible en otros diagramas. Estos sistemas pueden ser bases de datos, colas externas o cualquier otro sistema.
Ahora veremos las aplicaciones prácticas del diagrama de actividades. De la discusión anterior, queda claro que un diagrama de actividad se extrae de un nivel muy alto. Por lo que ofrece una vista de alto nivel de un sistema. Esta vista de alto nivel es principalmente para usuarios comerciales o cualquier otra persona que no sea un técnico.
Este diagrama se utiliza para modelar las actividades que no son más que requisitos comerciales. El diagrama tiene más impacto en la comprensión empresarial que en los detalles de implementación.
El diagrama de actividad se puede utilizar para:
Modelar el flujo de trabajo mediante el uso de actividades.
Modelado de requisitos comerciales.
Conocimiento de alto nivel de las funcionalidades del sistema.
Investigar los requisitos comerciales en una etapa posterior.