El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados. Se puede dividir en dos: el análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable.
En pocas palabras; “El análisis especifica qué es lo que el sistema debe hacer. El diseño establece cómo alcanzar el objetivo”. Se deben utilizar metodologías que permiten ver los sistemas en base a sus procesos, por lo menos en sistemas de procesado por lotes o secuencial. Un ejemplo de ello es la metodología estructurada. Existen otras metodologías como la orientada a objetos.
Este método es una actividad de construcción de modelos. Mediante una notación que es única, se crean modelos que reflejan el flujo y el contenido de la información (datos y control); el sistema se divide funcionalmente y, según los distintos comportamientos, se establece la esencia de lo que se debe construir.
Surge a mediados de los años 70, y ha ido evolucionando introduciéndose
mejoras por varios autores; en los primeros años se centraba en
las aplicaciones de sistemas de información, luego a mediados de
los 80 se introducen mejoras que proporcionan una notación adecuada
para los aspectos de control y de comportamiento de los problemas de tiempo
real (Ward y Mellor, Hatley y Pirbhai).
El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o aplicación bien sea nuevo o ya existente. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.) sin omitir ningún detalle. Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.
El Diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.
El modelado de datos estudia los datos independientemente del procesamiento que los transforma.
¿Cuáles son las entidades de datos primarios que va a
procesar el sistema.?
¿Cuál es la composición de cada entidad de datos
y que atributos la describen.?
¿Cuál es la relación entre las entidades y los
procesos que las transforman.?
Para resolver estas cuestiones se realiza el diagrama entidad-relación, donde se representa la red de datos que existe en el sistema dado, indicando los datos que se introducen, se almacenan se transforman y se producen dentro de la aplicación.
Diagramas de flujo de datos (DFD)
Herramienta que nos permite mostrar el sistema como una red de sistemas conectados entre sí por los datos. Representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.
Diagramas de flujo de Control (DFC)
Estas ampliaciones permiten al analista reflejar el flujo de control y el procesamiento de control; muestran como fluyen los sucesos entre los distintos procesos e ilustran como los sucesos externos hacen que se activen los procesos. El DFC contiene los mismos procesos que el DFD, pero muestra el flujo de control en lugar de datos. Esta ampliación se centra menos en la creación de símbolos gráficos adicionales y más en la representación y especificación de los aspectos del software orientados al control.
El modelado del comportamiento es uno de los principios fundamentales de todos los métodos de análisis de requisitos. El Diagrama de transición de Estado representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado.
El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista tengan una misma comprensión de las entradas, salidas, almacenes de datos y cálculos intermedios.
Se podría decir que el modelo de análisis estructurado toma la siguiente forma:
Diccionario de datos: contiene definiciones de todos los objetos de datos consumidos y producidos por el software.
Diagrama entidad-relación: representa las relaciones entre entidades de datos. Los atributos de cada entidad se pueden describir mediante la Descripción de datos.
Diagrama de flujo de datos (DFD): sirve para dos propósitos, indica como se transforman los datos a medida que se avanza en el sistema; y representa las funciones que transforman el flujo de datos. En la Especificación de proceso se encuentra un descripción de cada función representada en el DFD.
Diagrama de transición de estados (DTE): indica como se comporta el sistema como consecuencia de sucesos externos. La Especificación de control detalla mas información sobre los aspectos de control del software.
Algunas metodologías estructuradas, que se han implantado en mayor o menor grado en el ámbito laboral son:
Los productos de análisis han de ser de mantenimiento muy sencillo.
Esto concierne concretamente al documento final (Especificación
de requisitos del software).
Se deben tratar los problemas de gran tamaño mediante algún
método efectivo de partición.
Siempre que sea posible, se deben utilizar gráficos.
Se deben diferenciar las consideraciones lógicas (esenciales) y
las físicas (de implementación).
Esta metodología clásica presenta ciertos problemas, que
han ido haciéndose cada vez más graves, a medida que se
construían aplicaciones y sistemas informáticos más
complejos, entre los que destacan los siguientes:
Modelo mental anómalo. Nuestra imagen del mundo se apoya en los
seres, a los que asignamos nombres sustantivos, mientras la programación
clásica se basa en el comportamiento, representado usualmente por
verbos.
Es difícil modificar y extender los programas, pues suele haber
datos compartidos por varios subprogramas, que introducen interacciones
ocultas entre ellos.
Es difícil mantener los programas. Casi todos los sistemas informáticos
grandes tienen errores ocultos, que no surgen a la luz hasta después
de muchas horas de funcionamiento.
Es difícil reutilizar los programas. Es prácticamente imposible
aprovechar en una aplicación nueva las subrutinas que se diseñaron
para otra.
El Análisis Orientado a Objetos (AOO) se define como "un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema", los objetos son entidades tangibles que muestran un comportamiento bien definido.
Todo esto quiere decir que el análisis orientado a objetos parte
de entidades tangibles halladas en el problema, tales entidades varían
dependiendo de los diversos casos prácticos, pero en todos los
casos son elementos reales que toman parte del problema de forma directa.
El Diseño Orientado a Objetos (DOO) "es el método que
lleva a una descomposición Orientado a Objetos. Aplicando DOO,
se crea software resistente al cambio y escrito con economía de
expresión. Se logra un mayor nivel de confianza en la corrección
del software a través de la división inteligente de su espacio
de estados. En última instancia, se reducen los riesgos inherentes
al desarrollo de sistemas.
Los modelos del diseño orientado a objetos reflejan la importancia
de plasmar explícitamente las jerarquías de clases y objetos
del sistema que se diseña. Estos modelos cubren también
el espectro de las decisiones de diseño relevantes que hay que
considerar en el desarrollo de un sistema complejo, y así animan
a construir implantaciones que posean los atributos de los sistemas complejos
bien formados.
1) Análisis de Requerimientos (Modelo Conceptual)
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se va a presentar la solución que se está buscando. Se examina los requisitos desde la perspectiva de los objetos y clases del dominio del problema.
Actividades de esta etapa:
Diagramar los casos de usos los cuales son una descripción de la
secuencia de interacciones que se producen entre un actor y el sistema
cuando el actor usa el sistema para llevar a cabo una tarea específica.
Detallar o describir la información de entrada y salida de cada
caso de uso por medio de Diagramas de interacción de detalle (de
secuencia o colaboración). Un diagrama de Secuencia muestra una
interacción ordenada según la secuencia temporal de eventos.
En particular, muestra los objetos participantes en la interacción
y los mensajes que intercambian ordenados según su secuencia en
el tiempo. Un Diagrama de Colaboración muestra una interacción
organizada basándose en los objetos que toman parte en la interacción
y los enlaces entre los mismos (en cuanto a la interacción se refiere).
Definir la interfaz inicial del sistema (si es aplicable), lo cual puede
hacerse por medio de un diagrama de estados el cual muestra la secuencia
de estados por los que pasa un caso de uso o un objeto a lo largo de su
vida, indicando qué eventos hacen que se pase de un estado a otro
y cuáles son las respuestas y acciones que genera. También
puede definirse una interfaz inicial por medio de una descripción
textual del funcionamiento, diagramas de interacción o de un prototipo
funcional.
Desarrollar el modelo del mundo mediante un diagrama de estructura estática
de clases. Se deben identificar Clases Elementos físicos y lógicos
dentro del sistema a modelar, comenzando por la clase del objeto más
general (el mundo) Top-down, encontrando sus componentes hasta llegar
a clases de tipos básicos.
Validar los modelos o restricciones descritas para las clases. Para cada
clase evaluar la completitud de las restricciones, desarrollar objetos
ejemplo que cumplan con las restricciones y que no sean válidos
en el mundo real.
2) Diseño del sistema (Diagrama de Clases)
En esta etapa se define una subdivisión en aplicaciones del sistema (si es lo suficientemente grande) y la forma de comunicación con los sistemas ya existentes con los cuales debe interactuar.
Actividades:
Definir componentes del sistema, las aplicaciones y su ubicación.
Representarlos por medio de nodos, componentes y objetos activos (representando
las aplicaciones) dentro de los nodos.
Definir mecanismos de comunicación. Expresarlos por medio de asociaciones
de dependencia entre los nodos, componentes o aplicaciones y, si es conocido,
agregar un estereotipo para definir el protocolo de comunicación
requerido. Agregar notas con restricciones, rendimiento esperado y demás
detalles de las conexiones.
Particularizar los casos de uso a la arquitectura planteada. Refinar los
casos de uso ya existentes de la etapa anterior para adecuarse a la arquitectura
planteada.
Validar arquitectura. Comprobar la validez técnica, económica
y organizacional de la propuesta.
3) Diseño detallado
En esta etapa se adapta el análisis a las características específicas del ambiente de implementación y se completan las distintas aplicaciones del sistema con los modelos de control, interfaz o comunicaciones, según sea el caso
Actividades:
Detalles de implementación del modelo del mundo: Completar detalles
de las clases, atributos, diseño de asociaciones, métodos,
etc
Desarrollar el modelo de interfaz: Enlazar las clases de interfaz con
las clases del modelo del mundo
Desarrollar los modelos de control, persistencia y comunicaciones
4) Implementación y pruebas
Se desarrolla el código de una manera certificada.
Actividades:
Definir estándares de programación
Codificación y pruebas unitarias: Revisiones de código
Pruebas de módulos y de sistema: Se aplican algunos casos de prueba
para el Procedimiento de instalación.
Abstracción: Denotación de características
fundamentales.
Ocultación: Encapsulamiento de la implementación.
Modularidad: Fragmentación en componentes individuales.
Jerarquía: Clasificación de las abstracciones.
Tipificación: Caracterización de propiedades de
una serie de entidades.
Concurrencia: Existencia de objetos activos.
Persistencia: Trascendencia en tiempo y/o espacio.
Las principales ventajas del método orientado a objetos descansan en su posibilidad de hacer frente a dos temas esenciales: Gestión de la complejidad y Mejora de la Productividad en el proceso de desarrollo del software, los cuales son gestionadas a través de las siguientes estrategias:
Escribir código reutilizable
Escribir código posible de mantener
Depurar módulos de código existentes
Compartir código con otros
La complejidad se reduce y la productividad se mejora cuando se pueden volver a utilizar un código de alta calidad. Los mecanismos orientados a objetos en particular la herencia fomentan la reutilización así como el mantenimiento de sistemas.
4.1. Proceso Actual de Compensación de Cheques utilizando el Método Estructurado
Este proceso se efectúa de manera manual, contando con el apoyo de algunos sistemas para el registro de información y procesamiento de cálculos.
4.2. Proceso Propuesto de Compensación de Cheques utilizando el Método Estructurado
Se propone un proceso que cuente con una plataforma centralizada para todas las Instituciones Financieras a través de la cual se envén los cheques al cobro y en devolución, que efectúe los cálculos, proporciones los resultados en medios electrónicos y permita el monitorero en línea del comportamiento del proceso.
4.3. Proceso Actual de Compensación de Cheques Utilizando el Método Orientado a Objetos
Este proceso se efectúa de manera manual, contando con el apoyo de algunos sistemas para el registro de información y procesamiento de cálculos.
4.4. Proceso Propuesto de Compensación de Cheques utilizando el Método Orientado a Objetos
Se propone un proceso que cuente con una plataforma centralizada para todas las Instituciones Financieras a través de la cual se envén los cheques al cobro y en devolución, que efectúe los cálculos, proporciones los resultados en medios electrónicos y permita el monitorero en línea del comportamiento del proceso.
Referencias Bibliográficas:
Senn, James
A. (1992) Análisis y Diseño de Sistemas de Información. Segunda Edición.
Editorial McGrawHill. México
Kendal & Kendall,
Kenneth y Julie. (1997) Análisis y Diseño de Sistemas. Tecera Edición
Editorial Prentice Hall. Mexico
Ann L. Winbland,
Samuel D Edwards, David R King. (1993) Software Orientado a Objetos. Primera
Edición. Editorial Addison – Wesley Iberoamerican. E.U.A
Inforgrafía:
http://www.cs.ualberta.ca/~pfiguero/soo/metod/
http://www.willydev.net/descargas/Articulos/General/umlTotal.pdf
http://es.tldp.org/Manuales-LuCAS/doc-guia-usuario-ruby/doc-guia-usuario-ruby-html/c543.html
