El objetivo del análisis del sistema es modelar el producto software entendiendo y adaptando el dominio del negocio. Para ello el análisis del sistema define los flujos de datos y actividades, la representación de los distintos conceptos del negocio, los cambios del estado del sistema, etc.
Prescindir del Análisis del Sistema puede provocar un diseño o codificación equivocada de una determinada funcionalidad del producto software. Por el contrario, un adecuado Análisis del Sistema ayudará a aterrizar la construcción del producto ya que el equipo de desarrollo podrá consultar diagramas y especificaciones para despejar dudas y eliminar ambigüedades. Imagine un producto software que gestiona los pedidos de una tienda online, si se prescindiera del Análisis del Sistema, entonces un diseñador o codificador podría construir erróneamente un producto software tal que al validar el pedido se envía, cuando realmente antes de ser enviado debe ser registrado. En cambio, si los analistas hubiesen ofrecido a los diseñadores o codificadores un diagrama de estados del sistema o un diagrama de flujo, entonces el malentendido hubiese sido evitado.
A continuación, y a modo de ejemplo, trataremos diagramas habituales (de los muchos existentes) utilizados comúnmente en los análisis del sistema para ayudar a modelar el producto software:
Diagramas de Flujo de Datos. Utilizados en el paradigma de programación estructurada.
Diagramas de Flujo o Actividades. Ofrecen una representación gráfica de un proceso de negocio.
Diagramas Entidad-Relación. Proporcionan una idea de cómo son los datos del sistema y cómo se relacionan entre ellos.
Diagramas de Transición de Estados. Ayudan a entender algunos conceptos claves del negocio.
Los tipos de diagramas utilizados durante el análisis pueden resultar también de utilidad durante la actividad de diseño técnico. A medida que el diagrama expresa detalles de implementación técnica abstrayéndose del propósito funcional, el diagrama es más propio de la actividad de Diseño Técnico, en lugar de la actividad de Análisis. Por ejemplo, es posible utilizar un diagrama de flujo para describir a alto nivel, con poco detalle técnico, los flujos de ciertas actividades del negocio o para describir a bajo nivel, con mucho detalle técnico, cada una de las bifurcaciones e iteraciones del código (diseño técnico).
Esta notación está asociada al paradigma de programación imperativo y es habitualmente utilizado en el Análisis Estructurado muy utilizado durante los 70s. Actualmente la industria apuesta por otros paradigmas de programación, lo cual ha provocado que este tipo de análisis apenas se utilice.
El enfoque del análisis estructurado es considerar que un producto software es un “procesador de datos”. Recibe datos como entrada, los procesa y obtiene resultados. De esta forma, el software es definido a partir del flujo de datos que entra en el sistema, las transformaciones que se realizan con los datos de entrada y el resultado que se obtiene como salida. Los Diagramas de Flujo de Datos (DFD) ayudan a modelar este flujo.
Proceso. Representa una actividad que tiene que llevar a cabo el sistema para transformar o manipular datos.
Entidad Externa. Fuentes de información. Emiten o reciben información de los procesos.
Flujo. Indican el flujo de información a través del sistema. La información que viaja entre procesos puede ser datos o pueden ser eventos de control.
Almacén de Datos y archivos. Repositorios donde se guardan los datos para su procesamiento posterior.
La siguiente figura es un diagrama de flujos de un Sistema Gestor de Pedidos. En él están representados todos los elementos que pueden intervenir en un Diagrama de Flujo de Datos (DFD).
Para refinar el modelo los DFD se usan de forma jerarquizada por niveles. Cada círculo (proceso) puede definirse a su vez con otro DFD. Los niveles de un DFD son: Nivel 0, Diagrama de contexto; Nivel 1, Diagrama de nivel superior, Nivel 2, Diagrama de detalle o expansión. A partir de un determinado nivel y dependiendo de la complejidad del sistema no tiene sentido subdividir más el proceso.
Es importante señalar que los DFD no establecen la dinámica o secuencia en la que se ejecuta el proceso.
El diagrama de flujo o flujograma o diagrama de actividades es la representación gráfica de un algoritmo o proceso.
Los diagramas de flujo favorecen la comprensión del proceso del negocio al mostrarlo gráficamente, ilustrando modelos y conectando conceptos. También permiten identificar los problemas y las oportunidades de mejora del proceso. Se identifican los pasos, los flujos, los conflictos de autoridad, las responsabilidades, los cuellos de botella, y los puntos de decisión.
Cuando el diagrama de flujo o actividades comunica un proceso de negocio, entonces es habitual utilizarlo durante la actividad de Análisis del Sistema. Sin embargo, cuando el diagrama de flujo comunica un determinado algoritmo, entonces es frecuente elaborarlo durante la actividad de Diseño Técnico.
El modelo entidad-relación es una herramienta para el modelo de datos, la cual facilita la representación de entidades. Fue definido por Peter Chen en 1976.
El modelo de datos entidad-relación consta de una colección de objetos básicos, llamados entidades, y de relaciones entre esos objetos:
Entidad. Es una “caja” que representa un objeto (profesor, escuela, etc.) o concepto (tiene, posee, etc.). Suelen indicarse con sustantivos.
Relación. Es una “flecha” que representa una asociación entre entidades. La cardinalidad de la relación puede ser uno a uno, uno a muchos, muchos a muchos. Suelen indicarse con verbos.
En el análisis del sistema este tipo de diagrama pretende subrayar los principales conceptos y sus relaciones del dominio del cliente. Ayuda a modelar el “lenguaje” del negocio.
Un diagrama de transición de estados muestra el comportamiento dependiente del tiempo de un sistema de información. Representa los estados que puede tomar un componente o un sistema y muestra los eventos que implican el cambio de un estado a otro. La descripción de un estado debe ser un adverbio (Iniciado) o un gerundio (Iniciando), se debe evitar el uso de infinitivos (Iniciar) o imperativos (Iniciad).
Los dos elementos principales en estos diagramas son los estados y las posibles transiciones entre ellos. El estado de un componente o sistema representa algún comportamiento que es observable externamente y que perdura durante un periodo de tiempo finito. Una transición es un cambio de estado producido por un evento y refleja los posibles caminos para llegar a un estado final desde un estado inicial.
Desde un estado pueden surgir varias transiciones en función del evento que desencadena el cambio de estado, teniendo en cuenta que, las transiciones que provienen del mismo estado no pueden tener el mismo evento, salvo que exista alguna condición que se aplique al evento.
Referencias:
• Métrica-3 Técnicas. Administración Electrónica del Gobierno de España.
• S. Gómez, E.Moraleda; "Aproximación a la Ingeniería del Software", Editorial Universitaria Ramón Areces, 2014
• I. Sommerville; “Ingeniería del Software”, Addison Wesley, 2005