CONTENIDO

1. Análisis y Diseño de Sistemas de Información

2. Método de Análisis y Diseño Estructurado

2.1. Modelado de Datos

2.2. Modelado Funcional y Flujo de Información
2.3. Modelado de Comportamiento
2.4. Diccionario de Datos
2.5. Características del Método Estructrurado
2.6. Desventajas del Método Estructurado

3. Método de Análisis y Diseño Orientado a Objeto

3.1. Etapas
3.2. Características de la Orientación a Objetos
3.3. Ventajas de la Orientación a Objetos

4. Caso de Estudio aplicando ambas Metodologías

5. Bibliografía e Infografía

1. ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN

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.

2. MÉTODO DE ANÁLISIS Y DISEÑO ESTRUCTURADO

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.

2.1 Modelado de Datos

El modelado de datos estudia los datos independientemente del
procesamiento que los transforma.

El modelado de datos responde a:

¿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.

2.2 Modelado Funcional y Flujo de Informació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.

2.3 Modelado de Comportamiento

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.

2.4 Diccionario de Datos

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:

Jackson

Page-Jones

Gane & Sarson

Jourdon / De Marco

Warnier

Chen

Merise

SSADM

Metrica

Eurométodo
2.5 Características del Método Estructurado

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).

2.6 Desventajas del Método Estructurado

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.

3. MÉTODO DE ANÁLISIS Y DISEÑO ORIENTADO A

OBJETOS
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.

3.1 Etapas
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.
3.2 Características de la Orientación a Objetos

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.

3.3 Ventajas de la Orientación a Objetos

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. Caso de Estudio Aplicando ambas Metodologías

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.
5. Bibliografía e Infografía

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.monografias.com

http://www.cs.ualberta.ca/~pfiguero/soo/metod/

http://www.willydev.net/descargas/Articulos/General/umlTotal.pdf

http://www.agapea.com/Analisis-y-Diseno-Estructurado-y-orientado-a-
objetos-de-Sistemas-Informaticos-n10005i.htm

http://es.tldp.org/Manuales-LuCAS/doc-guia-usuario-ruby/doc-guia-
usuario-ruby-html/c543.html