METODOLOGIAS PARA MODELAR SOFTWARE

ANLISIS Y DISEO ESTRUCTURADO vs. ORIENTADO A OBJETO

INTRODUCCIN

El Analista de Sistemas es imprescindible en cualquier organizacin, debido al abanico de
destrezas que ste posee y los beneficios que le produce. Se encarga no slo estudiar la
organizacin y desarrollar un sistema automatizado, es ms que eso, la labor del analista de
sistemas es tambin la de asesorar, supervisar, recomendar y modificar procesos internos y
algunas veces de modificar la estructura misma de la empresa, con el propsito de lograr los
objetivos que se proponen.

El Analista de Sistemas tambin tiene dentro de sus actividades el Anlisis y Diseo de sistemas
el cual se refiere al "proceso de examinar la situacin de una empresa con el propsito de
manejarla con mtodos y procedimientos ms adecuados." (Senn, 1992, p.11). sta actividad
se puede dividir en dos: el anlisis de sistemas que comprende la planificacin, el
levantamiento inicial de informacin y el estudio en detalle del sistema actual para luego
recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseo
que consiste en llevar a cabo el sistema por medio de la clasificacin y empleo de la
informacin de manera que se pueda ofrecer una alternativa mucho ms viable.

Todo anlisis y diseo de sistemas lderizado o no por un analista de sistemas posee fases que
pueden dividirse de forma lgica en elementos discretos pero, que innegablemente son
continuos, de alguna manera cclica. Es aqu donde pueden ser utilizadas diferentes
metodologas entre las cuales se pueden mencionar: el Anlisis y Diseo Estructurado y el
Anlisis y Diseo Orientado a Objeto.

La investigacin que se presenta a continuacin define las dos metodologas mencionadas
anteriormente as como tambin, las diferencias que existen entre ellas. Por ltimo se
presenta un Caso Practico donde se planeta un ejemplo de cmo se puede utilizar la
metodologa Orientada a Objeto en un proyecto Web que le sirva a la empresa donde laboro.

ANLISIS Y DISEO ESTRUCTURADO

Muchos especialistas en sistemas de informacin reconocen la dificultad de comprender de
manera completa sistemas grandes y complejos. El mtodo de desarrollo del anlisis
estructurado tiene como finalidad superar esta dificultad por medio de: 1) la divisin del
sistema en componentes y 2) la construccin de un modelo del sistema. El mtodo incorpora
elemetos tanto de anlisis como de diseo.

ANLISIS ESTRUCTURADO
El anlisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la
aplicacin. No se establece cmo se cumplirn los requerimientos o la forma en que se
implantar la aplicacin. Ms bien permite que las personas observen los elementos lgicos (lo
que har el sistema) separado de los componentes fsicos (computadoras, terminales, sistemas
de almacenamiento, etc.). Despus de esto se puede desarrollar un diseo fsico eficiente para
la situacin donde ser utilizado.

ELEMENTOS DEL ANLISIS ESTRUCTURADO
Descripcin Grafica: Utiliza smbolos o iconos para crear un modelo grafico del sistema. Sin
introducir procesos manuales o informatizados, archivos, entre otros.
Diagramas de Flujo de Datos: Tienen la misin de Mostrar las fuentes y destinos de los datos,
Identificar y dar nombre a los procesos, Dar nombre a los grupos de datos que relacionan una
funcion con otra, Sealar los almacenes de datos a los que se tiene acceso.
Diccionario de Datos: Se definen flujo de datos, procesos y almacenes de datos.

DISEO ESTRUCTURADO
El diseo estructurado, otro elemento del anlisis estructurado que emplea la descripcin
grfica, se enfoca en el desarrollo de especificaciones del software. La meta del diseo
estructurado es crear programas formados por mdulos independientes unos de otros desde
el punto de vista funcional. Este enfoque no slo conduce hacia mejores programas sino que
facilita el mantenimiento de los mismos cuando surja la necesidad de hacerlo.

El diseo estructurado es una tcnica especfica para el diseo de programas y no un mtodo
de diseo de compresin. Es decir, no indica nada relacionado con el diseo de archivos o
bases de datos, la presentacin de entradas o salidas, la secuencia de procesamiento o el
hardware que dar soporte a la aplicacin. Esta tcnica conduce a la especificacin de mdulos
de programa que son funcionalmente independientes.

La herramienta fundamental del diseo estructurado es el diagrama de flujo de datos, los
diagramas estructurados son de naturaleza grfica y evitan cualquier referencia relacionada
con el hardware o detalles fsicos. Su finalidad no es mostrar la lgica de los programas (que es
la tarea de los diagramas de flujo). Los diagramas estructurados describen la interaccin entre
mdulos independientes junto con los datos que un mdulo pasa a otro cuando interacciona
con l. Estas especificaciones funcionales para los mdulos se porporcionan a los
programadores antes que de comienzo la fase de escritura de cdigo.

EMPLEO DEL ANLISIS Y DISEO ESTRUCTURADO CON OTROS MTODOS
Se combina, con bastante frecuencia, con el mtodo de ciclo de vida clsico de desarrollo de
sistemas. Por ejemplo los analistas pueden optar por desarrollar diagramas de flujo de datos
como una forma para documentar las relaciones entre componentes durante la investigacin
detallada de algn sistema existente. Asimismo, se pueden definir los archivos y datos en un
diccinario centralizado de datos de acuerdo con las reglas del anlisis estructurado.

ANLISIS Y DISEO ORIENTADO A OBJETOS

Las tcnicas orientadas a objetos permiten que el software se construya a partir de objetos de
comportamiento especfico. Los propios objetos se pueden construir a partir de otros, que a su
vez pueden estar formados por otros objetos.

El anlisis de sistemas en el mundo orientado a objetos se realiza al estudiar los objetos en un
ambiente, as como los eventos que interactan con dichos objetos. El diseo del software se
realiza al volver a utilizar clases de objetos ya existentes y, en caso necesario, al construir
nuevas clases. Al modelar una empresa, los analistas deben identificar sus tipos de objetos y
las operaciones que hagan que los objetos se comporten en determinada forma.

Las tcnicas orientadas a objetos se pueden utilizar como medios para el diseo sencillo de
sistemas complejos. el sistema se puede ver como una coleccin de objetos, donde cada uno
de ellos puede llegar a tener varias posibilidades. Las operaciones que modifican el estado son
relativamente sencillas. Los objetos se construyen a partir de otros objetos. Los sistemas se
construyen a partir de otros componentes probados con un formato definido para las
solicitudes de las operaciones del componente.

El analista orientado a objetos ve el mundo como objetos (con estructuras de datos y
mtodos) y eventos que activan operaciones, las cuales modifican el estado de los objetos. Las
operaciones aparecen como objetos que hacen solicitudes a otros objetos. El analista crea
diagramas de la estructura de los objetos y de los eventos que los modifican. El modelo del
diseador es similar al modelo del analista, pero se toma con el detalle suficiente como para
crear el cdigo. El anlisis y diseo orientado a objetos intenta lograr la reutilizacin masiva de
las clases de objetos. Modela el mundo en trminos de objetos que tienen propiedades y
comportamientos, y eventos que activan operaciones que modifican el estado de los objetos.
Los objetos interactan de manera formal con otros objetos.

PROGRAMACIN ORIENTADA A OBJETO
La programacin orientada a objetos no es un concepto nuevo, sus inicios y tcnicas de
programacin se iniciaron a principios de los 70. Se puede definir programacin orientada a
objetos (OOPS) como una tcnica de programacin que utiliza objetos como bloque esencial
de construccin. La OOPS, es un tipo de programacin ms cercana al razonamiento humano.
La OOPS surge como una solucin a la programacin de grandes programas, y para solventar el
mantenimiento de dichas aplicaciones, ya que en la programacin estructura el ms mnimo
cambio supone la modificacin de muchas funciones relacionadas, en cambio con la OOPS solo
es cuestin de aadir o modificar mtodos de una clase o mejor, crear una nueva clase a partir
de otra (Herencia).

OBJETO
Los objetos son las cosas fsicas y conceptuales que encontramos en el universo alrededor de
nosotros. Hadware, software, documentos , seres humanos, los conceptos son todos los
ejemplos de los objetos.

CLASES
Las Clases son como plantillas o modelos que describen como se construyen ciertos tipos de
Objeto. Cada vez que se construye un Objeto de una Clase, se crea una instancia de esa
Clase("instance"). Una Clase es una coleccin de Objetos similares y un Objeto es una instancia
de una Clase. Se puede definir una Clase como un modelo que se utiliza para describir uno o
ms Objetos del mismo tipo.

HERENCIA
Una caracterstica muy importante de los Objetos y las Clases es la Herencia, una propiedad
que permite construir nuevos Objetos (Clases) a partir de unos ya existentes. Esto permite
crear "Sub-Clases" denominadas Clases Derivadas que comparten las propiedades de la Clase
de la cual derivan (Clase base). Las Clases derivadas heredan cdigo y datos de la clase base,
asimismo incorporan su propio cdigo y datos especiales. Se puede decir que la herencia
permite definir nuevas Clases a partir de las Clases ya existentes.

POLIMORFISMO
En un sentido literal, Polimorfismo significa la cualidad de tener ms de una forma. En el
contexto de POO, el Polimorfismo se refiere al hecho de que una simple operacin puede
tener diferente comportamiento en diferentes objetos. En otras palabras, diferentes objetos
reaccionan al mismo mensaje de modo diferente. Los primeros lenguajes de POO fueron
interpretados, de forma que el Polimorfismo se contemplaba en tiempo de ejecucin. Por
ejemplo, en C++, al ser un lenguaje compilado, el Polimorfismo se admite tanto en tiempo de
ejecucin como en tiempo de compilacin.

DIFERENCIAS. ANLISIS Y DISEO ESTRUCTURADO vs. ORIENTADO A OBJETO

- La metodologa de anlisis y diseo estructurado, examinan los sistemas desde el punto de
vista de las funciones o tareas que deben realizar, tareas que se van descomponiendo
sucesivamente en otras tareas mas pequeas y que forman los bloques o mdulos de las
aplicaciones. En la orientacin a objeto, por su parte, cobra mucho ms importancia el aspecto
de "modelado" del sistema, examinando el dominio del problema como un conjunto de
ojbetos que interactan entre s.

- En la metodologa de anlisis y diseo estructurado se produce una divisin entre los dos
elementos de un sistema: funciones que llevan a cabo los programas y datos que se almacenan
en archivos o bases de datos. Y por otro lado, la orientacin al objeto da un enfoque unificador
de ambos aspectos, que se unen en los objetos.

- En la metodologa de anlisis y diseo estructurado las herramientas que utilizan para el
anlisis son: Diagramas de Flujos de Datos, Diccionarios de Datos, Diagramas Entidad-Relacin,
Diagramas de Trancisin de Estado, Especificaciones de procesos. En las metodologas
orientadas a objetos se emplean distintos modelos que depende de la metodologa, entre los
principales estn Modelo de objetos, Modelo de Estado u Objeto-Estado, entre otros.

Adems, podemos agregar otras diferencias secundarias tales como:

- Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo orientado al
objeto.

- Aparece una nueva forma de concebir los lenguajes de programacin y su uso al
incorporarse bibliotecas de clases y otros componentes reutilizables.

- Hay un alto grado de iteracin y solapamiento, lo que lleva a una forma de trabajo muy
dinmica.

CASO PRCTICO

A continuacin se describe el diseo de un sistema Web realizado por mi persona utilizando el
Lenguaje de Modelado Unificado UML.

Antes de comenzar con la descripcin del caso prctico, veamos algunos conceptos:

QU ES UML?
"El Lenguaje de Modelado Unificado UML es un lenguaje estndar para escribir planos de
software. UML puede utilizarse para visualizar, especificar, construir y documentar los
artefactos de un sistema que involucra gran cantidad de software"
El UML es el Lenguaje de Modelado Unificado Orientado a Objetos, UML no es un mtodo
porque no tiene nocin de proceso el cual es una parte importante de un mtodo. Ahora bien
si UML no es mtodo; entonces Cules son las etapas a seguir en el desarrollo de sistemas
con UML?, varios especialistas en desarrollo de sistemas de informacin arguyen de que existe
la necesidad de adoptar un Proceso de Desarrollo de sistemas para enmarcar las fases
importantes que sigue el UML, por ello los desarrolladores de proyectos de sistemas de
informacin emplean el Procesos Unificado para dar soluciones adecuadas a las necesidades
de los clientes.

El desarrollo de sistemas con UML siguiendo el proceso unificado incluye actividades
especficas, cada una de ellas a su vez contienen otras subactividades las cuales sirven como
una gua de cmo deben ser las actividades desarrolladas y secuenciadas con el fin de obtener
sistemas exitosos; consecuentemente el desarrollo de los sistemas puede variar de
desarrollador en desarrollador, de proyecto en proyecto, de empresa en empresa adoptando
siempre un Proceso de Desarrollo.


DIAGRAMAS UML
Los elementos de UML se muestran mediante diagramas que presentan mltiples vistas del
sistema, ese conjunto de vistas son conocidos como modelos .

UML presenta varios diagramas donde cada uno representa un aspecto del sistema. De ah que
varios investigadores segn sus criterios y puntos de vista mencionan qu diagramas emplear
en el desarrollo de los sistemas de informacin; sin mencionar cules son los diagramas ms
adecuados en las distintas etapas de desarrollo del Proceso Unificado, viendo esta necesidad,
la autora del presente artculo propone un conjunto de diagramas necesarios para cada etapa
segn la complejidad del sistema de informacin a solucionar.

Dado un sistema a desarrollar no es necesario emplear todos los diagramas; para sistemas
sencillos un diagrama de clases junto con un par de diagramas de actividades e interaccin
sera suficiente, asimismo si los sistemas son complejos requieren de la utilizacin de ms
diagramas, debido a que requieren de etapas incrementales e iterativas(ciclos de desarrollo)
en el anlisis, diseo e implementacin, por ello es que el conjunto actividades deber
especificar la etapa de desarrollo y los diagramas recomendados

Luego de haber dado un breve marco terico se proceder a la descripcin del caso prctico.

DESCRIPCIN DEL CASO PRCTICO

IDENTIFICAR LOS CASOS DE USO

En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la cual se le va a
presentar la solucin que est buscando. Para lograr ste objetivo se plantean los siguientes
puntos:

1. Actores o Usuarios

- Representan usuarios y otros sistemas que interaccionan con el sistema.

- Representan el tipo de usuario, no una instancia de usuario.

- No son parte del sistema que se desarrolla.

- Suministran y reciben informacin al sistema.


2. Por qu se disea el sistema?

El sistema actual presenta varias limitantes entre las cuales destacan:

- Es un sistema cuyo nivel de automatizacin del proceso es muy bajo.

- Asignacin manual de las acciones a tomar por parte del personal.

- Insuficiente informacin para el anlisis.

- No es ptimo el tiempo de respuesta para dar solucin a los problemas.

Los usuarios de la versin actual del sistema evaluaron la funcionalidad y eficiencia del mismo
se lleg a la conclusin de que no satisface los requerimientos del momento para las
organizaciones implicadas.

3. Roles y Funciones de los Usuarios

- Usuarios 01: personas encargadas de interactuar directamente con el sistema.

- Usuarios 02: operan otra aplicacin, la cual tiene una interfaz que permite ejecutar el sistema
en estudio.

- Analista(s) Custodio(s): encargados de la supervisin y mantenimiento del sistema.

4. Otros Sistemas e Interfaces

Existen dos aplicaciones con las cules interacta la aplicacin

Una vez realizado ste anlisis se proceder a modelar el diagrama de "Casos de Uso" de la
aplicacin. Luego de obtener el diagrama de "Casos de Uso", se obtendrn las clases, una vez
obtenido el "Diagrama de Clases" se generar el "Modelo Lgico de Datos" y por ltimo el
"Modelo Fsico de Datos". Todos estos diagramas sern realizados con la herramienta "Power
Designer" v. 10

En resumen los pasos a realizar utilizando el Lenguaje de Modelado Unificado para ste caso
prctico son los siguientes:

- Identicar los Casos de Uso.

- Identificar las Clases, tomando como base el diagrama de "Casos de Uso".

- Generar el Modelo Lgico de Datos

- Por ltimo generar el Modelo Fsico de Datos

Una vez realizados los pasos anteriormente mencionados iniciar el diseo del prototipo de la
aplicacin.