Modelado Dinámico con Diagramas de Actividades: Un Enfoque Detallado

Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones

Escrito el en español con un tamaño de 3,5 KB

Modelado Dinámico

Diagramas de Actividades

Recordemos los diferentes modelos que sirven para representar el aspecto dinámico de un sistema:

  • Diagramas de secuencia
  • Diagramas de colaboración
  • Diagramas de estados
  • Diagramas de casos de uso
  • Diagramas de actividades

En este capítulo nos centraremos en los diagramas de actividades, que sirven fundamentalmente para modelar el flujo de control entre actividades.

La idea es generar una especie de diagrama Pert, en el que se puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, así como las tareas concurrentes que pueden realizarse a la vez. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos.

Gráficamente, un diagrama de actividades será un conjunto de arcos y nodos.

Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecución de un proceso más complejo.

Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases, colaborando todas ellas para conseguir un mismo fin.

Ejemplo: Hacer un pedido.

Contenido del diagrama de actividades

Básicamente, un diagrama de actividades contiene:

  • Estados de actividad
  • Estados de acción
  • Transiciones
  • Objetos

Estados de actividad y estados de acción

La representación de ambos es un rectángulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una acción. La forma de expresar tanto una actividad como una acción no queda impuesta por UML; se podría utilizar lenguaje natural, una especificación formal de expresiones, un metalenguaje, etc.

La idea central es la siguiente:

“Un estado que represente una acción es atómico, lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida”

En cambio, un estado de actividad sí puede descomponerse en más sub-actividades representadas a través de otros diagramas de actividades. Además, estos estados sí pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestión, así como definición de submáquinas.

SOLID

En ingeniería de software, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) es un acrónimo mnemónico introducido por Robert C. Martin a comienzos de la década del 2000 que representa cinco principios básicos de la programación orientada a objetos y el diseño. Cuando estos principios se aplican en conjunto, es más probable que un desarrollador cree un sistema que sea fácil de mantener y ampliar con el tiempo. Los principios SOLID son guías que pueden ser aplicadas en el desarrollo de software para eliminar código sucio, provocando que el programador tenga que refactorizar el código fuente hasta que sea legible y extensible. Debe ser utilizado con el desarrollo guiado por pruebas o TDD, y forma parte de la estrategia global del desarrollo ágil de software y desarrollo adaptativo de software.

Entradas relacionadas: