Paradigma del desarrollo de Sistemas (Programacin Estructurada)

1.1. INTRODUCCIN

El desarrollo estructurado comenz con la programacin. A mediados de los 60 el enfoque

estructurado se extiende a la fase de diseo que se conoce como diseo estructurado, el
cual se basa en definir una abstraccin ms amplia usando los mdulos de programa
como componentes bsicos de construccin. A mediados de los 70, se empezaron a
surgir las tcnicas estructuradas, donde se empez a construir programas de una forma
artesanal con mtodos de ingeniera. El desarrollo estructurado permiti facilitar la
comprensin de programas, normas para la aplicacin de estructuras de datos y de
control.
En el diseo estructurado se caracteriza por lo siguiente:

Mayor nivel de abstraccin (independencia del lenguaje programacin).

Elemento bsico de diseo: mdulo.
Modularidad que permite medir la calidad de programas.
Representa los procesos, flujos y estructuras de datos, de una manera jerrquica y
descendente.
Ven el sistema como entradas-proceso-salidas.
Se concentran en la parte del proceso.
Se lee de porciones, independientes de las especificaciones.

Aunque este desarrollo permite disear un buen proceso y estructura de un programa,

tiene inconvenientes como:

Leer todas las especificaciones para entender el problema.

Se repeta la misma informacin en partes diferentes del documento.
El enfoque de requisitos se interpretaba diferente por cada usuario.
Cuando se finalizaba el proceso de desarrollo las especificaciones eran obsoletas.

Este enfoque se conoce como anlisis estructurado o anlisis descendente o top-down.

Desde su aparicin se han hecho mejoras como dar menor importancia a la construccin
de los modelos fsicos actuales y a los modelos lgicos actuales, diferenciar ms los
modelos fsicos y lgicos. Ampliar las tcnicas de anlisis estructurado, para modelar
sistemas en tiempo real y enfocarse en el modelo de datos.
En el desarrollo estructurado los programas estn divididos en distintos bloques, estos
bloques tienen funciones que se van confeccionado en forma de arriba-abajo, empezando
desde las generales hasta las particulares, hasta llegar a detallar cada uno de los
procedimientos y su interaccin. Este desarrollo se enfoca al diseo del programa y la
compresin se hace ms fcil. Se ha hecho evidente que este enfoque an est un poco
arraigado ya que se tiende a no pasar de un proceso o iteracin a otra, sin culminar con la
anterior, adems que el ciclo de vida debe recorrerse completo y al manejarse de esta
manera, trae como consecuencias informacin redundante, costos y desperdicio de
tiempo.
1.2.1. CARACTERSTICAS DESEABLES DE UNA METODOLOGA
Existencia de reglas predefinidas, fases y subfases, tareas, productos intermedios,
tcnicas y herramientas tales que se amolden a cualquier desarrollo.
Cobertura total del ciclo de desarrollo.
 Verificaciones intermedias.
Planificacin y control.
Comunicacin efectiva.
Utilizacin sobre un abanico amplio de proyectos.
Fcil formacin.
Herramientas case.
La metodologa debe contener actividades que mejoren el proceso de desarrollo.
Soporte al mantenimiento. Por ejemplo. Reingeniera.
Soporte de la reutilizacin de software, no solo reutilizacin de cdigo.
Actualmente, se huye de mtodos muy burocrticos o monolticos.

Se dice entonces que una metodologa es la que permita definir las etapas, las salidas,
entradas de un proyecto. Mantener un programa no es fcil, pero se puede lograr, por lo
tanto, las metodologas deben permitir una robusta formacin del proyecto que permita
utilizar mecanismos de mejora y que se usen los recursos disponibles con su mayor
rendimiento y eficacia.
1.2.2. METODOLOGAS VS. CICLO DE VIDA

Una metodologa es un conjunto integrado de tcnicas y mtodos que permite abordar de

forma homognea y abierta cada una de las actividades del ciclo de vida de un proyecto
de desarrollo. Una definicin estndar de metodologa puede ser el conjunto de mtodos
que se utilizan en una determinada actividad con el fin de formalizarla y optimizarla.
Determina los pasos a seguir y cmo realizarlos para finalizar una tarea.
Si esto se aplica a la Ingeniera de software, podemos destacar que una metodologa:

Optimiza el proceso y el producto software.

Es una gua en la planificacin y en el desarrollo del software.
Define qu hacer, cmo y cundo durante todo el desarrollo y mantenimiento de
un proyecto.

Una metodologa define una estrategia global para enfrentarse con el proyecto. Entre los
elementos que forman parte de una metodologa se pueden destacar:

Fases: tareas a realizar en cada fase.

Productos: E/S de cada fase, documentos.
Procedimientos y herramientas: apoyo a la realizacin de cada tarea.
Criterios de evaluacin: del proceso y del producto. Saber si se han logrado los
objetivos.

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se est
desarrollando desde que nace la idea inicial hasta que el software es retirado o
remplazado.
Entre las funciones que debe tener un ciclo de vida se pueden destacar:

Determinar el orden de las fases del proceso de software.

Establecer los criterios de transicin para pasar de una fase a la siguiente.

1
 Definir las entradas y salidas de cada fase.
Describir los estados por los que pasa el producto.
Describir las actividades a realizar para transformar el producto.
Definir un esquema que sirve como base para planificar, organizar, coordinar,
desarrollar, entre otros.

Las etapas de un ciclo de vida de un software son:

Inicio: ste es el nacimiento de la idea. Aqu definimos los objetivos del proyecto y
los recursos necesarios para su ejecucin. Hacia dnde queremos ir, y no cmo
queremos ir. Las caractersticas implcitas o explcitas de cada proyecto hacen
necesaria una etapa previa destinada a obtener el objetivo por el cual se escribirn
miles o cientos de miles de lneas de cdigo. Un alto porcentaje del xito de
nuestro proyecto se definir en estas etapas que, al igual que la etapa de
debugging, muchos lderes de proyecto subestiman.
Planificacin: idearemos un planeamiento detallado que gue la gestin del
proyecto, temporal y econmicamente.
Implementacin: acordaremos el conjunto de actividades que componen la
realizacin del producto. Puesta en produccin: nuestro proyecto entra en la etapa
de definicin, all donde se lo presentamos al cliente o usuario final, sabiendo que
funciona correctamente y responde a los requerimientos solicitados en su
momento. Esta etapa es muy importante no slo por representar la aceptacin o
no del proyecto por parte del cliente o usuario final sino perlas mltiples
dificultades que suele presentar en la prctica, alargndose excesivamente y
provocando costos no previstos.
Control en produccin: control del producto, analizando cmo el proceso difiere
o no de los requerimientos originales e iniciando las acciones correctivas si fuesen
necesarias. Cuando decimos que hay que corregir el producto, hacemos
referencia a pequeas desviaciones de los requerimientos originales que puedan
llegar a surgir en el ambiente productivo. Si nuestro programa no realiza la tarea
para lo cual fue creada, esta etapa no es la adecuada para el rediseo. Incluimos
tambin en esta etapa el liderazgo, documentacin y capacitacin, proporcionando
directivas a los recursos humanos, para que hagan su trabajo en forma correcta y
efectiva.

1.2.3. OBJETIVOS DE CADA ETAPA:

Expresin de necesidades: Esta etapa tiene como objetivo el armado de un

documento en el cual se reflejan los requerimientos y funcionalidades que ofrecer
al usuario el sistema a implementar (qu, y no cmo, se va a implementar).
Especificaciones: Formalizamos los requerimientos; el documento obtenido en la
etapa anterior se tomar como punto de partida para esta etapa.
Anlisis: Determinamos los elementos que intervienen en el sistema a desarrollar,
su estructura, relaciones, evolucin temporal, funcionalidades, tendremos una
descripcin clara de qu producto vamos a construir, qu funcionalidades aportar
y qu comportamiento tendr.

2
 Diseo: Ya sabemos qu hacer, ahora tenemos que determinar cmo debemos
hacerlo (cmo debe ser construido el sistema en cuestin?); definimos en detalle
entidades y relaciones de las bases de datos, seleccionamos el lenguaje que
vamos a utilizar, el Sistema Gestor de Bases de Datos, entre otros).
Implementacin: Empezamos a codificar algoritmos y estructuras de datos,
definidos en las etapas anteriores, en el correspondiente lenguaje de
programacin o para un determinado sistema gestor de bases de datos. En
muchos proyectos se pasa directamente a esta etapa; son proyectos muy
arriesgados que adoptan un modelo de ciclo de vida de code & fix (codificar y
corregir) donde se eliminan las etapas de especificaciones, anlisis y diseo con la
consiguiente prdida de control sobre la gestin del proyecto.
Debugging (Depuracin): El objetivo de esta etapa es garantizar que nuestro
programa no contiene errores de diseo o codificacin. En esta etapa no
deseamos saber si nuestro programa realiza lo que solicit el usuario, esa tarea le
corresponde a la etapa de implementacin. En sta deseamos encontrar la mayor
cantidad de errores. Todos los programas contienen errores: encontrarlos es
cuestin de tiempo. Lo ideal es encontrarla mayora, si no todos, en esta etapa.
Tambin se pueden agregar pruebas de rendimiento.
Validacin: Esta etapa tiene como objetivo la verificacin de que el sistema
desarrollado cumple con los requerimientos expresados inicialmente por el cliente
y que han dado lugar al presente proyecto. En muchos proyectos las etapas de
validacin y debugging se realizan en paralelo por la estrecha relacin que llevan.
Sin embargo, tenemos que evitar la confusin: podemos realizarlos en paralelo,
pero no como una nica etapa.
Evolucin: En la mayora de los proyectos se considera esta etapa como
Mantenimiento y evolucin, y se le asigna, no slo el agregado de nuevas
funcionalidades (evolucin); sino la correccin de errores que surgen
(mantenimiento). En la prctica esta denominacin no es del todo errnea, ya que
es posible que aun luego de una etapa de debugging y validacin exhaustiva, se
filtren errores.

Una metodologa puede seguir uno o varios modelos de ciclo de vida, adaptndose a
cada uno de ellos, dependiendo de las necesidades dadas en un momento determinado,
es decir, el ciclo de vida indica lo que hay que obtener a lo largo del desarrollo del
proyecto, pero no da las indicaciones de cmo obtenerlo. La metodologa indica los
diferentes pasos y fases para obtener los distintos productos parciales y finales. En s
para el desarrollo de software, se necesita aplicar una metodologa o varias metodologas,
dentro de un ciclo de vida, de manera que sepamos qu hacer y cmo hacerlo para
conseguir lo que se quiere y cumplir con las metas planteadas.
1.3. MODELOS DE PROCESOS EN EL DESARROLLO DE SOFTWARE

Un modelo de proceso para el desarrollo de software es una representacin simplificada

de pasos, representada desde una perspectiva especfica. Por su naturaleza los modelos
son simplificados, por lo tanto, un modelo de procesos del software es una abstraccin de
un proceso real.

3
Estos modelos tienen como propsito la produccin eficaz y eficiente de un producto
software que rena los requisitos del cliente. Este proceso es intensamente intelectual,
afectado por la creatividad y juicio de las personas involucradas. La mayora de los
modelos de procesos de desarrollo del software son dirigidos por el tiempo; cuanto ms
tarde sea, ms atrs se encontrar en el proceso de desarrollo. Como todo proceso, estn
constituidos de pasos o fases que contienen a su vez actividades, estos modelos de
desarrollo de software se basan en un ciclo de vida para desarrollar el mismo, como lo
son:

La necesidad de solucionar un problema (surgimiento de necesidades)

Inicio del proceso (desarrollo), dentro de esta fase se encuentra la definicin del
proyecto, el anlisis del contexto, definicin de requerimientos, diseo del sistema,
construccin del sistema, pruebas e implantacin.
Operacin y mantenimiento, donde realiza ajustes y se buscan fallas.
Renovacin o extincin.

Los procesos de software son complejos debido a que un producto de software es

intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus
requisitos, sobre todo cuando no se tiene precedentes en productos software similares.
En general este producto est compuesto por hardware y software. En cuanto al
hardware, su produccin se realiza sistemticamente y la base de conocimiento para el
desarrollo de dicha actividad est claramente definida. Respecto del software, su
construccin y resultados han sido histricamente cuestionados debido a los problemas
asociados.
Los modelos de procesos permiten al analista de sistemas desarrollar un plan de
requisitos del software, permiten establecer un trabajo en forma ordenada, adems que
existen muchos modelos que se adaptan a las exigencias del proyecto, solo debemos
saber cual nos conviene, pero lo ms importante, es que estos modelos nos llevan a
presentar los proyectos al cliente de manera que ste vea su diseo y sus funciones y que
la mayora de ellos estn orientados al mantenimiento.
2. CLASIFICACIN DE LAS METODOLOGAS SEGN EL MODELO DE PROCESO
2.1. MODELOS CONVENCIONALES O PRESCRIPTIVOS DE PROCESOS

Los modelos convencionales o modelos prescriptivos de procesos permiten llenar el

marco de trabajo con un conjunto de tareas orientadas al desarrollo de un software.
Se les llama "prescriptivos" porque prescriben un conjunto de elementos del proceso,
tales como:

Actividades del Marco de Trabajo.

Acciones de la Ingeniera del software.
Tareas.
Productos de trabajo.
Aseguramiento de la calidad.
Mecanismos de control del cambio para cada proyecto.

4
Estos modelos son tiles si queremos describir un conjunto nico de actividades dentro de
un marco de trabajo para un proceso de software. cada actividad debe contener un
conjunto de acciones de ingeniera del software, y definir cada accin en cuanto a un
conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben
completarse para alcanzar las metas de desarrollo. Sin importar el modelo del proceso
que se desee usar, los ingenieros de software eligen una manera tradicional para realizar
el marco de trabajo genrico para el proceso, ya que estos modelos se caracterizan por
ser en esencia rgidos, estrictos y los ms utilizados.
En las metodologas convencionales, el ciclo de vida de un proyecto, puede definirse
como un ciclo de vida lineal, ya que imponen una disciplina de trabajo sobre el proceso de
desarrollo del software, con el fin de conseguir un software ms eficiente. Para ello, se
hace nfasis en la planificacin total de todo el trabajo realizar y una vez que est todo
detallado, comienza el ciclo de desarrollo del producto software. Se centran
especialmente en el control del proceso, mediante una rigurosa definicin de roles,
actividades, artefactos, herramientas y notaciones para el modelado y documentacin
detallada. Adems, las metodologas tradicionales no se adaptan adecuadamente a los
cambios, por lo que no son mtodos adecuados cuando se trabaja en un entorno, donde
los requisitos no pueden predecirse o bien pueden variar.
Los modelos prescriptivos de proceso definen un conjunto distinto de actividades,
acciones, tareas fundamentos y productos de trabajo que se requieren para desarrollar
software de alta calidad. Los ingenieros de software y sugerentes deben adaptar un
modelo prescripto de proceso a sus necesidades y despus lo siguen. Adems, la gente
que ha solicitado el software tiene un papel por desempear se ejecuta el modelo de
software. Por qu es importante? Porque proporciona estabilidad, control y organizacin
a una actividad que si no se controla puede volverse catica. Cules son los pasos? El
proceso conduce a un equipo de software a travs de un conjunto de actividades del
marco de trabajo que se organizan en un flujo de proceso. Cul es un obtenido? Desde
punto de vista de un ingeniero de software, los productos de trabajo son los programas,
documentos y datos que se producen como consecuencia de las actividades y tareas que
define el proceso.
2.2.1. MODELO EN CASCADA

El modelo en cascada, algunas veces llamado el ciclo de vida clsico, sugiere un enfoque
sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin
de requerimientos del cliente y que contina con la planeacin, el modelado, la
construccin y el despliegue para culminar en el soporte del software terminado.

A. Estructura de Modelo en Cascada

5
Este modelo es aplicable en donde existen ocasiones en que los requisitos de un
problema se entienden de una manera razonable y deben estar bien definidos, tambin
cuando el trabajo fluye desde la comunicacin a travs del despliegue de una manera casi
lineal, esta situacin se encuentra a veces cuando es necesario hacer adaptaciones o
mejoras bien definidas a un sistema existente. El modelo en cascada es el paradigma
ms antiguo para la ingeniera del software. Sin embargo, en las dcadas pasadas, las
crticas a este modelo de proceso han ocasionado que aun sus ms fervientes
practicantes hayan cuestionado su eficacia.
Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada
estn:
1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el
modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera
indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto
acta.
2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera
explcita. El modelo en cascada lo requiere y se enfrentan dificultades al
incorporarla incertidumbre natural presente en el inicio de muchos proyectos.
3. El cliente debe tener paciencia. Una versin que funcione de los programas estar
disponible cuando el proyecto est muy avanzado. Un error grave ser desastroso
si no se detecta antes de la revisin del programa. En un anlisis interesante de
proyectos reales, Bradac (1994) concluy que la naturaleza lineal del modelo en
cascada conduce a "estados de bloqueo" en los cuales algunos miembros del
equipo del proyecto deben esperar a otros para terminar tareas dependientes. De
hecho, el tiempo de espera puede superar el que se aplica en el trabajo
productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del
proceso secuencial.

En la actualidad, el trabajo del software est acelerado y sujeto a una cadena infinita de
cambios (de caractersticas, funciones y contenido de la informacin). Con frecuencia, el
modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como
un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el
trabajo se realiza, hasta su conclusin, de una manera lineal. Las principales etapas de
este modelo segn Sommerville (2005) son:

Anlisis y definicin de requerimientos. Los servicios, restricciones y metas del

sistema se definen a partir de las consultas con los usuarios. Se define una
especificacin del sistema.
Diseo del sistema y del software. El proceso de diseo del sistema divide los
requerimientos en sistemas hardware o software. Establece una arquitectura
completa del sistema. El diseo del software identifica y describe las abstracciones
fundamentales del sistema software y sus relaciones.
Implementacin y prueba de unidades. Durante esta etapa, el diseo del
software se lleva a cabo como un conjunto o unidades de programas. Integracin y
prueba del sistema. Los programas o las unidades individuales de programas se

6
 integran y prueban como un sistema completo para asegurar que se cumplan los
requerimientos del software.
Funcionamiento y mantenimiento. El sistema se instala y se pone en
funcionamiento prctico. El mantenimiento implica corregir errores no descubiertos
en las etapas anteriores del ciclo de vida.

2.2.2. MODELO DE PROCESOS INCREMENTABLES

El modelo incremental combina elementos del modelo en cascada aplicado en forma

iterativa. El modelo incremental aplica secuencias lineales de manera escalonada
conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos"
del software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma
incremental en su primer incremento, podra realizar funciones bsicas de administracin
de archivos, edicin y produccin de documentos; en el segundo incremento, ediciones
ms sofisticadas, y tendra funciones ms complejas de produccin de documentos; en el
tercer incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto,
capacidades avanzadas de configuracin de pgina. Se debe tener en cuenta que el flujo
del proceso de cualquier incremento puede incorporar el paradigma de construccin de
prototipos que se expone ms adelante.
A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial.
Es decir, se incorporan los requisitos bsicos, pero muchas caractersticas suplementarias
(algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del
cliente (o se somete a una evaluacin detallada). Como resultado de la evaluacin se
desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del
producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la
entrega de caractersticas y funcionalidades adicionales. Este proceso se repite despus
de la entrega de cada incremento mientras no se haya elaborado el producto completo.

B. Estructura de Modelo Incremental

El modelo de proceso incremental, al igual que la construccin de prototipos otros
enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de
prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con
cada incremento. Los primeros incrementos son versiones incompletas del producto final,
pero proporcionan al usuario la funcionalidad que necesita y una plataforma para

7
evaluarlo. El desarrollo incremental es til sobre todo cuando el personal necesario para
una implementacin completa no est disponible. Los primeros incrementos se pueden
implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se
requiere) ms personal para implementar el incremento siguiente. Adems, los
incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un
sistema grande podra requerir la disponibilidad de un hardware nuevo que est en
desarrollo y cuya fecha de entrega es incierta. Sera posible planear los primeros
incrementos de forma que se evite el uso de este hardware, lo que permitira la entrega de
funcionalidad parcial a los usuarios finales sin retrasos desordenados.
Combina elementos del modelo en cascada aplicado en forma iterativa. El modelo
incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo
en el calendario. Cada secuencia lineal produce incrementos. Produce entregas de
software pequeas pero usables (incrementos). Cada parte se construye sobre partes ya
entregadas.
2.2.3. MODELO DE DESARROLLO RPIDO DE APLICACIONES (DRA)

El desarrollo rpido de aplicaciones (DRA) es un modelo de proceso de software

incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptacin a
"alta velocidad" del modelo en cascada en el que se logra el desarrollo rpido mediante
un enfoque de construccin basado en componentes. Si se entienden bien los requisitos y
se limita el mbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree
un "sistema completamente funcional dentro de un periodo muy corto (por ejemplo, de 60
a 90 das).
Como otros modelos de proceso, el enfoque DRA cumple con las actividades genricas
del marco de trabajo que ya se han presentado. La comunicacin trabaja para entender el
problema de negocios y las caractersticas de informacin que debe incluir el software. La
planeacin es esencial porque varios equipos de software trabajan en paralelo sobre
diferentes funciones del sistema. El modelado incluye tres grandes fases modelado de
negocios, modelado de datos y modelado del proceso y establece representaciones del
diseo que sirven como base para la actividad de construccin del modelo DRA. La
construccin resalta el empleo de componentes de software existente y la aplicacin de la
generacin automtica de cdigo. Por ltimo, el despliegue establece una base para las
iteraciones subsecuentes, si stas son necesarias.
El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las restricciones
de tiempo impuestas sobre un proyecto DRA exigen un "mbito de escalas". Si una
aplicacin de negocios se puede modular de forma que cada gran funcin pueda
completarse en menos de tres meses (mediante la aplicacin del enfoque ya descrito),
sta es una candidata para el DRA. Cada gran funcin se puede abordar mediante un
equipo de DRA por separado, para despus integrarlas y formar un todo.
Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes:
1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos
humanos para crear en nmero correcto de equipos DRA.

8
 2) Si los desarrolladores y clientes no se comprometen con las actividades rpidas
necesarias para completar el sistema en un marco de tiempo muy breve, los
proyectos DRA fallarn.
3) Si un sistema no se puede modular en forma apropiada, la construccin de los
componentes necesarios para el DRA ser problemtica.
4) Si el alto rendimiento es un aspecto importante, y se alcanzar al convertir
interfaces en componentes del sistema, el enfoque DRA podra no funcionar.
5) El DRA sera inapropiado cuando los riesgos tcnicos son altos (por ejemplo,
cuando una aplicacin nueva aplica muchas nuevas tecnologas).

Es un modelo de proceso del software incremental que resulta un ciclo de desarrollo

corto. El modelo DRA es una adaptacin a alta velocidad del modelo en cascada en el
que se logra el desarrollo rpido mediante un enfoque deconstruccin basado en
componentes. Hace un uso intensivo de componentes reusables de software con un ciclo
de desarrollo extremadamente corto.

C. Estructura de Modelo DRA

2.2.4. MODELOS EN FUNCIN DE PROTOTIPOS

Cuando en la etapa de anlisis se necesitan de tcnicas amigables para la elaboracin

del ERS, es recomendable el empleo de herramientas de levantamiento de informacin
como son los prototipos o modelos previos. Los modelos previos pueden ser en papel o
computadora para mostrar la interaccin hombre-mquina; un modelo que muestra
algunas funciones del software; o, algn software anterior (parte o todo) parecido al que
se desea, que luego ser modificado y adaptado segn los requerimientos del usuario.
El paradigma de construccin de prototipos comienza con la recoleccin de requisitos. El
desarrollador y el cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos, y las reas del esquema en donde es obligatoria ms
definicin. Entonces aparece un <<diseo rpido>>.
El diseo rpido se centra en una representacin de esos aspectos del software que
sern visibles para el usuario/cliente (p. Ej.: enfoques de entrada y formatos de salida). El
diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el
cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. La

9
interaccin ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que
permite que el desarrollador comprenda mejor lo que se necesita hacer.

D. Ejemplo de Modelo En Funcin de Prototipos

Lo ideal sera que el prototipo sirviera como un mecanismo para identificar los requisitos
del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de
los fragmentos del programa ya existentes o aplica herramientas (p. Ej.: generadores de
informes, gestores de ventanas, etc.) que permiten generar rpidamente programas de
trabajo.
El paradigma de la elaboracin por prototipos resulta una alternativa para el desarrollo
rpido de aplicaciones de software; pues el analista acorta en tiempo entre la
determinacin de los requerimientos de informacin y la entrega de un sistema funcional,
adems que el usuario podr modificar y depurar sus requerimientos conforme avance el
desarrollo del proyecto.
El paradigma de prototipos es aplicable a proyectos de anlisis acelerado, donde slo se
cuente con requisitos generales; a proyectos con clientes impacientes de ver algo
funcionando; a proyectos con clientes dispuestos a reaccionar abiertamente con el
prototipo. No es recomendable aplicarlo a proyectos con clientes exigentes de calidad,
pues los prototipos son susceptibles a muchos fallos, y el cliente se puede formar una
idea equivocada de la seriedad del desarrollador.
2.2.5. MODELO EN ESPIRAL

Propuesto por Boehm en 1988 con la finalidad de paliar los inconvenientes del modelo en
cascad y adecuar el desarrollo por prototipos a problemas complejos. Este paradigma
combina el paradigma de cascada y el de construccin por prototipos, agregando una
etapa de "anlisis de riesgo". El paradigma de espiral es un modelo de ciclo de vida
orientado a riesgos que divide un proyecto software en mini-proyectos y donde cada mini-
proyecto se centra en uno o ms riesgos importantes hasta que todos estos estn
controlados. Este modelo se realiza en varias iteraciones; se parte de una escala pequea
la cual comienza con la identificacin de objetivos, alternativas y restricciones; en medio
de la espiral, se localizan riesgos, se genera un plan para manejarlos, y a continuacin se
establece una aproximacin a la siguiente iteracin.

10
Se proporciona el potencial para el desarrollo rpido de versiones incremntales del
software. En el modelo espiral, el software se desarrolla en una serie de versiones
incremntales. Durante las primeras iteraciones, la versin incrementar podra ser un
modelo en papel prototipo. Durante las ltimas iteraciones, se producen versiones cada
vez ms completas de ingeniera del sistema. El modelo en espiral se divide en un
nmero de actividades estructurales tambin llamadas guiones de tareas. Estas inclusive
pueden variar de 3 a 6 tareas.
Cuando empieza este proceso evolutivo, el equipo de ingeniera del software gira
alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro. El
primer circuito de la espiral produce el desarrollo de una especificacin de productos; los
pasos siguientes en la espiral se podran utilizar para desarrollar un prototipo y
progresivamente versiones ms sofisticadas del software. Cada paso de la regin de
planificacin produce ajustes en el plan del proyecto. El costo y la planificacin se ajustan
segn la reaccin ante la evaluacin del cliente. Adems, el gestor del proyecto ajusta el
nmero planificado de iteraciones requeridas para completar el software.
En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativo hasta
que el software de se retira. Hay veces en que el proceso est inactivo, pero siempre que
se inicie un cambio, el proceso arranca en el punto de entrada adecuado (p. Ej.: mejora el
producto). El modelo en espiral es un enfoque realista del desarrollo de sistemas y de
software a gran escala. Como el software evoluciona, a medida que progresa el proceso,
el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de
los niveles evolutivos. El modelo en espiral utiliza la construccin de prototipos como
mecanismos de reduccin de riesgos, pero lo que es ms importante, permite a quien lo
desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de
evolucin del producto. Mantiene el enfoque sistemtico de los pasos sugeridos por el
ciclo de vida clsico, pero lo incorpora al marco de trabajo interactivo que refleja de forma
ms realista el mundo real. El modelo en espiral demanda una consideracin directa de
los riesgos tcnicos en todas las etapas del proyecto, y si se aplica adecuadamente, debe
reducir los riesgos antes de que se conviertan en problemticos.

E. Estructura de Modelo En Espiral

El modelo espiral es aplicable a proyectos donde no se trabaje bajo contrato, es decir,
proyectos que no involucren fuentes externas de software.
Este paradigma es poco recomendable para grupos de trabajo donde no se cuenta con un
equipo experto en anlisis de riesgos, o para proyectos donde los riesgos sean menores y
no se justifique la flexibilidad y gestin de riesgos que ofrece este paradigma.
2.2.6. MODELO DE ENSAMBLAJE DE COMPONENTES

11
Las tecnologas de objetos proporcionan el marco de trabajo tcnico para un modelo de
proceso basado en componentes para la ingeniera del software. El paradigma de
orientacin a objetos enfatiza la creacin de clases que encapsula tanto los datos como
los algoritmos que se utilizan para manejar los datos. Si se disean y se implementan
adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes
aplicaciones y arquitecturas de sistemas basados en computadora.
El modelo ensamblador de componentes configura aplicaciones desde componentes
preparados de software (algunas veces llamados << clases >>). La actividad de la
ingeniera comienza con la identificacin de clases candidatas. Esto se lleva a cabo
examinando los datos que se van a manejar por parte de la aplicacin y el algoritmo que
se va a aplicar para conseguir el tratamiento. Los datos y los algoritmos correspondientes
se empaquetan en una clase.
El modelo de ensamblaje de componentes incorpora muchas de las caractersticas del
modelo en espiral. Es evolutivo por naturaleza [NIE92], y exige un enfoque interactivo
para la creacin del software. Sin embargo, el modelo ensamblador de componentes
configura aplicaciones desde componentes preparados de software (algunas veces
llamados << clases >>).
El modelo ensamblador de componentes lleva a la reutilizacin del software, y la
reutilizacin proporciona beneficios a los ingenieros del software.
2.2.7. MODELO DE DESARROLLO CONCURRENTE

Definido por Davis y Sitaram [DAV94], el modelo de proceso concurrente se puede

representar en forma de esquema como una serie de actividades tcnicas importantes,
tareas, y estados asociados a ellas. Por ejemplo, la actividad de ingeniera definida para
el modelo en espiral, se lleva a cabo invocando las tareas siguientes: modelado de
construccin de prototipos y/o anlisis, especificacin de requisitos, y diseo.
El modelo de proceso concurrente define una serie de acontecimientos que disparan
transiciones de estado a estado para cada una de las actividades de la ingeniera del
software.
El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo
de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto
de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso
concurrente define actividades en dos dimensiones [SHE94]: una dimensin de sistemas
y una dimensin de componentes. Los aspectos del nivel de sistemas se afrontan
mediante tres actividades: diseo, ensamblaje y uso. La dimensin de componentes se
afronta con dos: diseo y realizacin. La concurrencia se logra de dos formas:
1) Las actividades de sistemas y de componentes ocurren simultneamente y
pueden moderarse con el enfoque orientado a objetos descrito anteriormente.
2) Una aplicacin cliente/servidor tpica se implementa con muchos componentes,
cada uno de los cuales se pueden disear y realizar concurrentemente.

En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de

software y proporciona una imagen exacta del estado actual de un proyecto. En vez de
confinar las actividades de ingeniera del software a una secuencia de sucesos, define

12
una red de actividades. Todas las actividades de la red existen simultneamente con
otras. Los sucesos generados dentro de una actividad dada o en algn otro lugar en la red
de actividad inicia las transiciones entre los estados de una actividad.
2.2.8. MODELO DE MTODOS FORMALES

El modelo de mtodos formales acompaa a un conjunto de actividades que conducen a

la especificacin matemtica del software de computadora. Los mtodos formales
permiten que un ingeniero del software especifique, desarrolle y verifique un sistema
basado en computadora aplicando una notacin rigurosa y matemtica.
La ambigedad, lo incompleto y la inconsistencia se descubren y se corrigen ms
fcilmente, no mediante una revisin a propsito para el caso, sino mediante la aplicacin
del anlisis matemtico. Cuando se utilizan mtodos formales durante el diseo, sirven
como base para la verificacin de programas y por consiguiente permiten que el ingeniero
del software descubra y corrija errores que no se pudieron detectar de otra manera.
Aunque todava no hay un enfoque establecido, los modelos de mtodos formales ofrecen
la promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran
preocupacin sobre su aplicabilidad en un entorno de gestin:
1) El desarrollo de modelos formales actualmente es bastante caro y lleva mucho
tiempo.
2) Se requiere un estudio caro porque pocos responsables del desarrollo de software
tienen los antecedentes necesarios para aplicar mtodos formales.
3) Es difcil utilizar los modelos como un mecanismo de comunicacin con clientes
que no tiene muchos conocimientos tcnicos.

No obstante, es posible que el enfoque a travs de mtodos formales tenga ms

partidarios entre los desarrolladores del software que deben construir software de mucha
seguridad (p. Ej.: los desarrolladores de avinica y dispositivos mdicos), y entre los
desarrolladores que pasan grandes penurias econmicas al aparecer errores de software.
2.3. CRITERIOS GENERALES PARA SELECCIONAR UN PARADIGMA

El ingeniero de sistemas debe estar en capacidad de seleccionar de manera correcta la

utilizacin de alguno de los paradigmas anteriormente mencionados o una combinacin
de ellos, evaluando las principales caractersticas del problema al cual se enfrentar.
Estas caractersticas se deben captar en la fase de anlisis general del sistema y debern
reforzarse en la etapa de anlisis detallado del sistema. Como puntos de evaluacin para
la seleccin del paradigma adecuado tenemos:

La naturaleza del proyecto, donde se agrupan criterios como la complejidad del

producto final, el conocimiento de la aplicacin por parte del grupo, la utilizacin
final del software, etc.
El control del proyecto y la importancia de los avances, directamente relacionado
con las caractersticas del cliente, sus perspectivas y deseos respecto al software,
la importancia de su inclusin en el grupo de desarrollo del producto, etc.

13
 Los mtodos y las herramientas disponibles para el desarrollo de cada una de las
fases a realizar.

3. TECNICA DE DISEO ESTRUCTURADO

3.1. OBJETIVOS DE LA TECNICA
Obtener la estructura modular y los detalles de proceso del sistema, partiendo
solamente de los productos obtenidos en la fase de Anlisis del Sistema.
Cambiar la atencin del QUE al COMO.
Obtener un diseo que no slo funcione, sino que tambin sea mantenible,
mejore la reutilizacin y se pueda probar y entender fcilmente.
Utilizar herramientas grficas (Diagramas de Estructura de Cuadros) para
representar la estructura modular del sistema.

Se trata, por tanto, de conseguir que cada mdulo de la estructura en rbol que se
obtenga cumpla las siguientes caractersticas:
1. Mdulos de pequeo tamao.
El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamao
de los mdulos es reducido, una determinada modificacin afectar a un nmero
mayor de mdulos, sin embargo, la cantidad de cdigo a considerar ser menor. O
Independencia modular. Cuanto mayor es la independencia de un mdulo es ms
sencillo trabajar con l, por tanto, el diseo debe reducir la comparticin de
ficheros, de datos, la de dispositivos, las interfaces comunes con el Sistema
Operativo y las llamadas, desde o hacia otros mdulos.
2. Caractersticas de Caja Negra.
La caracterstica de Caja Negra se aplica a cualquier sistema, programa o mdulo,
para dar una visin exclusiva de sus entradas y salidas, sin tener en cuenta los
detalles de cmo se realiza el proceso. El uso de la Caja Negra permite una visin
ms fcil del conjunto, posponiendo la consideracin de los detalles para una
etapa posterior.
3. Modelizacin conceptual.
Un sistema ser ms fcil de mantener si el modelo utilizado en su diseo se ha
basado en los conceptos lgicos de la organizacin, los cuales sern ms
familiares y comprensibles para el personal de mantenimiento que las
descripciones fsicas (equipo, organizacin de la unidad, cmo se realiza el trabajo
en la actualidad, ), o Aislamiento de los detalles. En un sistema existen partes
que reflejan la filosofa otras partes que reflejan los detalles. Debido a que los
detalles son ms susceptibles de cambiar, ambas partes deben disearse por
separado para evitar que una variacin en los detalles afecte a la filosofa del
sistema.

14
 Paradigma del desarrollo de Sistemas (POO)
1. INTRODUCCIN

Las mayores deficiencias (y desafos) en el proceso de desarrollo de software se

encuentran en sus primeras fases. La distancia entre el espacio del problema (Universo
de Discurso) y el espacio de la solucin (producto software) hace necesario que la
especificacin de requisitos del sistema, resultante del proceso de modelado conceptual,
tenga dos importantes propiedades: debe ser abstracta y declarativa.

2. MODELOS

A que nos referimos con modelo:

Modelo: abstraccin de algo, con el propsito de comprenderlo antes de

construirlo.
Modelos y abstraccin.

Un modelo sirve para:

Verificar una entidad fsica antes de su construccin.

Comunicarnos con otros usuarios.
Visualizar.
Disminuir la complejidad.
Abstraccin: examen selectivo de ciertos aspectos del problema, eliminando los
aspectos que no son importantes.
La abstraccin debe servir para un propsito que nos determina lo que no es
importante, delimitando nuestro universo.
Es posible obtener mltiples abstracciones de la misma cosa.
Todas las abstracciones son incompletas e inadecuadas.
Un buen modelo captura los aspectos cruciales del problema y omite el resto.

El modelo conceptual debe ser abstracto para facilitar la captacin y modelado de

aspectos del problema de una forma lo ms cercana posible a los conceptos del dominio
del problema. Esto es muy importante para la validacin del modelo obtenido, facilitando
la participacin del usuario en dicha tarea. En este sentido, el enfoque orientado a objeto
(OO) posibilita la elaboracin de entornos de produccin de software que resuelven
problemas clsicos asociados a la ya familiar nocin de "Crisis del Software''.
Entre las ventajas ms destacables del paradigma objetual en este contexto cabe sealar
las siguientes:

La encapsulacin bajo el concepto de objeto incluyendo las perspectivas esttica y

dinmica del sistema estudiado.
La desaparicin de barreras estrictas entre las distintas fases del ciclo de vida o
proceso de produccin de software.
La proximidad de sus nociones a los mecanismos cognitivos humanos reduciendo
as la distancia entre el problema y su solucin.

15
Por otra parte, el modelo conceptual debe ser declarativo de manera que permita
postergar decisiones de implementacin. Esta caracterstica nos separara de lo que
denominamos enfoques orientados a objetos clsicos, en los que la especificacin es
principalmente imperativa y se limita en general a la estructura de los objetos y los perfiles
de las operaciones.
La tarea de verificacin del modelo exige disponer de algn formalismo preciso y a la vez
con toda la capacidad expresiva necesaria para capturar todos los aspectos de inters del
problema. Las notaciones grficas son atractivas pues facilitan el modelado y la legibilidad
de una especificacin de requisitos, pero pierden estas ventajas cuando se sobrecargan
con detalles. Por otra parte, las representaciones puramente textuales, y ms aun siendo
formales, tienen el grado de detalle que se desee, pero exigen ms esfuerzo en su
utilizacin. Esto sugiere que metodolgicamente la mejor solucin es una combinacin de
ambas tcnicas: grficas y textuales. Como el objetivo es obtener un modelo completo y
preciso del sistema, una representacin textual final es la ms adecuada, pues tanto las
tcnicas textuales como las grficas pueden ser finalmente trasladadas a texto para
describir el modelo en su totalidad.
2.1. MODELO CONCEPTUAL

En la fase de Modelizacin Conceptual se construyen tres modelos del sistema:

Modelo de Objetos.
Modelo Dinmico.
Modelo Funcional.

Estos tres modelos describen la sociedad de objetos desde tres puntos de vista
complementarios.
2.1.1. MODELO ORIENTADO A OBJETOS.

El modelo orientado a objetos utiliza el paradigma de la orientacin a objetos para el

desarrollo de software. Este enfoque realiza la construccin de modelos de un sistema por
medio de la identificacin y la especificacin de un conjunto de objetos relacionados, que
colaboran entre s de acuerdo a los requerimientos establecidos para el sistema de
objetos.
La definicin del modelado orientado a objetos puede claramente dividir el enfoque en tres
dimensiones:

La dimensin estructural.
La dimensin dinmica.
La dimisin funcional.

Este tipo de modelado implica la realizacin de las siguientes actividades:

1) Identificar las clases, modelos y objetos. (objetos y atributos).
2) Asociar estticamente los objetos. (relaciones dependientes del dominio del
problema).
3) Especificacin del comportamiento de los objetos. (Definir como se comportarn
los objetos).

16
 4) Definir la jerarqua de herencia de las clases. (Definir la jerarqua de clases, para
que el sistema quede lo ms abstracto posible).

Caractersticas de los modelos Orientados a Objetos.

El modelado Orientado a Objetos est basado en el paradigma orientado a

objetos.
Trata el almacenamiento de objetos (persistencia de los objetos).
Define un lenguaje para le definicin y manipulacin de objetos.
Incluye mecanismos para optimizar el acceso (Indexacin y Clustering), el control
de la concurrencia, seguridad y gestin de usuarios, facilidad de consulta y
recuperacin ante fallos.
Debido a que es un esquema orientado a objetos incluye: Encapsulamiento,
herencia, polimorfismo, etc.

Describe la estructura de los objetos en un sistema (identidad, relaciones con otros

objetos, atributos y operaciones).
Marco en el que podemos ubicar los Modelos Dinmico y Funcional.
Los objetos son las unidades en las que dividiremos el mundo y que sern las
molculas de los distintos modelos.
Se representa de forma grfica mediante diagramas de objetos que contendrn
clases de objetos.
Las clases se disponen en jerarquas que comparten estructura y
comportamientos comunes, y que estn asociadas con otras clases.

A. Ejemplo de Modelo Orientado a Objetos

2.1.2. MODELO DINMICO.

El modelo dinmico est basado y constituido en aquellos aspectos de un sistema

relacionados con el tiempo (objetos y cambio de los mismos) a lo largo del tiempo. El
modelo dinmico describe el control del sistema, esto quiere decir, las secuencias que
ocurren como consecuencia del uso de los usuarios finales, sin tener en cuenta lo que
hacen las operaciones sobre que operan y como se implementan. Como ocurre en el
modelo orientado a objetos los objetos se comunican entre s a travs del paso de
mensajes (parmetros), a esta accin el modelo dinmico se denomina interaccin entre
objetos.

17
Los desgramas de estado, interaccin (secuencia, comunicacin, tempo y visin de
conjunto) son utilizados para describir como los objetos interactan dinmicamente. El
modelo dinmico est constituido principalmente por los diagramas de estado y de
actividad, a continuacin, se presentan las principales caractersticas de casa uno de
ellos:

Diagrama de Estado: Este tipo de diagrama indica de qu manera se comportan

los objetos durante su ciclo de vida, define el comportamiento del sistema
completo.
Caractersticas de los diagramas de estado:
o Los principales conceptos de un diagrama de estado son: los eventos los
estados. Un estado es un valor de los atributos de los objetos.
o El modelo dinmico consiste en mltiples diagramas de estado y muestra
el patrn de actividad para el sistema completo.
o ste tipo de diagramas contienen transiciones que son las relaciones entre
los objetos y los eventos que ocurren entra ellos.
Diagramas de actividad: Son utilizados para especificar el flujo de trabajo dentro
del sistema, a diferencia del diagrama de secuencia el diagrama de actividad no
modela el comportamiento de un sistema de software si no los procesos y los
flujos de un muy alto nivel. El diagrama de actividad define las siguientes
caractersticas:
o Proceso de negocio: Utilizado para definir como los objetos cambian para
definir una vista de alto nivel.
o Cartas de estados: Capturan los cambios del sistema a lo largo del tiempo.

En resumen, el UML contiene las herramientas necesarias para la definicin del modelo
dinmico de los sistemas de software mediante diversas herramientas que ayudan a
definir el comportamiento del sistema durante lo largo del tiempo. Cada tipo de diagrama
ayuda a capturar la informacin de los sistemas como un todo con todos los detalles del
mismo a travs de diagramas que definen el comportamiento.

B. Ejemplo de Diagrama
2.1.3. MODELO FUNCIONAL.

18
El modelo funcional representa todos los factores esenciales del desarrollo de software
ignorando aquellos que forman parte de los detalles ms especficos de sistema. Este
modelo parte de un propsito general bien especificado y de la manera ms simplificada
posible.
Desde una perspectiva ms general el modelo funcional se relaciona con el modelo
orientado a objetos, este modelo se relaciona con una entidad existente. ste modelo
tiene tres principios fundamentales:

Particionamiento
Abstraccin
Proyeccin

Este modelo est basado en conceptos de funciones o procesos, de modo que estos se
conviertan en el elemento ms importante de este enfoque. Este modelo describe los
clculos dentro del sistema, es decir lo que sucede. Comprende los siguientes tipos de
funciones:

Funcin asncrona: Una funcin asincrnica puede ser activado por otro objeto o
funcin para realizar alguna accin.
Funcin asncrona dependiente de un estado: Un asncrono dependiente del
estado es generalmente una funcin "one-shot" de accin, que se ejecuta durante
una transicin de un estado a otro estado. Esta funcin se activa mediante una
transformacin de control
Funcin peridica: Una funcin peridica se activa a intervalos regulares para
realizar alguna accin. La frecuencia con la que se activa una funcin especfica
depende de la aplicacin
Funcin peridica dependiente de un estado: Una funcin peridica se activa a
intervalos regulares para realizar alguna accin. La frecuencia con la que se activa
una funcin especfica depende de la aplicacin. Esta funcin se activa mediante
una transformacin de control

Un ejemplo de programas que utilizan este tipo de modelado pueden ser compiladores, ya
que por lo general este tipo de programas realizan clculos de las operaciones que tiene
que realizar un sistema. Por otra parte, las bases de datos a menudo tienen un modelo
funcional trivial, ya que su finalidad es almacenar y organizar datos, no transformarla.
El Mtodo Orientado a Objetos proporciona un modelo mediante el cual el analista slo
tiene que categorizar cada atributo de entre un conjunto predefinido de tres categoras no
disjuntas. Estas categoras determinan qu informacin se necesita para determinar cmo
cambia el valor del atributo ante la ocurrencia de determinados eventos.
Las tres categoras de atributos son:

Cardinales.
Independientes del estado.
De situacin.

19
Cardinales: sus eventos relevantes incrementan o decrementan su valor en una
determinada cantidad. Ej:

Categora: cardinal Clase: coche Atributo: cant-

alquileres

Tipo Accin Accin Efecto Cond. Evaluacin

Incremento USR:alquilar(...) +1

Decremento USR:devolver(...) -1

Independientes de estado: tienen un valor que slo depende de la ltima accin ocurrida.
Una vez ha ocurrido una accin relevante el nuevo valor del atributo es independiente del
valor que tena antes. Ej:

Categora: estado Clase: coche Atributo: ubicacin

Accin Efecto Cond. Evaluacin
USR: devolver(..., lugar, ...) = lugar
USR: = lugar
cambiar_de_base(lugar)
USR: reparar(...) = "taller:" + "nombre-taller"

De situacin: mediante la activacin de una accin portadora se le asigna al atributo un

valor de un dominio discreto. Ej:

Categora: situacin Clase: cliente Atributo: status

Accin Efecto Cond. Evaluacin
USR: alquilar(...) = "con-coche" Status <> "con-coche"
USR: devolver(...) = "sin-coche" nro-coches >= 2

La informacin que se obtiene al finalizar la construccin de los tres modelos constituye la

especificacin del sistema.
2.2. RELACIN ENTRE MODELOS
Cada modelo describe un aspecto del sistema manteniendo referencias al resto de
los modelos.
El Modelo de Objetos define las estructuras de datos sobre las que actuarn el
Modelo Dinmico y el Modelo Funcional.
Los sucesos sern las operaciones de los objetos definidas en el Modelo de
Objetos.
Puede existir una eventual ambigedad acerca de qu modelo debe contener
ciertos elementos de informacin.
Puede ocurrir que ciertas propiedades del sistema no queden bien expresadas por
ningn modelo, en cuyo caso el lenguaje natural ser la mejor alternativa.

20
2.3. MODELO DE EJECUCIN

Una vez especificado el sistema, un Modelo de Ejecucin establece:

1) Una representacin del modelo conceptual en un entorno de desarrollo,
atendiendo aspectos estticos y dinmicos (estrategia de generacin de cdigo).
2) Una estrategia de ejecucin.
Estrategia de generacin de cdigo.

Esta estrategia es un patrn genrico que define los componentes software a utilizar para
implementar en un entorno de desarrollo las propiedades del sistema utilizando una
arquitectura lgica de tres niveles (three-tier):

Nivel de interfaz: en este nivel se sitan los componentes que implementan la

interaccin con los usuarios finales, mostrando una representacin visual de los
datos y los servicios que ofrecen los objetos del sistema.
Nivel de aplicacin: en este nivel se sitan los componentes que implementan de
forma completa el comportamiento de las clases especificadas en la fase de
modelado conceptual.
Nivel de persistencia: en este nivel se sitan los componentes que proporcionan
los servicios necesarios para dar persistencia a los objetos del nivel de aplicacin.
La persistencia de los objetos actualmente se realiza recurriendo a un sistema
gestor de bases de datos relacional (SGBDR).
Estrategia de ejecucin.

Para animar el sistema especificado, se define una estrategia de ejecucin e interaccin.

Esta estrategia es cercana a las tcnicas de realidad virtual, en el sentido de que un
objeto activo se introduce en la sociedad de objetos como miembro de ella e interacta
con los dems enviando y recibiendo mensajes. Para iniciar una sesin de ejecucin, los
pasos a seguir son:
1) Identificacin del usuario (control de acceso): consiste en la conexin del usuario
al sistema. Una vez conectado se le proporciona una visin clara de la sociedad
de objetos (ofrecindole qu clases de objetos puede ver, los servicios que puede
activar y los atributos que puede consultar).
2) Activacin de servicios: el usuario podr activar cualquier servicio (evento o
transaccin) disponible en su visin de la sociedad. Adems, podr realizar
observaciones del sistema (object queries).

Las clases que implementan las tareas de control de acceso y construccin de la vista del
sistema (clases y servicios visibles) se implementarn en el nivel de interfaz. La
informacin necesaria para configurar la vista del sistema est incluida en la
especificacin del sistema (relaciones de agente) obtenida en la fase de modelado
conceptual.
Cualquier activacin de un servicio tiene dos partes: la construccin del mensaje y la
ejecucin (s es posible).

21
 1) Identificacin del objeto servidor: si el objeto existe el nivel de persistencia se
encargar de recuperar el objeto servidor de la base de datos y si es un evento de
creacin reservar espacio para su almacenamiento.
2) Introducir los argumentos necesarios para la ejecucin del evento: el nivel de
interfaz preguntar por los argumentos del evento que va a activarse (s es
necesario).

Una vez el mensaje se ha enviado, se identifica el objeto servidor (la existencia del
objeto servidor es una condicin implcita para ejecutar cualquier evento, excepto si se
trata del evento creacin) y se procede a seguir una secuencia de acciones sobre
dicho objeto:

1) Transicin vlida de estado: se verifica en el diagrama de transicin de estados

que exista una transicin vlida (desde el estado actual a un nuevo estado) para el
servicio seleccionado.
2) Satisfaccin de precondicin: se comprueba que se cumpla la precondicin
asociada al servicio en ejecucin (s existe).

Si no se cumplen 1 y 2 se elevar una excepcin informando que el servicio no puede

ejecutarse.

3) Evaluaciones: se modifican los valores de los atributos afectados por la ocurrencia

del servicio (como fuera especificado en el modelo funcional).
4) Comprobacin de las restricciones de integridad: las evaluaciones del servicio
deben dejar al objeto en un estado vlido. Se comprueba que no se violan las
restricciones de integridad (estticas y dinmicas). Si alguna de ellas se viola, se
generar una excepcin y el cambio de estado producido se ignorar.
5) Comprobacin de las relaciones de disparo: despus de un cambio de estado
vlido, y como accin final, se debe verificar el conjunto de reglas condicin-
accin que representa la actividad interna del sistema. Si alguna de ellas se
cumple, se activar el servicio correspondiente.

Una vez finalizadas con xito las acciones precedentes, los componentes de la capa de
persistencia se encargan de actualizar (UPDATE) la BDR correspondiente.
Los pasos anteriores guiarn la implementacin de cualquier aplicacin para asegurar la
equivalencia funcional entre la descripcin del sistema, recogida en el modelo conceptual,
y su realizacin en un entorno de programacin de acuerdo con el modelo de ejecucin.

3. METODOLOGAS

Una metodologa de Ingeniera del Software es un proceso de produccin organizada de

software, utilizando una coleccin predefinida de tcnicas y notaciones.
3.1. METODOLOGA OOHDM

Es una metodologa orientada a objetos la cual comprende 5 fases:

22
 1) Obtencin de requerimientos.
2) Modelo conceptual.
3) Diseo navegacional.
4) Diseo de la interfaz abstracta.
5) Implementacin.

Fase 1 (obtencin de requerimientos): La herramienta en la cual se fundamenta

esta fase son los diagramas de casos de usos, los cuales son diseados por
escenarios con la finalidad de obtener de manera clara los requerimientos y
acciones del sistema.
Fase 2 (Modelo conceptual): Se construye un modelo orientado a objetos que
represente el dominio de la aplicacin usando las tcnicas propias de la
orientacin a objetos.
Fase 3 (Diseo navegacional): La estructura de navegacin de una aplicacin
hipermedia est definida por un esquema de clases de navegacin especfica, que
refleja una posible vista elegida.
Fase 4 (diseo de la interfaz abstracta): En esta fase se definen qu objetos de
interfaz va a percibir el usuario, el camino en el cul aparecern los diferentes
objetos de navegacin, qu objeto de interfaz actuarn en la navegacin, la forma
de sincronizacin de los objetos multimedia y el interfaz de transformaciones.
Fase 5 (Implementacin): Una vez cumplidas las 4 fases anteriores solo queda
llevar los objetos a un lenguaje concreto de programacin.

3.2. SOHDM

Propone un proceso para el modelo conceptual del sistema, que es representado

mediante un diagrama de clases. El proceso de SOHDM contina reagrupando estas
clases para conseguir un modelo de clases navegacionales del sistema. Consiste en seis
fases: anlisis del dominio, modelado del objeto, diseo de la visin, diseo de la
navegacin, diseo de la puesta en prctica y construccin. Esta metodologa tiene
semejanzas con, OOHDM y EORM donde se diferencian en el uso de panoramas, que
describen las actividades en los acontecimientos y primitivas de flujos de actividades. Los
panoramas se definen en la fase de anlisis y se utilizan para modelar los objetos
3.3. RUP

El Proceso Unificado Racional, consiste en un proceso de desarrollo de software y junto

con el Lenguaje Unificado de Modelado (UML), este proceso constituye la metodologa
estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas
orientados a objetos. Este modelo tiene 4 fases principales:

Inicio: Se hace un plan de fases, donde se identifican los principales casos de uso
y se identifican los riesgos. Se concreta la idea, la visin del producto, como se
enmarca en el sistema, el alcance del proyecto.
Elaboracin: Se realiza el plan que seguir el proyecto de software, donde se
contemplan todos los casos de uso del sistema.
Construccin: Se realiza un producto totalmente operativo y se elabora el manual
de usuario, es en esta fase donde se define la arquitectura del proyecto.

23
 Transicin: Se implementa el proyecto, en esta fase se entrena a los usuarios
como deben utilizar el producto, en esta fase se el proyecto pasa del desarrollador
el usuario (transicin).

3.4. UML

El lenguaje de modelado unificado es una especificacin de notacin orientada a objetos,

el cual se compone de diferentes diagramas, los cuales representan las diferentes etapas
del desarrollo del proyecto. UML no preescribe un proceso o mtodo estndar para
desarrollar un sistema, es decir no especifica una sola forma de realizar una operacin, si
no que brinda las herramientas necearas para definir, crear y modelar las diferentes
etapas de un proyecto mediante una serie de diagramas. Hay varias metodologas
existentes; entre las ms populares se incluyen las siguientes:

Catalysis: Un mtodo orientado a objetos que fusiona mucho del trabajo reciente
en mtodos orientados a objetos, y adems ofrece tcnicas especficas para
modelar componentes distribuidos.
Objetory: Un mtodo de Caso de Uso guiado para el desarrollo, creado por Ivar
Jacobson.
Shlaer/Mellor: El mtodo para disear sistemas de tiempo real.
Fusion: Desarrollado en Hewlett Packard a mediados de los noventa como primer
intento de un mtodo de diseo orientado a objetos estndar.
OMT: La Tcnica de Modelado de Objetos fue desarrollada por James Rumbaugh
y otros, y publicada en el libro de gran influencia. Un mtodo que propone anlisis
y diseo iterative, ms centrado en el lado del anlisis.
Booch: Parecido al OMT con caractersticas adicionales.

3.5. MODELADO DE CASOS DE USO

Un caso de uso se modela para todos los procesos que el sistema debe llevar a cabo. Los
procesos se describen dentro del caso de uso por una descripcin textual o una
secuencia de pasos ejecutados. Una vez que el comportamiento del sistema est captado
de esta manera, los casos de uso se examinan y amplan para mostrar qu objetos se
interrelacionan para que ocurra este comportamiento. Los casos de uso son la forma ms
efectiva y fcil de modelar los requisitos de un usuario desde el punto de vista de este.
Los casos de uso son la herramienta que describen como debe funcionar un sistema o
como se deseara que funcione. No es realmente una aproximacin a la orientacin a
objetos; es realmente una forma de modelar procesos. Los casos de uso son
generalmente el punto de partida del anlisis orientado a objetos con UML.

4. CICLO DE VIDA

La ayuda que proporciona el ciclo de vida del proyecto es que puede organizar las
actividades del administrador, aumentando la probabilidad de que se traten los problemas
pertinentes en el momento adecuado.

24
Esta tcnica fue presentada en la dcada de los 90, tal vez como una de las mejores
metodologas a seguir para la creacin de productos software.
Puede considerarse como un modelo pleno a seguir, como as tambin una alternativa
dentro de los modelos anteriores.
Al igual que la filosofa del paradigma de la programacin orientada a objetos, en esta
metodologa cada funcionalidad, o requerimiento solicitado por el usuario, es considerado
un objeto.
Los ciclos de vida clsicos se centran en el proyecto, el desarrollo orientado a objetos se
basa en el producto, no comprende los procesos como funciones, sino que arma mdulos
basados en componentes, es decir, cada componente es independiente del otro y se
relacionan entre ellos a travs de interfaces, son ms modulares y se dividen en mini-
proyectos lo cual permiten que el cdigo sea reutilizable.

C. Ciclo de Vida Bsico

Es ms fcil de mantener porque los cambios estn localizados en cada uno de estos
componentes. De esta forma si el cliente tiene nuevos requerimientos es mucho ms fcil
agregarlos sin tener que hacer demasiados cambios en lo que ya se tiene.
Debido a todo esto se considera que el ciclo de vida orientado a objetos es iterativo e
incremental.
Los ciclos de vida orientados a objetos son:
1) Modelo Fuente.
2) Modelo de Agrupamiento.
3) Modelo Remolino.
4) Modelo PinBall.

A continuacin, veremos un tipo de ciclo de vida orientado a objetos ms conocidos, que

es adems el ms representativo.
4.1. MODELO FUENTE

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida

pensado para la orientacin a objetos y posiblemente el ms seguido.
Un proyecto se divide en las fases:
1) Planificacin del negocio

25
 2) Construccin: Es la ms importante y se divide a su vez en otras cinco actividades
Planificacin
Investigacin
Especificacin
Implementacin
Revisin
3) Entrega

La primera y la tercera fase son independientes de la metodologa de desarrollo orientado

a objetos. Adems de las tres fases, existen dos periodos:

Crecimiento: Es el tiempo durante el cual se construye el sistema

Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica
igual que el periodo anterior, es decir, con las fases de Planificacin del negocio,
Construccin y Entrega.

Cada clase puede tener un ciclo de vida slo para ella debido a que cada una puede estar
en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo
solapado e iterativo. En la figura se muestra un esquema de este tipo de ciclo de vida.

D. Estructura de Modelo Fuente

4.2. MODELO DE AGRUPAMIENTO (CLSTER)

Propuesto por Bertrand Meyer (Meyer, 1990).

Concepto Clave: Agrupamiento, que es un conjunto de clases relacionadas con un
objetivo comn.
Clster: Unidad organizativa bsica. Es un grupo de clases relacionadas o,
recursivamente, clsteres relacionados. El clster es la unidad natural para el desarrollo
por parte de un nico desarrollador.

Evita el efecto todo-nada propio del modelo en cascada.

26
Tiene un componente secuencial y un componente concurrente.

Existencia de diferentes subciclos de vida, que pueden solaparse en el tiempo.

Se aplica al clster no al sistema completo.
El miniciclo de vida que gobierna el desarrollo de un clster est formado por
Especificacin, Diseo, Implementacin, Verificacin/Validacin y
Generalizacin.

Enfoque Ascendente.
La ocultacin de la informacin posibilita la forma del modelo de clsteres de ingeniera
concurrente.

E. Estructura de Modelo De Agrupamiento

4.3. MODELO REMOLINO

Definido por James Rumbaugh (Rumbaugh, 1992). Las metodologas de desarrollo no

ofrecen una visin real del ciclo de vida en el desarrollo orientado al objeto. El ciclo de
vida de un desarrollo orientado al objeto es desordenado, involucrando mltiples
iteraciones interrelacionadas.
El modelo en cascada asume una sola dimensin de iteracin, consistentes en la fase de
proceso.
Pueden Identificarse otras dimensiones:

Amplitud: tamao del desarrollo, por ejemplo, en nmero de elementos.

Profundidad: referida al nivel de abstraccin o detalle.
Madurez: grado de complexin, correccin y elegancia.
Alternativas: Diferentes soluciones a un problema.
Alcance: Propsitos y objetivos del sistema, ya que los requisitos van cambiando a
lo largo del tiempo.

Las diferentes dimensiones pueden anidarse de varias formas. Ejemplo: profundidad -

madurez amplitud

27
Este proceso fractal (mas que lineal), consiste en un desarrollo multiciclo en forma de
remolino en lugar de una cascada, de ah su nombre.

4.4. MODELO PINBALL

Propuesto por Ambler (Ambler, 1994). Modelo muy didctico seala que el pinball refleja
la forma que se desarrolla el software.

Pelota Proyecto o subproyecto

Jugador Equipo de desarrollo

Se procede de forma iterativa a encontrar clases, atributos, mtodos y relaciones

(actividades que pueden englobarse en la fase de anlisis) y definir colaboraciones,
herencia, agregacin y subsistemas (actividades de diseo), y por ltimo se pasa a la
programacin, prueba e implementacin.
Como en el pinball los pasos se pueden dar en cualquier orden y de forma simultnea.
Existen dos estilos a la hora de jugar

A lo seguro Con tecnologas y mtodos probados

Al lmite Con ms riesgo (se pueden conseguir beneficios espectaculares)

El autor destaca que al igual que en el juego del pinball, la habilidad es el factor ms
importante.

F. Estructura de Modelo Pinball

4.5. CONSIDERACIONES SOBRE LOS CICLOS DE VIDA ORIENTADO A OBJETOS

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.

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

BIBLIOGRAFA

1) http://148.204.211.134/polilibros/Portal/Polilibros/P_proceso/ANALISIS_Y_DISEnO
_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20I/1.5.htm
2) https://sites.google.com/site/paradigmasdelais/4-1-el-enfoque-estructurado
3) https://helisulbaransistemas.blogspot.com/2014/09/paradigmas-en-el-desarrollo-
de-software.html
4) http://exa.unne.edu.ar/informatica/anasistem2/public_html/apuntes/maf/cap2.htm
5) http://es.slideshare.net/waralivt/desarrollo-estructurado

6) https://maestria-modulo7.blogspot.com/2012/05/ciclo-de-vida-orientado-objetos-
vs.html
7) http://exa.unne.edu.ar/informatica/anasistem2/public_html/apuntes/maf/cap4.htm#
CiclodeVida
8) http://exa.unne.edu.ar/informatica/anasistem2/public_html/apuntes/maf/cap3.htm
9) https://webcache.googleusercontent.com/search?
q=cache:JqPMrpFGrIwJ:indalog.ual.es/mtorres/LP/DOO.pdf+&cd=5&hl=es&ct=cln
k&gl=ar
10) https://sites.google.com/site/paradigmasdelais/4-2-el-enfoque-orientado-a-objetos
11) http://es.slideshare.net/RafaelMiranda2/modelado-orientado-a-objetos
12) http://es.slideshare.net/josefabiandiazs/ciclos-de-vida-orientados-a-objetos

29