Modelos del Sistema

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

INGENIERÍA INFORMÁTICA

ESTUDIANTE: SOFÍA TAMAYO

2009 - 2010

Transcripción del libroIngeniería del software

Ian sommerville

MODELOSDEL SISTEMA

CAPÍTULO 8

contenidosMODELOS

DEL SISTEMAMODELOS DE CONTEXTO

MODELOS DE COMPORTAMIENTOMODELOS DE FLUJO DE DATOS

MODELOS DE MAQUINAS DE ESTADO

MODELOS DE DATOS

MODELOS DE OBJETOSMODELOS DE HERENCIA

AGREGACIÓN DE OBJETOS

MODELADO DE COMPORTAMIENTO DE OBJETOS

MÉTODOS ESTRUCTURADOS

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.

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:Una perspectiva externa

en la que se modela el contexto

o entorno del sistema

Una perspectiva de comportamiento

en la que se modela el

comportamiento del sistema.

Una perspectiva estructural

en la que se modela la

arquitectura del sistema o la

estructura de los datos procesados

por el sistema.

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 intención del traductor debería ser mantener toda la información tal y como se presenta en inglés.

Diferentes tipos de modelos del sistema se basan en distintas aproximaciones de abstracción.

Un MODELO DE FLUJO DE DATOS

(por ejemplo) se centra en el flujo de datos y las

transformaciones funcionales sobre esos

datos. Se omiten los detalles de las estructuras de

datos.

Por el contrario, un MODELO DE

ENTIDADES DE DATOS Y SUS RELACIONES documentan las

estructuras de datos del sistema en lugar de su funcionalidad.

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.

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.

MODELOS DE CONTEXTOEn 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.

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.

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.

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.1El contexto de unsistema ATM.

Figura 8.1El contexto de unsistema ATM.

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.

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.

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.

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.

MODELOS DE COMPORTAMIENTO

Los modelos de comportamiento se utilizan para describir el comportamiento del sistema en su totalidad. Aquí se analizan dos tipos de modelos de comportamiento:

MODELOS DE FLUJO DE

DATOS

que modelan el procesamiento

de los datos en el sistema

MODELOS DE

MÁQUINAS DE ESTADO

que modelan cómo el sistema

reacciona a los eventos

Estos modelos pueden usarse de forma separada o conjuntamente, dependiendo del tipo de sistema que se esté desarrollando.

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

MODELOS DE FLUJO DE DATOSLos 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.

La notación Usada en ellos representa el procesamiento funcional (rectángulos redondeados),

los almacenes de datos (rectángulos)

Y el flujo de datos entre funciones (flechas etiquetadas).

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.

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

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.

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.

Figura 8.4Diagrama de flujo dedatos de una bombade insulina.

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.

MODELOS DE MÁQUINA DE ESTADOSUn 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.

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.

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

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.

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.

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.

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.

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.

ESTADO DESCRIPCIÓNEn espero El horno está esperando la entrada. La pantalla muestra la hora actual.

Potencia media La potencia del homo se fija en 300 vatios. La pantalla muestra <<Potencia Media>>

Potencia múima La potencia del horno se fija en 600 vatios. La pantalla muestra <<Potencia Máxima>>

Fijar tiempoSe fija el tiempo de cocción con el valor de entrada del usuario. La pantalla muestra el tiempo de cocción seleccionado y se actualiza en cuanto se fija el tiempo.

Inhabilitado Se inhabilita el funcionamiento del horno por razones de seguridad. La luz interior del homo se enciende. La pantalla muestra <<No listo>>.

Habilitado Se habilita el funcionamiento del horno. Se apaga la luz de su interior. La pantalla muestra <<listo para cocinar>>3

Funcionamiento

El horno está en funcionamiento. La luz interior del horno se enciende. La pantalla muestra la cuenta atrás del temporizador. Cuando finaliza la cocción, suena un timbre durante 5 segundos. La luz interior se enciende. La pantalla muestra <<Cocción finalizada>> mientras el timbre suena.

EstImulo Descripción Potencia media El usuario ha presionado el botón de potencia media.Potencia múima El usuario ha presionado el botón de potencia máxima.Temporizador El usuario ha presionado uno de los botones del temporizador.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.

Figura 8.6Descripción deestados y estimulaspara el hornomicroondas.

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.7Funcionamiento delhorno microondas.

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.7Funcionamiento delhorno microondas.

MODELOS DE DATOSLa 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.

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.

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.8Modelo semánticode datos para elsistema L1BSYS.

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.8Modelo semánticode datos para elsistema L1BSYS.

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.

Las ventajas de usar un diccionario de datos son las siguientes:

l. Es un mecanismo para la gestión de

nombres.

Muchas personas pueden tener que inventar nombres para las entidades y relaciones cuando

están desarrollando un modelo de un sistema grande estos nombres deberían ser usados de

forma consistente y no deberían entrar en conflicto. El software del diccionario de datos puede comprobar la unicidad de los nombres

cuando sea necesario y avisar a los analistas de requerimientos de las duplicaciones de

nombres.

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.

Figura 8.9Ejemplos deentradasde diccionariode datos.

ArtículoDetalle del articulo publicado que puede pedirse por las personas que usen LIBSYS

Entidad 30.12.2002

AutoresLos nombres de los Autores del articulo Atribulo que pueden compartir los honorarios

Atributo 30.12.2002

Comprador La persona u organización que emite emite la orden de copia del articulo

Entidad 29.12.2002

Honorarios a pagar a

Una relación 1:1 entre Artículo y la Agencia de derechos de autor a quien se deberla abonar el honorario de derechos de autor

Relación 31.12.2002

Dirección (Compredor)

La dirección del comprador. Esta se utiliza para cualquier información que se requiera que se requiera sobre la factura en papel

atributo 30.12.2002

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.

MODELOS DE OBJETOSUna 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 entidades.

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.

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.

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.

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íade clases para unabiblioteca.

Figura 8.10 Parte de una jerarquíade clases para unabiblioteca.

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.

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.

MODELOS DE HERENCIAEl 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.

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 Partede una jerarquíade clases para unabiblioteca.

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.11Jerarquía de clasesde usuarios.

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.

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.

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.

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.11Jerarquía de clasesde usuarios.


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.12Herencia múltiple.

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.

AGREGACIÓN DE OBJETOSAsí 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 Objetoagregado querepresenta un curso.

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.


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


MODELADO DE COMPORTAMIENTO DE OBJETOS

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

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.14Expediciónde elementos enformato electrónico.

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.


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.

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

Figur.7.8Interaccionesdel sistema para laimpresiónde artículos.

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.

MÉTODOS ESTRUCTURADOSUn 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.

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.

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.

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.

Figura 8.15 Loscomponentes deuna herramientaCASE para el soportede métodosestructurados.

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.

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.



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.



4. UN DICCIONARIO DE DATOS que mantiene información sobre las entidades utilizadas en el diseño de un sistema.



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.



6. HERRAMIENTAS DE DEFINICIÓN DE FORMULARIOS que permiten especificar los formatos de pantallas y de documentos.



7. FACILIDADES PARA IMPORTAR/EXPORTAR que permiten el intercambio de información desde el repositorio central con otras herramientas de desarrollo.



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.

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.

PUNTOS CLAVE

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.

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

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

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.

Los modelos de secuencia que muestran las interacciones entre actores y objetos en un sistema se utilizan para modelar el comportamiento dinámico

Modelos del Sistema

Education

Transcript of Modelos del Sistema