Este documento describe diferentes tipos de modelos que pueden usarse para documentar la especificación de un sistema, incluyendo modelos de flujo de datos, modelos de comportamiento, modelos de máquinas de estado, y modelos de objetos. Explica que los modelos son representaciones gráficas que describen los procesos del negocio y el sistema de una manera más comprensible que las descripciones detalladas en lenguaje natural.

3. CAPÍTULO 8

4. contenidos
MODELOS DE
CONTEXTO
MODELOS DE FLUJO DE DATOS
MODELOS DE
COMPORTAMIENTO
MODELOS DE MAQUINAS DE
ESTADO
MODELOS MODELOS DE DATOS
DEL SISTEMA MODELOS DE HERENCIA
MODELOS DE OBJETOS AGREGACIÓN DE OBJETOS
MODELADO DE
MÉTODOS COMPORTAMIENTO DE OBJETOS
ESTRUCTURADOS

5. Una técnica ampliamente usada es documentar
la especificación del sistema como un conjunto
de modelos del sistema. Estos modelos son
representaciones gráficas que describen los
procesos del negocio, el problema a resolver y
el sistema que tiene que ser desarrollado.
Debido a las representaciones gráficas
usadas, los modelos son a menudo más
comprensibles que las descripciones detalladas
en lenguaje natural de los requerimientos del
sistema. Ellos constituyen también un puente
importante entre el proceso de análisis y diseño.

6. Pueden usarse modelos en el proceso de análisis para
comprender el sistema existente que debe ser
reemplazado o mejorado, o para especificar el nuevo
sistema que sea requerido. Pueden desarrollarse
diferentes modelos para representar el sistema desde
diferentes perspectivas. Por ejemplo:

7. El aspecto más importante de un modelo del sistema es
que omite los detalles.
Un modelo del sistema es una abstracción del sistema
que se está estudiando en lugar de una representación
alternativa de ese sistema.
Idealmente, una representación de un sistema debería
mantener toda la información sobre la entidad que se está
representando.
Una abstracción simplifica y resalta de forma deliberada
las características más relevantes. Por ejemplo, en el
caso improbable de que este libro fuese publicado
por capítulos en un periódico, la presentación en este
caso sería una abstracción de los puntos clave del
libro. Si fuese traducido del inglés al italiano, ésta
podría ser una representación alternativa. La

8. Diferentes tipos de modelos del sistema se basan en
distintas aproximaciones de abstracción.
Un MODELO DE
FLUJO DE DATOS Por el contrario, un
(por ejemplo) se centra MODELO DE
en el flujo de datos y las ENTIDADES DE
transformaciones DATOS Y SUS
funcionales sobre esos RELACIONES
datos. documentan las
Se omiten los detalles estructuras de datos
de las estructuras de del sistema en lugar
datos. de su funcionalidad.

9. Ejemplos de tipos de modelos del sistema que podrían
crearse durante el proceso de análisis son:
1. Un modelo de flujo de datos
• Muestran cómo se procesan los datos en
el sistema en diferentes etapas.
2. Un modelo de composición
• O agregación muestra cómo las entidades
del sistema están compuestas por otras
entidades.

10. 3. Un modelo arquitectónico
• Muestran los principales subsistemas que componen
un sistema.
4. Un modelo de clasificación
• Los diagramas de clases herencia de objetos
muestran cómo las entidades tienen características
comunes.
5. Un modelo de estímulo-respuesta.
• O diagrama de transición de estados muestra cómo
reacciona el sistema a eventos internos y externos.

11. En una de las primeras etapas de la obtención de requerimientos
y del proceso de análisis se deben definir los límites del sistema.
Esto comprende trabajar conjuntamente con los stakeholders del
sistema para distinguir lo que es el sistema y lo que es el entorno
del sistema. Usted debería tomar estas decisiones al inicio del
proceso para delimitar los costes del sistema y el tiempo
necesario para el análisis.
En algunos casos, el límite entre un sistema y su entorno está
relativamente claro. Por ejemplo, en el caso de que un sistema
automático reemplace a un sistema existente manual o
computarizado el entorno del nuevo sistema es normalmente el
mismo que el entorno del sistema existente. En otros casos, hay
más flexibilidad, y usted decide lo que constituye el límite entre
el sistema y su entorno durante el proceso de ingeniería de
requerimientos.

12. Por ejemplo, suponga que está desarrollando la
especificación para el sistema de biblioteca LIBSYS.
Recuerde que este sistema pretende entregar versiones
electrónicas de material con derechos de autor a los
usuarios de computadoras.
A continuación los usuarios pueden imprimir copias
personales del material. Cuando desarrolla la
especificación para este sistema, usted tiene que decidir
si otros sistemas de bases de datos de bibliotecas tales
como catálogos de bibliotecas están dentro de los límites
del sistema. Si lo están, entonces puede permitir el
acceso al sistema a través de la interfaz de usuario del
catálogo; si no lo están, entonces los usuarios sufrirán la
incomodidad de tenerse que mover de un sistema a
otro.

13. La definición de un límite del sistema no es una decisión
arbitraria. Aspectos sociales y organizacionales pueden
implicar que la situación de los límites de un sistema puedan
ser determinados por factores no técnicos. Por ejemplo, un
límite de un sistema puede situarse de forma que el proceso
de análisis sólo se pueda llevar a cabo en un lugar; puede ser
elegido para que un gestor problemático no necesite ser
consultado; puede situarse para que el coste del sistema se
incremente, y la división del desarrollo del sistema debe, por
lo tanto, expandirse al diseño e implementación del sistema.
Una vez que se han tomado algunas decisiones sobre los
límites del sistema, parte de la actividad del análisis es la
definición de ese contexto y de las dependencias que el
sistema tiene sobre su entorno. Normalmente, la
producción de un modelo arquitectónico sencillo es el
primer paso en esta actividad.

14. La Figura 8.1 es un modelo arquitectónico que ilustra la estructura
del sistema de información que incluye una red de cajeros
automáticos.
Los modelos arquitectónicos de alto nivel se expresan
normalmente como sencillos diagramas de bloques en donde cada
subsistema se representa por un rectángulo con nombre, y las
líneas indican asociaciones entre los subsistemas.
Figura 8.1
El contexto de un
sistema ATM.

15. En la Figura 8.1, podemos ver que cada ATM (cajero automático) está
conectado a una base de datos de cuentas, a un sistema de contabilidad de
la sucursal, a un sistema de seguridad y a otro de mantenimiento de los
cajeros. El sistema también está conectado a una base de datos de uso
común que monitoriza cómo se usa la red de ATMs y también está
conectado a un sistema auxiliar local de una sucursal. Este sistema auxiliar
proporciona, servicios tales como copias de seguridad e impresión.
Éstos, por lo tanto, no necesitan incluirse en el propio sistema ATM.
Figura 8.1
El contexto de un
sistema ATM.

16. Los modelos arquitectónicos describen el entorno de un sistema.
Sin embargo, no muestran las relaciones entre otros sistemas del
entorno y el sistema que se está especificando. Los sistemas
externos podrían producir o consumir datos del sistema. Podrían
compartir datos con el sistema, o podrían ser conectados
directamente, conectados a través de una red o no estar
conectados. Podrían estar físicamente en el mismo lugar o
localizados en edificios diferentes.
Todas estas relaciones podrían afectar a los requerimientos del
sistema que se está definiendo y deben tenerse en cuenta.
Por lo tanto, los modelos arquitectónicos sencillos normalmente
se complementan con otros modelos, tales como modelos de
procesos, que muestran las actividades de los procesos soportadas
por el sistema. Los modelos de flujo de datos (descritos en la
sección siguiente) también pueden usarse para mostrar los datos
que son transferidos entre el sistema y otros sistemas de su
entorno.

17. La Figura 8.2 ilustra un modelo de proceso de adquisición de
equipos de una organización.
Esto implica especificar el equipo requerido, buscar y elegir a los
proveedores, pedir el equipo, recibir los equipos a su llegada y a
continuación verificarlos.

18. Cuando especifique el soporte informático para este proceso, usted
tiene que decidir cuáles de esas actividades serán realmente
informatizadas. El resto de las actividades están fuera de los límites
del sistema. En la Figura 8.2, la línea discontinua encierra las
actividades que están dentro de los límites del sistema.

19. Los modelos de comportamiento se utilizan para describir el
comportamiento del sistema en su totalidad. Aquí se analizan
dos tipos de modelos de comportamiento:
Estos modelos pueden usarse de forma separada o
conjuntamente, dependiendo del tipo de sistema que se esté
desarrollando.

20. La mayoría de los sistemas de negocio están fundamentalmente
dirigidos por los datos. Están controlados por las entradas de
datos al sistema con relativamente poco procesamiento de
eventos externos.
Un MODELO DE FLUJO DE DATOS puede ser todo lo que se
necesite para representar el comportamiento de estos sistemas.
Por el contrario, los sistemas de tiempo real a menudo están
dirigidos por eventos con un mínimo procesamiento de datos.
Un MODELO DE MÁQUINA DE ESTADOS es la forma más
efectiva de representar su comportamiento.
Otras clases de sistemas pueden estar dirigidas tanto por datos
como por eventos. En estos casos usted puede desarrollar
ambos tipos de modelos

21. Los modelos de flujo de datos son una forma intuitiva de mostrar
cómo los datos son procesados por un sistema.
A nivel de análisis, deberían usarse para modelar la forma en la que
los datos son procesados en el sistema existente.
El uso de modelos de flujo de datos para análisis comenzó a usarse
ampliamente después de la publicación del libro de DeMarco
(DeMarco, 1978) sobre análisis de sistemas estructurados.
Estos modelos son una parte intrínseca de los métodos estructurados
que han sido desarrollados a partir de este trabajo.

22. Los modelos de flujo de datos se utilizan para mostrar
cómo fluyen los datos a través de una secuencia de pasos
de procesamiento.
Por ejemplo, un paso de procesamiento podría ser filtrar
registros duplicados en una base de datos de clientes.
Los datos se transforman en cada paso antes de moverse a
la siguiente etapa.
Estos pasos de procesamiento o transformaciones
representan procesos software o funciones cuando los
diagramas de flujo de datos se utilizan para documentar
un diseño software.
Sin embargo, en un modelo de análisis, el procesamiento
se puede llevar a cabo por las personas o por las
computadoras.

23. Un modelo de flujo de datos, que muestra los pasos que comprende el
procesamiento de un pedido de productos (tales como equipamiento
informático) en una organización, se ilustra en la Figura 8.3. Este modelo
particular describe el procesamiento de datos en la actividad
Colocar el pedido del equipamiento en el modelo completo del proceso mostrado
en la Figura 8.2. El modelo muestra cómo el pedido para los productos fluye
desde un proceso a otro.
También muestra los almacenes de datos (Fichero de pedidos y Fichero de
presupuesto) que están implicados en este proceso.

24. Los modelos de flujo de datos son valiosos debido a que
realizan un seguimiento y documentan cómo los datos
asociados con un proceso particular fluyen a través del
sistema, y esto ayuda a los analistas a comprender el
proceso.
Los diagramas de flujo de datos tienen la ventaja de que, a
diferencia de otras notaciones de modelado, son sencillos
e intuitivos.
Normalmente es posible explicarlos a los usuarios
potenciales del sistema, quienes pueden entonces participar
en la validación del análisis.
En principio, el desarrollo de modelos tales como modelos
de flujo de datos debería ser un proceso «descendente».
En este ejemplo, esto podría implicar que debería
comenzarse analizando el proceso de adquisición de
equipamiento en su totalidad.

25. A continuación se seguiría con el análisis de subprocesos
tales como el de solicitud de pedidos. En la práctica, el
análisis nunca se hace así. Se analizan varios niveles al mismo
tiempo. Los modelos de bajo nivel pueden desarrollarse
primero y después abstraerse para crear un modelo más
general.
Los modelos de flujo de datos muestran una perspectiva
funcional en donde cada transformación representa un
único proceso o función.
Son particularmente útiles durante el análisis de
requerimientos ya que pueden usarse para mostrar el
procesamiento desde el principio hasta el final en un sistema.
Es decir, muestra la secuencia completa de acciones que
tienen lugar a partir de una entrada que se está procesando
hasta la correspondiente salida que constituye la respuesta
del sistema.

26. La Figura 8.4 ilustra este uso de los diagramas de flujo de datos.
Éste es un diagrama del procesamiento que tiene lugar en el
sistema de bomba de insulina introducido en el Capítulo 3.
Figura 8.4
Diagrama de flujo de
datos de una bomba
de insulina.

27. Un modelo de máquina de estados describe cómo
responde un sistema a eventos internos o externos.
El modelo de máquina de estados muestra los estados
del sistema y los eventos que provocan las transiciones
de un estado a otro.
No muestra el flujo de datos dentro del sistema.
Este tipo de modelo se utiliza a menudo para modelar
sistemas de tiempo real debido a que estos sistemas
suelen estar dirigidos por estímulos procedentes del
entorno del sistema.
Por ejemplo, el sistema de alarma de tiempo real
explicado en el Capítulo 13 responde a estímulos de
sensores de movimiento, sensores de apertura de
puertas, etcétera.

28. Los modelos de máquina de estados son una parte
integral de los métodos de diseño de tiempo real tales
como los propuestos por Ward y Mellor. El método de
Harel usa una notación denominada diagramas de
estado que fue la base para la notación del modelado de
máquina de estados en UML.
Un modelo de máquina de estados de un sistema
supone que, en cualquier momento, el sistema está en
uno de varios estados posibles.
Cuando se recibe un estímulo, éste puede disparar una
transición a un estado diferente.
Por ejemplo, un sistema de control de una válvula puede
moverse desde un estado «Válvula abierta» a un estado
«Válvula cerrada» cuando se reciba una orden (el
estímulo) del operador.

29. Esta aproximación para el modelado de sistemas se ilustra en la
Figura 8.5. Este diagrama muestra un modelo de máquina de
estados de un sencillo horno microondas equipado con botones
para fijar la potencia y el temporizador y para iniciar el sistema.
Los hornos microondas reales son actualmente mucho más
complejos que el sistema descrito aquí.

30. Sin embargo, este modelo incluye las características esenciales del
sistema. Para simplificar el modelo. Se supone que la secuencia de
acciones al usar el microondas es:
l. Seleccionar el nivel de potencia (ya sea media o máxima).
2. Introducir el tiempo de cocción.
3. Pulsar el botón de inicio, y la comida se cocina durante el tiempo
establecido.

31. Por razones de seguridad, el horno no debería funcionar cuando
la puerta esté abierta y, cuando se completa la cocción, suena un
timbre. El horno dispone de una pantalla alfanumérica sencilla
que se utiliza para visualizar varios mensajes de alerta y de
precaución.

32. La notación UML utilizada para describir los modelos de máquina de
estados está diseñada para modelar el comportamiento de los
objetos. Sin embargo, es una notación de propósito general que se
puede utilizar para cualquier tipo de modelado de máquina de
estados. Los rectángulos redondeados en un modelo representan los
estados del sistema. Incluyen una breve descripción (a continuación
de «do») de las acciones realizadas en ese estado. Las flechas
etiquetadas representan estímulos que fuerzan transiciones de un
estado a otro.

33. Por lo tanto, en la Figura 8.5, podemos ver que el sistema responde
bien inicialmente al botón de potencia máxima o al de potencia
media. Los usuarios pueden cambiar de idea después de seleccionar
uno de éstos y presionar el otro botón. Se fija el tiempo y, si la
puerta está cerrada, se habilita el botón de comienzo. Pulsando este
botón comienza a funcionar el horno y la cocción tiene lugar
durante el tiempo especificado.

34. La notación UML indica la actividad que tiene lugar en un
estado. En una especificación detallada del sistema, usted tiene
que proporcionar más detalle sobre el estímulo y los estados del
sistema (Figura 8.6). Esta información puede mantenerse en un
diccionario de datos o enciclopedia (incluida en la Sección 8.3) y
que es mantenida por las herramientas CASE utilizadas para
crear el modelo del sistema.
El problema con la aproximación de la máquina de estados es
que el número de posibles estados crece rápidamente.
Por lo tanto, para los modelos de sistemas grandes, es necesaria
una cierta estructuración de estos modelos de estados.
Una forma de hacer esto es mediante la noción de un
superestado que encierra a varios estados separados.
Este superestado se asemeja a un único estado de un modelo
de alto nivel, pero se expande a continuación con más detalle
en un diagrama distinto.

35. ESTADO DESCRIPCIÓN
En espero El horno está esperando la entrada. La pantalla muestra la hora actual.
La potencia del homo se fija en 300 vatios. La pantalla muestra
Potencia media
<<Potencia Media>>
La potencia del horno se fija en 600 vatios. La pantalla muestra
Potencia múima
<<Potencia Máxima>>
Se fija el tiempo de cocción con el valor de entrada del usuario. La
Fijar tiempo pantalla muestra el tiempo de cocción seleccionado y se actualiza en
cuanto se fija el tiempo.
Se inhabilita el funcionamiento del horno por razones de seguridad. La
Inhabilitado
luz interior del homo se enciende. La pantalla muestra <<No listo>>.
Se habilita el funcionamiento del horno. Se apaga la luz de su interior. La
Habilitado
pantalla muestra <<listo para cocinar>>3
El horno está en funcionamiento. La luz interior del horno se enciende.
La pantalla muestra la cuenta atrás del temporizador. Cuando finaliza la
Funcionamiento cocción, suena un timbre durante 5 segundos. La luz interior se
enciende. La pantalla muestra <<Cocción finalizada>> mientras el
timbre suena. Figura 8.6
EstImulo Descripción Descripción de
Potencia media El usuario ha presionado el botón de potencia media. estados y
estimulas
Potencia múima El usuario ha presionado el botón de potencia máxima. para el horno
Temporizador El usuario ha presionado uno de los botones del temporizador. microondas.
Número El usuario ha presionado una teda numérica.
Puerta abierta El interruptor de la puerta del horno no está cerrado.
Puerta cenada El interruptor de la puerta del horno está cerrado.
Iniciar El usuario ha presionado el botón de inicio.
Cancelar El usuario ha presionado el botón de cancelar.

36. Para ilustrar este concepto, considere el estado
Funcionamiento en la Figura 8.5. Éste es un
superestado que puede expandirse, tal y como
se ilustra en la Figura 8.7.
figura 8.7
Funcionamiento del
horno microondas.

37. El estado Funcionamiento incluye varios subestados. Muestra que una
operación comienza con una comprobación de estado, y que si se
descubre cualquier problema, se activa una alarma y la operación
queda inhabilitada. La cocción implica poner en marcha el generador
de microondas durante el tiempo especificado; a su terminación, suena
un timbre. Si la puerta se abre durante el funcionamiento, el sistema se
mueve al estado inhabilitado, tal y como se muestra en la Figura 8.5.
figura 8.7
Funcionamiento del
horno microondas.

38. La mayoría de los sistemas software grandes utilizan bases de
datos de información de gran tamaño. En algunos casos, esta
base de datos es independiente del sistema software. En
otros, se crea para el sistema que se está desarrollando.
Una parte importante del modelado de sistemas es la definición
de la forma lógica de los datos procesados por el sistema. Éstos
se denominan a menudo modelos semánticos de datos.
La técnica de modelado de datos más ampliamente usada es el
modelado Entidad-Relación- Atributo (modelado
ERA), que muestra las entidades de datos, sus atributos
asociados y las relaciones entre estas entidades. Esta
aproximación de modelado fue propuesta por primera vez a
mediados de los años 70 por Chen desde entonces se han
desarrollado varias variantes, y todas ellas tienen la misma forma
básica.

39. Los modelos entidad-relación han sido ampliamente usados en
el diseño de bases de datos.
Los esquemas de bases de datos relacionales derivados de
estos modelos se encuentran de manera natural en tercera
forma normal, lo cual es una característica deseable. Debido al
tipado explícito y al reconocimiento de subtipos y
supertipos, también es sencillo implementar estos modelos
utilizando bases de datos orientadas a objetos.
UML no incluye una notación específica para este modelado de
bases de datos, ya que asume un proceso de desarrollo
orientado a objetos y modela los datos utilizando objetos y sus
relaciones. Sin embargo, se puede usar UML para representar
un modelo semántico de datos.
Se puede pensaren las entidades de un modelo ERA (Entidad-
Relación- Atributo) como clases de objetos simplificadas (no
tienen operaciones), los atributos como atributos de la clase y
las denominadas asociaciones entre clases como relaciones.

40. La Figura 8.8 es un ejemplo de un modelo de datos que es parte del sistema de
biblioteca LIBSYS introducido en capítulos anteriores. Recuerde que LIBSYS se
diseña para entregar copias de artículos con derechos de autor que han sido
publicados en revistas y periódicos y para registrar el pago de estos artículos. Por
lo tanto, el modelo de datos debe incluir información sobre el artículo, el poseedor
de los derechos de autor y el comprador del artículo.
Aquí hemos supuesto que estos pagos para los artículos no se hacen directamente
sino a través de agencias nacionales de derechos de autor.
Figura 8.8
Modelo semántico
de datos para el
sistema L1BSYS.

41. La Figura 8.8 muestra que un Articulo tiene atributos que representan el
título, los autores, el nombre del fichero PDF del artículo y el honorario a pagar.
Éste se enlaza con Fuente, en donde fue publicado el artículo, y con la Agencia
de derechos de autor del país de publicación. Ambos, Agencia de derechos de
autor y Fuente, se enlazan con País. El país de publicación es importante debido
a que las leyes de derechos de autor varían de un país a otro. El diagrama
también muestra que los Compradores emiten Órdenes de compra de Artículos.
Figura 8.8
Modelo semántico
de datos para el
sistema L1BSYS.

42. Al igual que todos los modelos gráficos, a los modelos de datos les
faltan detalles, y usted debería mantener descripciones más
detalladas de las entidades, relaciones y atributos incluidas en el
modelo. Usted puede reunir estas descripciones más detalladas en
un repositorio o diccionario de datos. Los diccionarios de datos
generalmente son útiles cuando desarrollamos modelos de sistemas
y pueden utilizarse para gestionar toda la información de todos los
tipos de modelos de sistemas.
Un diccionario de datos es, de forma simple, una lista de nombres
ordenada alfabéticamente incluida en los modelos del sistema. El
diccionario debería incluir, además del nombre, una descripción
asociada de dicha entidad con nombre y, si el nombre representa
un objeto compuesto, una descripción de la composición. Se puede
incluir otra información, como la fecha de creación, el creador y la
representación de la entidad dependiendo del tipo de modelo que
se esté desarrollando.

43. Las ventajas de usar un diccionario de datos son las siguientes:
l. Es un mecanismo para la 2. Sirve como un almacén de
gestión de nombres. información de la organización.
Muchas personas pueden
tener que inventar nombres A medida que el sistema
para las entidades y relaciones se desarrolla, la
cuando están desarrollando información que enlaza
un modelo de un sistema el análisis, diseño,
grande estos nombres implementación y
deberían ser usados de forma evolución se añade al
consistente y no deberían diccionario de datos,
entrar en conflicto. El para que toda la
software del diccionario de
datos puede comprobar la
información sobre una
unicidad de los nombres entidad esté en un
cuando sea necesario y avisar mismo lugar.
a los analistas de
requerimientos de las
duplicaciones de nombres.

44. Las entradas del diccionario de datos mostradas en la Figura 8.9
definen los nombres en el modelo semántico de datos para LIBSYS
(Figura 8.8). Se ha simplificado la presentación de este ejemplo
obviando algunos nombres y reduciendo la información asociada.
Detalle del articulo publicado que
Artículo puede pedirse por las personas que Entidad 30.12.2002
usen LIBSYS
Los nombres de los Autores del
Autores articulo Atribulo que pueden Atributo 30.12.2002
compartir los honorarios
La persona u organización que emite
Comprador Entidad 29.12.2002
emite la orden de copia del articulo
Una relación 1:1 entre Artículo y la
Honorarios a Agencia de derechos de autor a quien
Figura 8.9 Relación 31.12.2002
pagar a se deberla abonar el honorario de
Ejemplos de
derechos de autor
entradas
de diccionario La dirección del comprador. Esta se
de datos. Dirección utiliza para cualquier información que
atributo 30.12.2002
(Compredor) se requiera que se requiera sobre la
factura en papel

45. Todos los nombres del sistema, tanto si son
nombres de entidades, relaciones, atributos o
servicios, deberían introducirse en el diccionario.
El software se utiliza normalmente para
crear, mantener y consultar el diccionario. Este
software debería integrarse con otras
herramientas para que la creación del diccionario
se automatice parcialmente. Por ejemplo, las
herramientas CASE que soportan el modelado del
sistema incluyen soporte para el diccionario de
datos e introducen los nombres en el diccionario
cuando se utilizan por primera vez en el modelo.

46. Una aproximación orientada a objetos para el proceso de
desarrollo del software en su totalidad se usa actualmente de
forma generalizada, en particular para el desarrollo de sistemas
interactivos. Esto significa expresar los requerimientos de los
sistemas utilizando un modelo de objetos, diseñar utilizando
objetos y desarrollar el sistema en un lenguaje de programación
orientado a objetos, como por ejemplo Java o C++.
Los modelos de objetos que usted desarrolla durante el análisis
de requerimientos pueden utilizarse para representar tanto
los datos del sistema como su procesamiento. A este
respecto, dichos modelos combinan algunos de los usos de los
modelos de flujo de datos y los modelos semánticos de
datos.
Los modelos de objetos también son útiles para mostrar cómo se
clasifican las entidades en el sistema y se componen de otras

47. Para algunas clases del sistema. Los modelos de objetos son formas
naturales de reflejar las entidades del mundo real que son manipuladas
por el sistema. Esto es particularmente cierto cuando el sistema procesa
información sobre entidades tangibles, tales como coches, aviones o
libros, que tienen atributos claramente identificables. Entidades más
abstractas, y de más alto nivel, tales como el concepto de una
biblioteca, un sistema de registros médicos o un procesador de
texto, son más difíciles de modelar como clases de objetos. Éstos no
tienen necesariamente una interfaz sencilla consistente en atributos
independientes y operaciones.
El desarrollo de modelos de objetos durante el análisis de
requerimientos normalmente simplifica la transición entre el diseño
orientado a objetos y la programación. Sin embargo, se observa que los
usuarios de un sistema a menudo buscan modelos de objetos no
naturales y difíciles de entender. Ellos pueden preferir adoptar un
punto de vista más funcional y de proceso de datos. Por lo tanto, a
veces es útil complementar el modelo de objetos con modelos de
flujos de datos que muestren el procesamiento de datos en el sistema
desde el principio hasta el final.

48. Una clase de objetos es una abstracción sobre un conjunto de
objetos que identifica atributos comunes (como en un modelo
semántico de datos) y los servicios u operaciones que son
proporcionados por cada objeto. Los objetos son entidades
ejecutables que tienen atributos y servicios de la clase de objetos.
Los objetos son instanciaciones de la clase de objetos, y pueden
crearse muchos objetos a partir de una clase. Generalmente, los
modelos desarrollados utilizando análisis se centran en las clases
de objetos y en sus relaciones.
En el análisis de requerimientos orientado a objetos, deberían
modelarse entidades del mundo real utilizando clases de objetos.
No deberían incluirse detalles de los objetos individuales
(instanciaciones de la clase) en el sistema. Se pueden crear
diferentes tipos de modelos de objetos, mostrando cómo las clases
de objeto se relacionan unas con otras, cómo los objetos son
agregados para formar otros objetos, cómo los objetos interactúan
con otros objetos, etcétera. Cada uno de éstos presenta una
información distinta sobre el sistema que se está especificando.

49. El proceso de análisis para identificar los objetos y las clases de
objetos se reconoce como una de las áreas más difíciles del
desarrollo orientado a objetos. La identificación de objetos es
básicamente la misma para el análisis y para el diseño. Pueden
utilizarse los métodos de identificación de objetos tratados en el
Capítulo 14, que analiza el diseño orientado a objetos.
Aquí se tratan algunos de los modelos de objetos que podrían
generarse durante el proceso de análisis.
En los años 90 se propusieron varios métodos de análisis orientados
a objetos Estos métodos tienen mucho en común, y tres de estos
desarrolladores (Booch, Rumbaugh y Jacobsen) decidieron integrar
sus aproximaciones para producir un método unificado. El Lenguaje
Unificado de Modelado (UML) utilizado en este método unificado
se ha convertido en un estándar para el modelado de objetos. UML
incluye notaciones para diferentes tipos de modelos de sistemas.
Nosotros ya hemos visto los modelos de casos de uso y los
diagramas de secuencia en capítulos anteriores y los modelos de
máquinas de estados al principio de este capítulo.

50. Una clase de objetos en UML, como se
ha ilustrado en los ejemplos de la
Figura 8.10, se representa como un
rectángulo orientado verticalmente
con tres secciones:
Figura 8.10
Parte de una jerarquía
de clases para una
biblioteca.

51. l. El nombre de la clase de objetos está en la
sección superior.
2. Los atributos de la clase están en la sección
intermedia.
3. Las operaciones asociadas con la clase de
objetos están en la sección inferior del
rectángulo.
Figura 8.10
Parte de una jerarquía
de clases para una
biblioteca.

52. Debido a la limitación de espacio para
incluir todo sobre UML, aquí sólo se tratan
modelos de objetos que muestran
cómo los objetos pueden clasificarse y
pueden heredar atributos y operaciones de
otros objetos.
modelos de agregación que muestran
cómo están compuestos los objetos, y
modelos de comportamiento
sencillos, que muestran las interacciones
entre los objetos.

53. El modelado orientado a objetos implica la
identificación de clases de objetos que son importantes
en el dominio que se está estudiando. Estos objetos se
organizan a continuación en una taxonomía.
Una taxonomía es un esquema de clasificación que
muestra cómo una clase de objetos está relacionada
con otras clases a través de atributos y servicios
comunes.
Para mostrar esta taxonomía, las clases se organizan en
una jerarquía de herencia con las clases de objetos más
generales al principio de la jerarquía. Los objetos más
especializados heredan sus atributos y servicios. Estos
objetos especializados pueden tener sus propios
atributos y servicios.

54. La Figura 8.10 ilustra parte de una
jerarquía de clases simplificada para un
modelo de biblioteca. Esta jerarquía
proporciona información sobre los
elementos almacenados en la
biblioteca. La biblioteca comprende
varios elementos, tales como libros,
música, grabaciones de películas,
revistas y periódicos.
Figura 8.10 Parte
de una jerarquía
de clases para una
biblioteca.

55. En la Figura 8.10, el elemento más
general está en la raíz del árbol y tiene
un conjunto de atributos y servicios que
son comunes a todos los elementos de
la biblioteca. Éstos son heredados por
las clases Elemento publicado y
Elemento registrado, que añaden sus
propios atributos que son heredados a
continuación por elementos de niveles
inferiores.
Figura 8.10 Parte
de una jerarquía
de clases para una
biblioteca.

56. La Figura 8.11 es un ejemplo de otra jerarquía de herencia que
podría ser parte del modelo de biblioteca. En este caso, se
muestran los usuarios de una biblioteca.
Hay dos clases de usuarios: aquellos a los que se les permite pedir
prestados libros, y aquellos que sólo pueden leer los libros en la
biblioteca sin llevárselos.
Figura 8.11
Jerarquía de clases
de usuarios.

57. En la notación UML, la herencia se muestra «hacia arriba» en
lugar de «hacia abajo» como en otras notaciones orientadas a
objetos o en lenguajes tales como Java, en donde las subclases
heredan de las superclases. Es decir, la punta de la flecha
(mostrada como un triángulo) apunta desde las clases que
heredan sus atributos y operaciones hasta su superclase.
En lugar de utilizar el término herencia. UML habla de
relación de generalización.
El diseño de jerarquías de clases no es fácil, ya que el analista
necesita comprender con detalle el dominio en el que el
sistema será implantado. Como ejemplo de los problemas
sutiles que surgen en la práctica, considere la jerarquía de
elementos de la biblioteca. Podría parecer que el atributo
Título podría situarse como el elemento más general, y a
continuación ser heredado por elementos de niveles
inferiores.

58. Sin embargo, si bien cada elemento en una biblioteca
debe tener algún tipo de identificador o número de
registro, esto no significa que todos los elementos
deban tener un título. Por ejemplo, una biblioteca
puede almacenar ciertos elementos personales de un
político retirado. Muchos de estos elementos, tales
como cartas, pueden no tener un título de forma
explícita. Éstos serán clasificados utilizando alguna
otra clase (no mostrada aquí) que tiene un conjunto
diferente de atributos.

59. Las Figuras 8.10 y 8.11 muestran jerarquías de herencia de clases en las que
cada clase de objetos hereda sus atributos y operaciones de una única clase
padre. También pueden construirse modelos de herencia en los que una clase
tiene varios padres. Sus atributos y servicios son una conjunción de los
heredados de cada superclase.
Figura 8.10 Parte
de una jerarquía
de clases para una
biblioteca.
Figura 8.11
Jerarquía de clases
de usuarios.

60. La Figura 8.12 muestra un ejemplo de modelo de herencia
múltiple que también puede ser parte del modelo de biblioteca.
Figura 8.12
Herencia múltiple.

61. El problema principal con la herencia múltiple es
el diseño de un grafo de herencia en donde los
objetos no heredan atributos innecesarios. Entre
otros problemas se incluye la dificultad de
reorganizar el grafo de herencia cuando se
requieren cambios y resolver conflictos de
nombres cuando dos o más superclases tienen el
mismo nombre pero diferentes significados.
A nivel de modelado de sistemas, tales conflictos
son relativamente fáciles de resolver alterando
manualmente el modelo de objetos. Esto puede
ocasionar más problemas en la programación
orientada a objetos.

62. Así como se adquieren atributos y servicios a través de una relación
de herencia con otros objetos, algunos objetos son agrupaciones
de otros objetos. Es decir, un objeto es un agregado de un
conjunto de otros objetos. Las clases que representan a estos
objetos pueden modelarse utilizando un modelo de agregación, tal
y como se muestra en la Figura 8.13.
Figura 8.13 Objeto
agregado que
representa un curso.

63. En este ejemplo, se ha modelado un elemento de
biblioteca, consistente en un paquete de estudio para un curso
universitario. El paquete de estudio comprende apuntes de
clase, ejercicios, soluciones ejemplo, copias de las transparencias
usadas en las clases y cintas de vídeo.
Figura 8.13 Objeto
agregado que
representa un curso.

64. La notación UML para la agregación consiste en representar la
composición incluyendo una figura de diamante colocada sobre
el elemento fuente del enlace. Por lo tanto, la Figura 8.13
puede leerse como "Un paquete de estudio está compuesto
por uno o varios elementos asignados, paquetes de
transparencias OHP, apuntes y cintas de vídeo».
Figura 8.13 Objeto
agregado que
representa un curso.

65. Para modelar el comportamiento de los objetos, se tiene que
mostrar cómo se utilizan las operaciones proporcionadas por los
objetos. En UML, se modelan los comportamientos utilizando
escenarios que son representados como casos de uso UML
(estudiados en el Capítulo 7).
Una forma de modelar los comportamientos es utilizar
diagramas de secuencia UML que muestran la secuencia
de acciones implicadas en un caso de uso. Además de los
diagramas de secuencia, UML también incluye diagramas de
colaboración que muestran la secuencia de mensajes
intercambiados por los objetos. Estos diagramas son similares a
los diagramas de secuencia, por lo que no se tratan aquí.

66. Se puede ver cómo se pueden utilizar los diagramas de
secuencia para modelar el comportamiento en la Figura 8.14.
que expande un caso de uso del sistema LlBSYS en el que los
usuarios solicitan préstamos a la biblioteca en formato
electrónico.
Figura 8.14
Expedición
de elementos en
formato electrónico.

67. Por ejemplo, imagine una situación en la que los paquetes de
estudio mostrados en la Figura 8.13 podrían mantenerse en
formato electrónico y descargarse a la computadora del
estudiante.
Figura 8.13 Objeto
agregado que
representa un curso.

68. En un diagrama de
secuencia, los objetos y los
actores se alinean en la parte
superior del diagrama.
Las flechas etiquetadas
indican las operaciones; la
secuencia de operaciones se
lleva a cabo desde arriba
hacia abajo enviado al usuario
de la biblioteca.

69. En este escenario, el usuario de
la biblioteca accede al catálogo
para ver si el elemento
solicitado está disponible en
formato electrónico; si lo
está, el usuario solicita dicho
elemento. Por razones de
derechos de autor, se debe
asignar una licencia al elemento
para que exista una transacción
entre el elemento y el
usuario, que debe aceptar
dicha licencia. El elemento
solicitado se envía a un objeto
servidor de red para su
compresión antes de ser
enviado al usuario de la

70. Se puede encontrar otro ejemplo de un diagrama de secuencia
que expande un caso de uso de LIBSYS en la Figura 7.8, que
muestra la secuencia de actividades implicadas en la impresión
de un artículo.
Figur.7.8
Interacciones
del sistema para la
impresión
de artículos.

71. Un método estructurado es una forma sistemática de
elaborar modelos de un sistema existente o de un
sistema que tiene que ser construido. Fueron
desarrollados por primera vez en la década de los 70
para soportar el análisis y el diseño del software y
evolucionaron en las décadas de los 80 y de los 90 para
soportar el desarrollo orientado a objetos . Estos
métodos orientados a objetos se unieron con la
propuesta UML como lenguaje de modelado estándar y
el Proceso Unificado, y más tarde con el Proceso
Unificado de Rational como un método asociado
estructurado. Budgen resume y compara varios de estos
métodos estructurados.

72. Los métodos estructurados proporcionan un marco
para el modelado detallado de sistemas como parte
de la elicitación y análisis de requerimientos. La
mayoría de métodos estructurados tienen su propio
conjunto preferido de modelos de sistemas.
Normalmente definen un proceso que puede utilizarse
para derivar estos modelos y un conjunto de reglas y
guías que aplican a dichos modelos. Se genera una
documentación estándar para el sistema.
Normalmente se encuentran disponibles herramientas
CASE que soportan el uso de métodos. Estas
herramientas soportan la edición de modelos y
generación de código y documentación, y
proporcionan algunas capacidades para comprobar los
modelos.

73. Los métodos estructurados han sido aplicados con éxito en muchos
proyectos grandes.
Pueden suponer reducciones significativas de coste debido a que
utilizan notaciones estándar y aseguran que se produce una
documentación de diseño estándar. Sin embargo, los métodos
estructurados tienen una serie de inconvenientes:
1. No proporcionan un soporte efectivo para la comprensión o el
modelado de requerimientos del sistema no funcionales.
2. No discriminan en tanto que normalmente no incluyen guías que
ayuden a los usuarios a decidir si un método es adecuado para un
problema concreto. Tampoco incluyen normalmente consejos
sobre cómo pueden adaptarse para su uso en un entorno
particular.
3. A menudo generan demasiada documentación. La esencia de los
requerimientos del sistema puede quedar oculta por el volumen
de detalle que se incluye.
4. Los modelos producidos son muy detallados, y los usuarios a
menudo los encuentran difíciles de entender. Estos usuarios, por
lo tanto, no pueden comprobar el realismo de estos modelos.

74. En la práctica, sin embargo, los ingenieros de requerimientos y los
diseñadores no se restringen a los modelos propuestos por un
método determinado. Por ejemplo, los métodos orientados a
objetos no sugieren normalmente que los modelos de flujos de
datos deban desarrollarse.
Sin embargo, según mi experiencia, dichos modelos son a menudo
útiles como parte del proceso de análisis de requerimientos debido
a que pueden presentar un panorama general del procesamiento
en el sistema desde el principio hasta el final.
También pueden contribuir directamente a la identificación de los
objetos (los datos que fluyen) y la identificación de las operaciones
sobre esos objetos (las transformaciones).
Las herramientas CASE de análisis y diseño soportan la
creación, edición y análisis de las notaciones gráficas utilizadas en
los métodos estructurados. La Figura 8.15 muestra los
componentes que pueden ser incluidos en los entornos que
soportan métodos.

75. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
1. EDITORES DE DIAGRAMAS utilizados para crear modelos de
objetos, modelos de datos, modelos de
comportamiento, etcétera. Estos editores no son simplemente
herramientas de dibujo puesto que identifican los tipos de
entidades en el diagrama. Captan la información sobre estas
entidades y guardan esta información en el repositorio central.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

76. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
2. HERRAMIENTAS DE ANÁLISIS Y COMPROBACIÓN DE DISEÑOS
que procesan el diseño e informan sobre errores y anomalías.
Pueden integrarse con el sistema de edición para que los
errores del usuario sean detectados en etapas tempranas del
proceso de desarrollo.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

77. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
3. LENGUAJES DE CONSULTA DEL REPOSITORIO que permite al
diseñador encontrar diseños e información asociada a los
diseños en el repositorio.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

78. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
4. UN DICCIONARIO DE DATOS que mantiene
información sobre las entidades utilizadas en el diseño
de un sistema.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

79. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
5. HERRAMIENTAS DE GENERACIÓN Y DEFINICIÓN DE
INFORMES que obtienen información del almacén
central y generan automáticamente la documentación
del sistema.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

80. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
6. HERRAMIENTAS DE DEFINICIÓN DE FORMULARIOS
que permiten especificar los formatos de pantallas y
de documentos.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

81. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
7. FACILIDADES PARA IMPORTAR/EXPORTAR que permiten el
intercambio de información desde el repositorio central con
otras herramientas de desarrollo.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

82. Las herramientas que soportan métodos completos, tal y como
se ilustra en la Figura 8.15, normalmente incluyen:
8. GENERADORES DE CÓDIGO que generan código o
esqueletos de código de forma automática a partir del
diseño capturado en el almacén central.
Figura 8.15 Los
componentes de
una herramienta
CASE para el soporte
de métodos
estructurados.

83. La mayoría de los conjuntos de herramientas CASE
completos permiten al usuario generar un programa o
un fragmento de un programa a partir de la información
proporcionada en el modelo del sistema. Las
herramientas CASE a menudo soportan diferentes
lenguajes para que el usuario pueda generar un
programa en C. C++ o Java a panir del mismo modelo de
diseño. Debido a que los modelos excluyen detalles de
bajo nivel, el generador de código en un banco de
trabajo de diseño no puede normalmente generar el
sistema completo.
Normalmente es necesaria alguna codificación manual
para añadir detalles al código generado.

84. Un modelo es una vista abstracta de un sistema
que prescinde de algunos detalles del mismo.
Pueden desarrollarse modelos del sistema
complementarlos para presentar otra Información
sobre dicho sistema.
Los modelos de contexto muestran como el sistema que se
está modelando se ubica en un entorno con otros sistemas
y procesos. Definen los limites del sistema. Los modelos
arquitectónicos, los modelos de procesos y modelos de
flujos de datos pueden utilizarse como modelos de
contexto.

85. Los diagramas de flujo de datos pueden utilizarse
para modelar el procesamiento de los datos
llevado acabo por un sistema. El sistema se
modela como un conjunto de transformaciones
de datos con funciones que actúan sobre los
datos.
Los modelos de maquina de estados se utilizan
para modelar el comportamiento del sistema en
respuesta a eventos Internos o externos.

86. Los modelos semánticos de datos describen la
estructura lógica de los datos importados y
exportados por el sistema. Estos modelos
muestran las entidades del sistema, sus
atributos y las relaciones en las que Intervienen.
Los modelos de objetos describen las entidades
lógicas del sistema y su clasificación y agregación.
Combinan un modelo de datos con un modelo de
procesamiento. Posibles modelos de objetos que
pueden desarrollarse Incluyen modelos de
herencia, modelos de agregadón y modelos de
comportamiento..

87. Los modelos de secuencia que muestran las
interacciones entre actores y objetos en un
sistema se utilizan para modelar el
comportamiento dinámico
Los métodos estructurados proporcionan un
marco para soportar el desarrollo de modelos
del sistema. Los métodos estructurados
normalmente son soportados de forma
extensiva por herramientas CASE, incluyendo la
edición de modelos y la comparación y
generación de código.